Subject: June 2001 mail archives part 1

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 18 Jul 2001 17:30:39 -0700

From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: [Fwd: Re: M2PA: Multiple streams]
Date: Fri, 1 Jun 2001 00:21:34 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail4.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail4.rdc1.on.home.com [24.2.9.91]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Wednesday, May 30, 2001 2:40 PM
Subject: Re: [Fwd: Re: M2PA: Multiple streams]

Greg,

So, to sum up, can you see a reason not to permit multiple streams and using
TSN instead of SSN?

--Brian

[Greg] I'm not sure yet - I need to think about this proposal a little more.
I was originally against restricting the M2PA to use of a single stream - if
you have found a way to take advantage of this then I am all ears.

Cheers,

   Greg

On Wed, 30 May 2001, Sidebottom, Greg [BCNR:7M01:EXCH] wrote:

>
>    Hi Brian,
>
>    Don't ask Jeff - ask the Operators who do have asked for this - we are
>    just lowly vendors listening to our customers  2;^)
>
>    Seriously, it is just a question of degree.  I think you may have
>    partially answered your own question with your other e-mail about how
>    the 04/0.8 rule was dependent on MTP2 link characteristics and
>    simulation data.  You correctly implied that we don't really have much
>    data or simulations for operation an M2PA/SCTP link in an SS7
>    network.  I think we will learn this as progressive operators try it
>    out at low load and then see how they can crank it up.  It is doubtful
>    that an M2PA link would congest when this lightly loaded (i.e., at
>    0.4e equivalent of a low-speed link) but there are enough other
>    network and implementation-dependent reasons for a link to congest in
>    a real network that operators might find this loading as useful as a
>    starting point.
>
>    Cheers,
>
>       Greg
>

--
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To unsubscribe
send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 1 Jun 2001 00:54:06 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA: Changeover between ASPs
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      AAA15743
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.231]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

I agree with you whole-heartedly on the Override-Standby.  It's useless.
However, I also believe that Load-Share is useless as well.  Let me offer a
proposal for a Broadcast redundancy model, show you how I intend to use it,
and show you why I need a Correlation Id, at least as an optional parameter
which must be used in some circumstances.

Bear with me.

I would like to propose two new Traffic Mode Types with text as follows (I
had mentioned this to Greg before):

In Section 3.5.5 change the following:

.   Traffic Mode Type: 32-bit (unsigned integer) .
.      The Traffic Mode Type parameter identifies the traffic mode of .
operation of the ASP within an AS.  The valid values for Type are .
shown in the following table.
.
.           1       Over-ride
.           2       Load-share
.           3       Over-ride (Standby) .           4       Load-share
(Standby) |           5       Broadcast
|           6       Broadcast (Standby) .   
.      Within a particular Routing Context, only one Traffic Mode Type .
can be used.  The Over-ride value indicates that the ASP is .      operating
in Over-ride mode, and the ASP takes over all .      traffic in an
Application Server (i.e., primary/back-up operation), .      over-riding any
currently active ASPs in the AS.  In Load-share .      mode, the ASP will
share in the traffic distribution with any other .      currently active
ASPs.  The Standby versions of the Over-ride and .      Load-share Types
indicate that the ASP is declaring itself ready to .      accept traffic but
leaves it up to the sender as to when the traffic .      is started.
Over-ride (Standby) indicates that the traffic sender .      continues to
use the currently active ASP until it can no longer .      send/receive
traffic (i.e., the currently active ASP transitions to .      Down or
Inactive).  At this point the sender MUST move the standby .      ASP to
Active and commence traffic.  Load-share (Standby) is similar .      - the
sender continues to load-share to the current ASPs until it is .
determined that there is insufficient resources in .      the Load-share
group.  When there are insufficient ASPs, the sender .      MUST move the
ASP to Active.
|      In Broadcast mode, the ASP will receive the identical traffic |
distribution as any other currently active ASPs.  The Standby |      version
of the Broadcast Type indicates that the ASP is declaring |      itself as
ready to accept traffic but leaves it up to the sender |      as to when the
traffic is started.  Broadcast (Standby) is |      similar to other Standby
modes in that the sending continues to |      broadcast traffic to the
current ASPs until it is determined that |      there are insufficient
resources in the Broadcast group.  When |      there are insufficient ASPs,
the sender MUST move the ASP to |      Active.

In Section 3.5.6 add ASPAC (broadcast (standby)) with the others.

Add to Section 4.1.1:

.   From the list of ASPs within the AS table, an Active ASP is selected .
and a DATA message is constructed and issued on the corresponding SCTP .
Association.  If more than one ASP is active (i.e., traffic is to be .
load-shared across all the active ASPs), one of the active ASPs from .   the
list is selected.  The selection algorithm is implementation .   dependent
but could, for example, be round-robin or based on, for .   example, the SLS
or ISUP CIC.  The appropriate selection algorithm must .   be chosen
carefully as it is dependent on application assumptions and .
understanding of the degree of state coordination between the active .
ASPs in the AS. 
|
|   In the Broadcast mode, all active ASP(s) are selected and a DATA |
message is constructed and issued on each of the corresponding SCTP |
Association(s).
|

Alter to Section 4.3.3.4 as follows:

|   There are six modes of Application Server traffic handling in the SG |
M3UA - Over-ride, Over-ride (Standby), Loadshare, Load-share |   (Standby),
Broadcast, and Broadcast (Standby).  The Traffic Mode .   Type parameter in
the ASPAC message indicates the traffic handling .   mode used in a
particular Application Server. If the SG determines .   that the mode
indicated in an ASPAC is unsupported or incompatible
    ...

Add to the end of Section 4.3.3.4 as follows:

|   In the case of a Broadcast mode AS, reception of an ASPAC message at |
an SG or IPSP causes the direction of traffic to the ASP sending the |
ASPAC, in addition to all other ASPs that are currently active in |   the
AS.  The SG MUST broadcast traffic to all of the active ASPs |   within the
AS.
|
|   As in the Load-share mode, an SG or IPSP, upon reception of an ASPAC |
for the first ASP in a Broadcast AS, MAY choose not to direct |   traffic to
a newly active ASP until it determines that there are |   sufficient
resources to handle the expected load (e.g., until there |   are sufficient
ASPs "Active" in the AS).
|
|   In the case of Broadcast (Standby) mode, the traffic is not started |
to the ASP until the SG or IPSP determines that there are |   insufficient
resources available in the AS.  This is likely when one |   of the active
broadcast ASPs transitions to the "Inactive" or "Down" |   state.  At this
point the ASP that sent the Broadcast (Standby) |   ASPAC is moved to the
Active state and traffic is started.  A second |   ASP-Active Ack message
with a new Traffic Mode Type ("Broadcast" |   previously "Broadcast
(Standby)") is sent to the ASP.  A Notify |   ("Insufficient ASP resources
active in AS") message is not sent in |   this case.
|
|   All ASPs within a broadcast mode AS must coordinate between |
themselves to determine which portion of the broadcast traffic they |   will
handle.

In the middle of Section 4.3.3.5 add:

|   In the case of a Broadcast mode AS, the SG moves the ASP to the |
"Inactive" state and the AS traffic is broadcast only to the |   remaining
"active" ASPs.  A NTFY(Insufficient ASP resources active |   in AS) may be
sent to all inactive ASPs, if required.  However, if a |   Broadcast
(Standby) ASP is available, it may be now immediately |   included in the
broadcast group and a Notify message is not sent.
|   An ASPIA Ack message is sent to the ASP after all traffic is halted |
and Layer Management is informed with an ASP-INACTIVE indication |
primitive.

And here's the rub: also add to Section 4.3.3.5:

|   Whenever an ASP in a Broadcast mode AS becomes active, the SG MUST |
tag the first DATA message broadcast in each SCTP stream with a |   unique
Correlation Id parameter.  The purpose of this Correlation Id |   is to
permite the newly active ASP to synchronize its processing of |   the
traffic in each ordered stream with other ASPs in the broadcast |   group.

Modify Section 4.3.3.6 to:

.   In the case where a Notify (AS-Pending) message is sent by an SG that .
now has no ASPs active to service the traffic, or a NTFY(Insufficient .
ASP resources active in AS) is sent in the Loadshare |   or Broadcast modes,
the Notify 
.   does not explicitly compel the ASP(s) receiving the message to become .
active. The ASPs remain in control of what (and when) traffic action is .
taken.

In my previous proposal make the Correlation Id parameter in the DATA
message Optional and you can remove the Correlation Id Ack if you'd like.

If you would like to rework this so that Broadcast is a separate algorithm
under Loadshare, that's fine too.  Just as long as the ASP can require
Broadcast algorithm and require the addition of a Correlation Id to messages
in each stream upon going active, I see no problem.

Now, as promised, here is the implementation: (This is not conjecture, I
have built them this way before.)

I have break down my ISUP application server into CIC ranges which
correspond to ISUP circuit management groups.  (Basically that is one AS per
24 circuits.)

I arrange at the SG to distribute messages over streams in each of the 16
(or more) associations by OPC/DPC/SLS/CIC to the maximum number of streams
permissible.  I have 16 ASPs which I register against all of the AS's in
Broadcast Mode.

Upon going up with a sufficient number of ASPs active, the ASPs begin
receiving traffic and each initial DATA message in each stream contains a
Correlation Id which the ASP uses as a sequence number to start numbering
the messages in each stream (I cannot be sure that the SSNs will be
synchronized at the SG).

Each ASP knows the other ASPs that are active in the broadcast group by
inter-ASP communication.  Each ASP knows the assignment of the other ASPs to
traffic (say, each ASP processes one of 16 streams according to it's ASP
number in the pool).  For it's assigned trafffic the ASP is Master.  For the
other 15 of 16 streams the ASP is Slave.

For messages received on the streams for which the ASP is Master the ASP
processes the message through its ISUP state machines and responds with
control messages and reply ISUP messages back to the SG.  For messages
received on the streams for which the ASP is Slave, the ASP processes the
message through its ISUP state machines but does not dispatch the controll
messages or ISUP replies.  It only moves through the state transitions.

After processing state transitions for streams upon which the ASP is Master,
the ASP also broadcasts the Stream Id and Correlation Id associated with the
message to the slave ASPs for that stream.  This checkpoints the slaves.

Each ASP, when processing messages on Slave streams should buffer incoming
messages long enough that the checkpoint from the Master for the stream (or
separate inter-ASP heartbeat) verifies the viability of the Master.
Therefore, each ASP is a Leader on its Master stream and a Follower on its
slave streams.

When an ASP fails, either through lost of inter-ASP checkpoint or heartbeat,
a prearranged ASP takes over as Master for the failed ASPs streams beginning
distribution of control and ISUP responses at the point which minimizes
duplication and discard.

With some good software design ;) this loosley coupled interlocking
leader-follower arrangement can perform well, has extremely low inter-ASP
sychronization overheads and has minimal message loss and call-state
mishandling.  Many low-reliability or low-performance ASPs can be grouped
into large arrays that scale well.

The difficulty in the arrangement come when adding an ASP to the group.
It must have a marker in the message streams upon which to start
synchonizing its behaviour.  It must replicate state from one of its peers
for the marked point before starting slave operation and subsequently master
operation on the traffic.  (The Broadcast (Standby) mode is really useless:
I don't intend to use it.)

This is where the Correlation Id come in.  I need it to mark the traffic for
synchronization with my ASP peers.  I would prefer if it was contained in
all DATA messages, however, if the SG will place it in the first DATA
message broadcast on any stream within a time interval from the transition
of an ASP from the "inactive" to "active" state within the broadcast group,
then the ASP can infer the correlation Id of the other messages from the
stream and the SSN.

Does this explain the need a little better?

On Thu, 31 May 2001, Ken Morneault wrote:

> 
> 
> Brian,
> 
> See below.
> 
> Ken
> 
> At 12:24 PM 5/31/01 -0500, Brian F. G. Bidulock wrote:
> >Ken,
> >
> >Per your 1) and 2):
> >
> >The M3UA ASP state diagrams do not distinguish between
> >SCTP CDI fatal and non-fatal.  The diagrams show the
> >ASP always moving to the DOWN state as a result of an
> >SCTP CDI.  The SG, in this case is required to send
> >messages to the standby ASP.
> 
> 
> Sorry, I do not value the Override-Standby option in ASP 
> Active and would not use it.  The decision regarding failover 
> should be made by the ASPs not the SG.  Clearly, the 
> SG does not have enough information to determine a 
> failover condition.  
> 
> See Section 5.2 for failover examples. 
> 
> There is no way to guarantee that there will
> be no messages lost during an ungraceful failover.
> Even with a "Correlation ID", it is highly likely that
> messages will be lost.  More importantly, some
> User Part state information will be lost (i.e. calls
> that are in setup phase).
> 
> Further, going back to your original message, how does
> M3UA determine when the message has been
> processed.  M3UA has no idea of when the
> message has been processed and the state information
> has been checkpointed by the User Part to the Standby 
> ASP.
> 
> 
> >As far as T(r) is concerned, the message have already
> >been delivered (or not) before T(r) is started.  I did
> >not have a problem with messages which arrive *after*
> >the SCTP CDI, just those that are sent *before* the
> >SCTP CDI.  So, T(r) doesn't help.
> >
> >I don't see where you have solved the problem that a
> >Correlation Id would easily solve.
> 
> My email only intended to layout scenarios of
> interest to see where and if problem(s) existed.   
> 
> >--Brian
> >

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 1 Jun 2001 01:04:04 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: [Fwd: Re: M2PA: Multiple streams]
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      BAA15935
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-231.dallas.net [209.44.42.231]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

Actually, I'd like to propose the use of an M2PA sequence number which is
outside that provided by SCTP and provide for a separate acknowledgement.
This is because SS7 links do not acknowledge messages which have not be
successfully delivered to MTP3 and it is difficult to get SCTP to withold
cumulative ACKs of messages which have been received by M2PA but not
delivered to MTP3.

Acking messages delivered to M2PA but not delivered to MTP3 will cause the
sending M2PA to be unable to retrieve these messages in the event of failure
between MTP3 and M2PA.  These cases are the Busy and Processor Outage cases
which M2PA is unable to correctly handle today.  M2PA can then be provided
with the option of using this M2PA generated sequence number on a per-stream
basis or a per-association basis as the implementation desires and in
fitting with the specific implementation of the NIF and existing MTP3 lower
interface implementations.

It should be possible to easily outfit M2UA with the same mechanism and
address Busy and Processor Outage difficulties which are even more sever in
the M2UA case where there is an SCTP assocation between the link and MTP3.

I had intended on discussing this over lunch with Tom George and a few
others next week.  I will report back on any conclusions reached then and
place a proposal forward.

--Brian

On Fri, 01 Jun 2001, Greg Sidebottom wrote:

> 
> ----- Original Message -----
> From: "Brian F. G. Bidulock" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Wednesday, May 30, 2001 2:40 PM
> Subject: Re: [Fwd: Re: M2PA: Multiple streams]
> 
> 
> Greg,
> 
> So, to sum up, can you see a reason not to permit multiple
> streams and using TSN instead of SSN?
> 
> --Brian
> 
> [Greg] I'm not sure yet - I need to think about this proposal a little
more.
> I was originally against restricting the M2PA to use of a single stream -
if
> you have found a way to take advantage of this then I am all ears.
> 
> Cheers,
> 
>    Greg
> 

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 1 Jun 2001 02:37:14 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA: Changes
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      CAA17206
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.231]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

While on the subject of changes, I would like to comment on a number of
other sections of the text of draft-ietf- m3ua-06.txt, as follows:

Section 1.3.2.1

        "The M3UA does not impose a 272-octet signaling
         information field (SIF) length limit as specified by the
         SS7 MTP Level 2 protocol [14] [15] [16].  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 inter-working 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 SG.  However, if
         the SS7 network is provisioned to support the Broadband
         MTP [20] to the final SS7 destination, the information
         block size limit may be increased past 272 octets."

There it is again.  This is well laid out in Q.701 in the description of the
MTP to MTP-User interface.  There is certainly no need to transcribe it
here.  What *is* required is the M3UA protocol elements which the SG (MTP)
uses to tell the AS (MTP-User(s)) what the maximum size is.

I propose that you change the text in Section 1.3.2.1 to read as follows:

    *   The MTP3 at the SG may impose limits on the size of the data
contained
    *   in an MTP-TRANSFER primitive [Q.701].  The M3UA does not impose any
    *   additional limits on the size of the message contained in an
    *   MTP-TRANSFER primitive beyond that required by the MTP3 at the SG.

And, enhancements to the Registration Results as follows:

    |   Registration Results:
    |   
    |      The Registration Results parameter contains one or more results, 
    |      each containing the registration status for a single Routing Key
in 
    |      an REG REQ message.  The number of results in a single REG RSP 
    |      message MAY match the number of Routing Key parameters found in
the 
    |      corresponding REG REQ message.  The format of each result is as 
    |      follows:
    |   
    |       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
    |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      |                  Local-RK-Identifier value                    |
    |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      |                      Registration Status                      |
    |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      |                        Routing Context                        |
    |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    *      |                  Maximum Protocol Data Size                   |
    *      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   
    |   Local-RK-Identifier: 32-bit integer
    |   
    |      The Local-RK-Identifier contains the same value as found in the
    |      matching Routing Key parameter found in the REG Req message.
    |   
    |   Registration Status: 32-bit integer
    |   
    |      The Registration Result Status field indicates the success or the

    |      reason for failure of a registration request.
    |   
    |      Its values may be:
    |   
    |           0           Successfully Registered
    |           1           Error - Unknown
    |           2           Error - Invalid DPC
    |           3           Error - Invalid Network Appearance
    |           4           Error - Invalid Routing Key
    |           5           Error - Permission Denied
    |           6           Error - Overlapping (Non-unique) Routing Key
    |           7           Error - Routing Key not Provisioned
    |           8           Error - Insufficient Resources
    |   
    |   Routing Context: 32-bit integer
    |   
    |      The Routing Context field contains the Routing Context value for
the
    |      associated Routing Key if the registration was successful. It is
set
    |      to "0" if the registration was not successful.
    *   
    *   Maximum Protocol Data Size: 32-bit unsigned integer
    *
    *      The Maximum Protocol Data Size field contains the maximum number
of
    *      bytes which may be place in a Protocol Data parameter in a
Payload
    *      Data Message (see Section 3.3.1)

You see, the smallest SIF which occurs on a route is the SIF to which the
MTP must require the MTP-User to adhere.  Perhaps it should be included in
additional M3UA messages, because is can change as a result of configuration
changes in the MTP3 of the SG while an ASP is active.

Section 1.3.2.3

        "   - Providing an indication to MTP3-Users at an ASP
              that messages to a remote MTP3-User peer in the
              SS7 network are experiencing SS7 congestion.

            - Providing an indication to MTP3-Users at an ASP
              that the routes to a remote MTP3-User peer in the
              SS7 network are restricted."

The MTP at the SG is not currently information that a remote MTP3-User peer
is congested.  It is only informed that a destination signalling point is
congested.  The same is true for restricted.  Replace this text with:

    *       - Providing an indication to MTP3-users at an ASP that messages
to a
    *         remote destination in the SS7 network is experiencing SS7
    *         congestion.
    *
    *       - Providing an indication to MTP3-users at an ASP that routes to
a
    *         remote destination in the SS7 network are restricted.

Section 1.3.3

        "The M3UA protocol is flexible enough to allow its
         operation and management in a variety of physical
         configurations, enabling Network Operators to meet their
         performance and reliability requirements."

This is quetionable given the current inablity of M3UA to avoid discarding
or duplicating messages on changeover between ASPs.
It is actually probable that the message loss will increase as the number of
lesser reliablity ASPs increases, even though one would that this increases
ASP availability, it actually decreases the ability of M3UA without
changeover to meet MTP3 transport requirements.

Section 1.3.3

        "M3UA imposes no restrictions as to the exact layout of
         the network elements, the message distribution
         algorithms and the distribution of the signalling
         processes."

Well, if you add a "broadcast" option in addition to over-ride and loadshare
then you will relieve one restriction M3UA places on the distribution
algorithm.

The other restriction is the view presented later in the document that the
SGP must each be equally able to transfer MSUs to the SS7 network and that
they are `instantly' available once their SCTP associations are formed.
This is a rather restricted case of SGP distribution which is imposed by
M3UA.

I would like to see both these restrictions lifted in fitting with the goals
of providing a general "framework" (or the false motherhood statement
removed).

Section 1.3.3

        "This example model can also be applied to IPSP-IPSP
         signalling.  In this case, each IPSP would have its
         services distributed across 2 hosts or more, and may
         have multiple server processes on each host."

I see nothing in the document precluding an IPSP from being equipped with
the transfer function as a sort of IPSTP.
Further, I see no reason why an SG providing service to an AS might not also
be an IPSP or an IPSTP.  Also, there appears to be no reasons why an AS
cannot also be a IPSP or IPSTP.

So, the question is what difference (if any) is there between an ASP and an
IPSP with regards to the protocol?  What difference (if any) is there
between an SG and an IPSP?
Should not an IPSP be able to register as an ASP with another IPSP and visa
versa?

Section 1.4.1

        "Within an SS7 network, a Signalling Gateway is charged
         with representing a set of nodes in the IP domain into
         the SS7 network for routing purposes.  The SG itself, as
         a physical node in the SS7 network, must be addressable
         with an SS7 Point Code for MTP3 Management purposes. The
         SG Point Code is also used for addressing any local
         MTP3- Users at the SG such as an SG-resident SCCP
         function."

Tone down the must to a might and make it an example.  It is certainly not
necessary for an SG to have its own point code or its own MTP3 management
procedures.  It is quite easy to concieve of a protocol conversion box which
sits at the end of an A-link link set and converts SS7 messages to M3UA
messages and visa versa without having a separately addressable point code.
You "must" here is an assumption rather than a requirement for operation in
either the SS7 network or M3UA.
The M3UA ASP has no knowledge of (nor does it need knowledge of) any SG
point code, and as such, one is not always necessary.
Replace this with:

    *   For example, within an SS7 network, a Signalling Gateway
    *   might be charged with representing a set of nodes in the
    *   IP domain into the SS7 network for routing purposes.
    *   The SG itself, as a physical node in the SS7 network,
    *   might also be addressable with an SS7 Point Code for
    *   MTP3 Management purposes. The SG Point Code might also
    *   used for addressing any local MTP3- Users at the SG such
    *   as an SG-resident SCCP function."

Section 1.4.1

        "Where Application Servers are grouped under a Point
         Code address, an SPMC will include more than one AS. If
         full advantage of SS7 management procedures is to be
         taken (as is advisable in carrier grade networks) care
         must be taken that, if one AS of an SPMC becomes
         unavailable, all Application Servers of the SPMC become
         unavailable from the SG.  Otherwise, usage of SS7
         transfer prohibited procedures by the SG becomes
         problematic as either traffic to the unavailable AS
         cannot be stopped/diverted or traffic to a still
         available AS will be unnecessarily stopped/diverted.
         (Depending on the network configuration it may even be
         necessary to assign an individual SS7 point code to each
         AS.)"

Strike this.  Again, from previous discussions on transfer prohibited
procedures, the procedure is only applicable when the MTP management
functions association with an SPMC become unavailable, not the
unavailability of the AS (the SPMC's MTP-Users or routing context partitions
of an MTP-User).

This approach to the NIF is invalid (at best) and certainly does not
necessitate the assignment of signalling point codes to individual AS,
something which is severly restricted in adminsitrations which utilize
16-bit signalling point codes in fully association signalling modes where
point code exhaustion is a serious issue.

Section 1.4.1

        "Where an AS can be reached via more than one SG it is
         equally important that the corresponding Routing Keys in
         the involved SGs are identical.  (Note: It is possible
         for the Routing Key configuration data to be temporarily
         out-of-synch during configuration updates).

Can you explain this?  I see no reason why the corresponding routing keys
need to by identical.  This is an unnecessary restriction on the
distribution framework (I may want 4 SG's and one AS with different routing
keys for 2 of the SG's than the other 2, for marketing purposes ;)

Section 1.4.1

        "Note: there is no SG-to-SG communication shown, so each
         SG can be reached only via the direct linkset from the
         SS7 network."

If you mean to say here that one SG cannot route messages to the ASPs via
the other SG, it does not follow from the diagram.
SG 1 (being an STP) can quite possibly be provisioned with a route to the
ASP via the STP on the left in the diagram.  SG 2's routing can also be set
to route as an alternate (lower priority) route via the STP on the left.  As
an STP, if SG 2 discovers that it cannot directly communicate with the ASP,
there is nothing stopping it from routing buffered data and any ariving data
for the ASP to the STP on the left, which (according to SS7 procedures)
would then be routed to the ASP via SG1.

My point here is, that although someone has gone to a lot of trouble to not
draw C-links in the diagram (although they make perfect sense), you cannot
preclude the ability of the SG acting as an STP to be provisioned to reroute
traffic in the network without also mandating what it's routing tables will
look like.

The absense of C-links from the diagram and the distinction that SG 2 can't
reach the ASP via SG 1 is a restriction which does not even simplify the
example!

Put the C-links in and remove the note.  Adding the C-links does not reduce
the generality of the model, it contributes to it.

Section 1.4.2.1

        "Keys are: the DPC alone, the DPC/OPC combination, the
         DPC/OPC/CIC"

I would suggest that you remove or qualify DPC alone in the example.  The
reason for this is that if you consider that DPC alone includes all SIO
field values, then that would also include SNMM and SNTM messages which you
have tried so hard to forbid from being "blindly passed" to the ASP.  If DPC
alone does not include all SIO field values, then it is merely a range of
user parts and is the same as the OPC, DPC, SIO stated before it.

Section 1.4.2.2

        "From an SS7 network perspective, a Routing Key is
         limited to within a single SS7 Destination Point Code.
         This is important, as the SG must be able to present
         this point code to the SS7 network, without compromising
         the integrity of the Signaling Point Management Cluster."

As previous discussions show, this is not important.  As long as the
management functions of the MTP3 are terminated at the SG, there is no need
for any such restriction.  Weaken this to:

    *   Some SS7 networks configurations or SG implementations
    *   may require that a Routing Key be limited to a single
    *   SS7 Destination Point Code.

Section 1.4.2.2

        "Routing Keys MUST be unique in the sense that a
         received SS7 signalling message cannot be matched to
         more than one Routing Key."

Please relax this statement in consideration of "Broadcast" groups where
overlapping AS may be to some advantage.

Section 1.4.2.5

        "Whenever an SCTP association to an SGP exists, it is
         assumed to be available.  Also, every SGP of one SG
         communicating with one ASP regarding one AS provides
         identical SS7 connectivity to this ASP."

Well... that statement might be a little off for Load-Share and broadcast
groups.  Where multiple ASPs in a Load-Share group or a Broadcast group are
connected to multiple SGP, the selection of SGP for outgoing message must be
a little bit better than arbitrary, if only from a sizing and capacity
perspective on the SG of the SGPs.

I would like to suggest that in a Load-share group or in a Broadcast group
that the ASP use some algorithm for determining the appropriate and active
SGP to which to send a message.

Further, the restriction that an SGP is available the moment that an SCTP
association is formed, (and even before an ASP has registered) is not
workable.  Perhaps from the moment that the ASP receives an M3UA message or
a response to an M3UA message (NTFY, ASPAC ACK, ASPIA ACK) from the SGP
would be a better starting point.

Section 1.4.3.1

        "The SG is responsible for terminating MTP Level 3 of
         the SS7 protocol, and offering an IP-based extension
         to its users."

SS7 MTP entities are identified by their signalling point code.
If the SG is responsible for "terminating" MTP, then the SG "owns" the point
code.  The SG must, therefore, be included in the definition of what makes
up a SPMC.

Section 1.4.3.1

        "It is possible for IP-based links to be present, using
         the services of the MTP2-User Adaptation Layer (M2UA)
         [19].  These SS7 datalinks may be terminated at a
         Signalling Transfer Point (STP) or at a Signalling End
         Point (SEP)."

I would certainly *not* call M2UA an IP-based link.  I *would* call M2PA an
IP-based link.  This description of M2UA is not consistent with M2UA and is
confusing when used alongside MTP-3b which *is* and ATM-based link.

Section 1.4.3.1

        "Where ATM-based High Speed Links are used in the SS7
         network, it is possible for the SG to use the services
         of the MTP-3b [20] for reliable transport to and from
         an SS7 SEP or STP. The maximum SIF length supported by
         the MTP-3b is 4095 octets compared to the 272-octet
         maximum of the MTP3.  However, for MTP3-Users to take
         advantage of the larger SDU between MTP3-User peers,
         network architects should ensure that MTP3-b is used
         end-to-end between the SG and the SS7-resident peer."

Why are you even saying this?  The maximum SIF supported by the MTP is one
of the pieces of information which must be provided at the MTP to MTP-User
interface per Q.701.  All that an MTP-User needs to know is what is the
maximum size of the data payload of an MTP-TRANSFER primitive.  It is then
the MTP-User's responsibility to restrict it's MTP-TRANSFER data payloads to
this maximum and perform whatever fragmentation and reassembly is required
at Level 4 and above to ensure that this maximum is not violated.

There is no need to preach to anyone about the use of MTP3-b or any other
link for that matter (you missed Q.703 Annex A) which have various SIFs.
Nor is it necessary to talk about the SIF values provided.  This is part of
MTP Level 3 design (far less the implementation of the NIF) and has no place
in the document.

What *is* required is the mechanism whereby the ASP can know what maximum
integral number of bytes can be present in the data payload of an
MTP-TRANSFER primitive (note that this does *not* include the routing label,
which is represented by parameters of the MTP-TRANSFER primitive).

(See proposal earlier on...)

Section 1.4.3.2

        "When the SG determines that the transport of SS7
         messages to an SPMC (or possibly to parts of an SPMC)
         is encountering congestion, the SG should inform the
         MTP3 route management function (by an implementation-
         dependent mechanism).  This information is used by the
         MTP3 to mark the "route" to the affected destination as
         congested and to trigger MTP Transfer Controlled (TFC)
         messages to any SS7 SEPs generating traffic to the
         congested DPC, as per current MTP3 procedures.

         When the SG determines that the transport of SS7
         messages to all ASPs in a particular SPMC is
         interrupted, then it should similarly inform the MTP3
         route management function.  This information is used by
         the MTP3 to mark the "route" to the affected
         destination as unavailable, and in the case of the SG
         acting as a signalling transfer point (i.e., the Point
         Code of the SG is different from that of the SPMC), to
         send MTP Transfer Prohibited (TFP) messages to the
         relevant adjacent SS7 nodes, according to the local SS7
         network procedures. 

         When the SG determines that the transport of SS7
         messages to an ASP in a particular SPMC can be resumed,
         the SG should similarly inform the MTP3 route
         management function.  This information is used by the
         MTP3 to mark the route to the affected destination as
         available, and in the case of a signalling transfer
         point, to send MTP Transfer Allowed (TFA) messages to
         the relevant adjacent SS7 nodes, according to the local
         SS7 network procedures.  

Strike the above per other discussion.

Section 1.4.3.2

        "It is important to clarify that MTP3 management
        messages such as TFPs or TFAs received from the SS7
        network are not "encapsulated" and sent blindly to the
        ASPs.  Rather, the existing MTP3 management procedures
        are followed within the MTP3 function of the SG to
        re-calculate the MTP3 route set status and to initiate
        any required signalling-route- set-test procedures into
        the SS7 network."
        
This is good text, but I quote it here because I would like to see a
clarification.  There is nothing (so far) which precludes this from
happening.  Perhaps this needs to be strenthened to:

        MTP3 management messages MUST NOT be encapsulated as
        DATA message Payload Data and send either from SG
        to ASP or from ASP to SG.  The SG MUST terminate
        these messages and generate M3UA messages as
        appropriate.

Note the other direction as well.  There is nothing stopping an ASP from
generating a TFP and sending it off somewhere with a bogus OPC.  (Actually
there is nothing stoppping the ASP from generating one by accident.  Perhaps
the SG should filter the ASP's data and remove any messages for user parts
for which the ASP is not registered or using any OPCs which do not
correspond to a PC of the AS to which the ASP belongs.)

Section 1.4.3.2

        "Only when an SS7 destination status changes are
        MTP-PAUSE or MTP-RESUME primitives invoked.  These
        primitives can also be invoked due to local SS7 link set
        conditions as per existing MTP3 procedures."

Strike the above per other discussion.

Section 1.4.3.2

        "When the SG discovers SS7 network isolation, the SG
         sends an indication to all concerned available ASPs
         (i.e., ASPs in the "active" or "inactive" state), using
         a DUNA message.  For the purposes of MTP Restart, all
         SPMCs with point codes different from that of the SG
         with at least one ASP that is active or that has sent an
         ASPAC message to the SG during the first part of the
         restart procedure should be considered as available.  If
         the M3UA at the SG receives any ASPAC messages during
         the restart procedure, it delays the ASPAC-ACK messages
         until the end of the restart procedure.  During the
         second part of the restart procedure the M3UA at the SG
         informs all concerned ASPs in the "active" or "inactive"
         state of any unavailable SS7 destinations.  At the end
         of the restart procedure the M3UA sends an ASPAC-ACK
         message to all ASPs in the "active" state."

Strike all this ASPAC stuff.  Remember: an ASP is an MTP-User, not the
management of the Point Code (MTP management).  The moment that the SG
becomes isolated, the normal procedure would be to inform the MTP-User parts
via MTP-PAUSE primitives of the inavailability of destinations to which the
MTP has provisioned routes.  That is not every point code in the world, that
is just point codes to which the signalling point has provisioned routes.

When the SG is no longer isolated, it indicates MTP-RESTART to all of its
user parts.  The user parts then know that subsequent MTP-RESUME primitives
do not yet permit the user part to send traffic to these destinations until
it is informed that MTP-RESTART-ENDS.

Now, it looks fine that a DUNA with a mask of 24 be used to indicate the
start of isolation and that a DAVA with a mask of 24 be used to indicate the
end of the MTP restart procedure.
So the syntax is there.

ASPs (which, again, are MTP-users) on the other hand can be allowed to go up
and down all that you want.  Traffic will not be restarted to the user parts
until the MTP restart procedure completes.  At that time, and in response to
specific messages, the MTP, default ASP, or implementation specific
procedure may return UPUs to the originator.

If an point code adjacent to the SG restarts (per Q.704 definition), it
might be advisable for the SG in accordance with its compliant MTP3 to
withold MTP-PAUSE and MTP-RESUME primitives from the user parts with respect
to routes becoming available to or via the restarting adjacent signalling
point until such time as the adjacent signalling point has completed the MTP
restart procedure and is ready to accept traffic.

Section 1.4.3.3

        "When an ASP enters the "Inactive" state towards an SG
         the M3UA must mark all SS7 destinations configured to be
         reachable via this SG as available."

There is no point in doing this.  There is no reason why an inactive ASP
should not receive DUNA and DAVA messages and keep track of the state of
concerned destinations, or for that matter, to at least DAUD the
destinations.  Only when the ASP goes from ASP-Down to ASP-Up would it be
advantageous to consider all destinations available and wait for responsive
DUNAs to update the ones that are not available.

Section 1.4.3.3

        "When the M3UA at an ASP receives a DUNA message
         indicating SS7 network isolation at an SG, it will stop
         any affected traffic via this SG and clear any
         unavailability state of SS7 destinations via this SG.
         When the M3UA subsequently receives any DUNA messages
         from an SG it will mark the effected SS7 destinations
         as unavailable via that SG.  When the M3UA receives an
         ASPAC-ACK message it can resume traffic to available
         SS7 destinations via this SG, provided the ASP is in
         the active state towards this SG."

I know that this mimics restart procedures, but what is the point in doing
this quite this way.  What is the point in erasing state information
concerning destinations which the SG is quite capable of remembering?
Remember that an AS which acts as an SCTP may have thousands of concerned
desitinations the status of each of which will be cleared and then must be
updated again by the SG, when the SG could have simply sent the delta.  If
the SG reboots or the ASP reboots, I can understand starting at the all
available position, but for simple isolation of the SG from the SS7 network,
there is no reason to go clearing things within the SPMC.  Updating 32 ASPs
individually with the fresh status of 1000 point codes could be quite an
onerous task.

Furthermore, there is isolation and then there is isolation.
MTP restart procedures apply equally well when a network is partitioned as
when a signalling point is completely isolated.
Isolation occurs to some part of the network whenever a signalling point
loses communication with an adjacent signalling point to which it has
critical routes.  Upon re-establishing communication to the adjacent
signalling point, the restart procedures are necessary.  There is surely no
need for the ASPs to clear the unavailability status of signalling routes
which do not pertain to the restarting adjacent SP.

Section 1.4.3.3 IPSP Considerations

        "Since IPSPs use M3UA in a point-to-point fashion, there
         is no concept of routing of messages beyond the remote
         end.  Therefore, SS7 and M3UA inter-working is not
         necessary for this model."

There are two sections numbered 1.4.3.3.

What precludes an IPSP from standing between an SG and an ASP as a sort of
IPSTP?

Section 1.4.4.1
 
        "All MTP3-User messages (e.g., ISUP, SCCP) incoming to
         an SG from the SS7 network are assigned to a unique
         Application Server, based on the information in the
         message and the provisioned Routing Keys."

Please alter to "one or more Application Servers" from "a unique Application
Server" to permit overlap of Routing Keys for load-share and broadcast
operation between AS.  In this situation, the routing key overlap could be
considered as a cause for the SG to load-share or broadcast over the
available AS's for messages at the intersection of the overlapping routing
keys.

Section 1.4.4.2

        "Whenever an SCTP association to an SGP exists, the SGP
         is assumed to be available.  Also, every SGP within an
         SG communicating with an ASP provides identical SS7
         connectivity to this ASP."

See comments on identical text under Section 1.4.2.5.

It would probably be a real bad idea to send traffic destined for the same
SLS (according to the SLS selection rules for ISUP and SCCP) to different
SGPs over different associations.  Lots of mis-sequencing could result.

Furthermore, different SGPs may become partitioned from each other in
different ways which would leave one SGP with an available route to a
destination and another without.  Because of this possibility, it is a poor
model which does not reflect real situations to attempt to treat all SGPs as
"identical".

In fact, multiple SGPs should be treated in a similar fashion to multiple
SGs.

Section 1.4.6

        "When an SG determines that the transport of SS7
         messages to a Signalling Point Management Cluster (SPMC)
         is encountering congestion, the SG should trigger SS7
         MTP3 Transfer Controlled management messages to
         originating SS7 nodes, as per current MTP3 procedures.
         The triggering of SS7 MTP3 Management messages from an
         SG is an implementation-dependent function."

         ... When an SG M3UA receives an SCON message from an
         ASP, and the SG determines that an SPMC is now
         encountering congestion, it should trigger SS7 MTP3
         Transfer Controlled management messages to concerned
         SS7 destinations according to current MTP procedures.

Vote to strike per other discussion.

I think that pretty much covers Section 1.  I will continue with comments on
other sections in a subsequent note.

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Schwarzbauer Hanns Juergen <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: [Fwd: Re: M2PA: Multiple streams]
Date: Fri, 1 Jun 2001 10:00:16 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: beamer.mchh.siemens.de
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [194.138.158.163]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

Comment inline

greetings

HannsJuergen

> -----Original Message-----
> From:	Brian F. G. Bidulock [SMTP:[email-masked]]
> Sent:	Friday, June 01, 2001 8:04 AM
> To:	sigtran
> Subject:	Re: [Fwd: Re: M2PA: Multiple streams]
> 
> Greg,
> 
> Actually, I'd like to propose the use of an M2PA sequence number
> which is outside that provided by SCTP and provide for a separate
> acknowledgement.  This is because SS7 links do not acknowledge
> messages which have not be successfully delivered to MTP3 and it is
> difficult to get SCTP to withold cumulative ACKs of messages which
> have been received by M2PA but not delivered to MTP3.
	[HJS]  sorry beeing ignorant on this sequence number, but as far as
my interpretation of the SDLs given in Q.703 is concerned:
	when basic reception control is informed about a "Signal Unit " (see
Q.703 Figure 14 (sheets 2 and 3 of 7) DAEDR -> RC) and this is not an LSSU,
it immediately prepares the acknowledgement of that MSU. There is no
feedback from MTP L3 indicationg it has accepted the "received message". In
my understanding it is always assumed that messages accepted by MTP L2 are
also successfully delivered to MTP L3 except MTP L3 used some more general
signals to prevent MTP L2 from working as usual, e.g. LPO.

> Acking messages delivered to M2PA but not delivered to MTP3 will
> cause the sending M2PA to be unable to retrieve these messages in
> the event of failure between MTP3 and M2PA.  These cases are the
> Busy and Processor Outage cases which M2PA is unable to correctly
> handle today.  M2PA can then be provided with the option of using
> this M2PA generated sequence number on a per-stream basis or a
> per-association basis as the implementation desires and in fitting
> with the specific implementation of the NIF and existing MTP3 lower
> interface implementations.
> 
> It should be possible to easily outfit M2UA with the same mechanism
> and address Busy and Processor Outage difficulties which are even
> more sever in the M2UA case where there is an SCTP assocation
> between the link and MTP3.
> 
> I had intended on discussing this over lunch with Tom George and a
> few others next week.  I will report back on any conclusions reached
> then and place a proposal forward.
> 
> --Brian
> 
> 
> On Fri, 01 Jun 2001, Greg Sidebottom wrote:
> 
> > 
> > ----- Original Message -----
> > From: "Brian F. G. Bidulock" <[email-masked]>
> > To: "sigtran" <[email-masked]>
> > Sent: Wednesday, May 30, 2001 2:40 PM
> > Subject: Re: [Fwd: Re: M2PA: Multiple streams]
> > 
> > 
> > Greg,
> > 
> > So, to sum up, can you see a reason not to permit multiple
> > streams and using TSN instead of SSN?
> > 
> > --Brian
> > 
> > [Greg] I'm not sure yet - I need to think about this proposal a little
more.
> > I was originally against restricting the M2PA to use of a single stream
- if
> > you have found a way to take advantage of this then I am all ears.
> > 
> > Cheers,
> > 
> >    Greg
> > 
> 
> -- 
> Brian F. G. Bidulock    > ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
> 
> 
> ---
> You are currently subscribed to sigtran as:
[email-masked]
> To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Schwarzbauer Hanns Juergen <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA: Changeover between ASPs
Date: Fri, 1 Jun 2001 10:12:21 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-MIME-Autoconverted: from 8bit to quoted-printable by
beamer.mchh.siemens.de 
                      id KAA12597
X-SMTP-HELO: beamer.mchh.siemens.de
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: beamer.mchh.siemens.de [194.138.158.163]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

comments inline

Furthernore: the subject says "M3UA..." but you obviously refer to M2PA. 

regards

HannsJuergen

> -----Original Message-----
> From:	Brian F. G. Bidulock [SMTP:[email-masked]]
> Sent:	Thursday, May 31, 2001 5:26 PM
> To:	sigtran
> Subject:	Re: M3UA: Changeover between ASPs
> 
> HannsJuergen,
> 
> On Thu, 31 May 2001, Schwarzbauer Hanns Juergen wrote:
> 
> > in my understanding you are proposing a sequential numbering
> > of all payload data messages and sending back a piggybacked
> > acknowledgement later.  Without having a detailed message
> > flow, I do not see how this should work in any circumstances,
> > e.g. the message back to the SG is queued but then backhoe
> > starts its work. 
> 
> 
> An SGP and an ASP have an association which they are merrily
> tranfering data on:  (Consider one direction and one stream
> for simplicity)
> 
>   MTP3     SGP      SCTP      Network     SCTP     ASP      MTP3
>         |        |        |            |        |        |        
>         |        |        |            |        |        |        
> TRANSFER|  DATA  | TSN 50 |\           |        |        |        
> TRANSFER|  DATA  | TSN 51 |\\          |        |        |        
> TRANSFER|  DATA  | TSN 52 |\\\         |        |        |        
> TRANSFER|  DATA  | TSN 53 |\\\\        |        |        |        
> TRANSFER|  DATA  | TSN 54 |\\\\\       |        |        |        
> TRANSFER|  DATA  | TSN 55 |\\\\\\      |        |        |        
> TRANSFER|  DATA  | TSN 56 |\\\\\\\     |        |        |        
> TRANSFER|  DATA  | TSN 57 |\\\\\\\\    |        |        |        
> TRANSFER|  DATA  | TSN 58 |\\\\\\\\\   |        |        |        
>         |        |        | \\\\\\\\\  |        |        |        
>         |        |        |  \\\\\\\\\ |        |        |        
>         |        |        |   \\\\\\\\\|        |        |        
>         |        |        |    \\\\\\\X| TSN 50 |  DATA  |TRANSFER
>         |        |        |     \\\\\XX| TSN 51 |  DATA  |TRANSFER
>         |        |        |      \\\XXX| TSN 52 |  DATA  |TRANSFER
>         |        |        |       \XXXX| TSN 53 |  DATA  |TRANSFER
>         |        |        |       /XXXX| TSN 54 |  DATA  |TRANSFER
>         |        |        |      ///XXX| TSN 55 |  DATA  |TRANSFER
>         |        |        |     /////XX| TSN 56 |  DATA  |TRANSFER
>         |        |        |    ///////X| TSN 57 |  DATA  |TRANSFER
>         |        |        |   //////// | TSN 58 |  DATA  |TRANSFER
>         |        |        |  ////////  |        |        |        
>         |        |        | ////////   |        |        |        
>         |        | SACK 50|////////    |        |        |        
>         |        | SACK 51|///////     |        |        |        
>         |        | SACK 52|//////      |        |        |        
>         |        | SACK 53|/////       |        |        |        
> ---------SCTP CDI--ABORT--|+           |        |        |        
>         |        |        | -+         |        |        |        
>         |        |        |   -+       |        |        |        
>         |        |        |     -+     |        |        |        
>         |        |        |       -+   |        |        |        
>         |        |        |         -+ |        |        |        
>         |        |        |            |-ABORT--|SCTP CDI|--------
>         |        |        |            |        |        |        
>         |        |        |            |        |        |        
>         |        |        |            |        |        |        
> 
> Which messages does the SGP send to the standby ASP?  If it
> sends those that were numbered TSN 50 through 58 it will
> duplicate all of them.  According to the MTP-User's
> expectations, it would not be able to duplicate or mis-sequence
> another MSU in the next 90,000,000,000 MSUs.  If it discards> 
> them it runs the risk of message loss on TSNs 54 through 58.
> According to the MTP-User's expectations it would have to not
> lose another MSUs in then next 40,000,000 MSUs for any reason.
> 
> Does that help?
	[HJS]  not at all, as this picture tells nothing about the potential
change-over processes occurring in the SS7 network! In case you redirect the
SS7 traffic to another SGP I seriously doubt the proposal.
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
> 
> 
> ---
> You are currently subscribed to sigtran as:
[email-masked]
> To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Schwarzbauer Hanns Juergen <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA: Changeover between ASPs
Date: Fri, 1 Jun 2001 10:20:22 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: beamer.mchh.siemens.de
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: beamer.mchh.siemens.de [194.138.158.163]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

hi,

sorry to insist:

these are the requirements that MTP L3/L2/L1 have to meet. 
In my understanding M3UA belongs to the User Part.

regards

HannsJuergen

> -----Original Message-----
> From:	Brian F. G. Bidulock [SMTP:[email-masked]]
> Sent:	Thursday, May 31, 2001 7:16 PM
> To:	sigtran
> Subject:	Re: M3UA: Changeover between ASPs
> 
> MannsJuergen,
> 
> You are mistaken.  See Q.701/4.5.2 and Q.706.
> 
> These numbers are the expectations of MTP-Users of the MTP.
> 
> --Brian
> 
> 
> On Thu, 31 May 2001, Schwarzbauer Hanns Juergen wrote:
> 
> > Hi Brian,
> > 
> > only one single remark:
> > 
> > the reliablity figures you are using below are relevant for MTP Level 2!
> > 
> > IMHO we should here talk about "Call Failure Rates" instead. they are
> > certainly not in the region of 1% but definitely not 10E-07! Operators
might
> > tell us their CFR's if they are willing to do so, perhaps there might be
an
> > answer from Telcordia.
> > 
> > 
> > HannsJuergen
> > 
> 
> -- 
> Brian F. G. Bidulock    > ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
> 
> 
> ---
> You are currently subscribed to sigtran as:
[email-masked]
> To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Fri, 1 Jun 2001 10:31:18 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades6.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mailhost2.atea.be [194.78.143.126]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Klaus,

Yes, with this concept of "AMF" (address mapping function ... why not "SRF"
SUA relay function ...) SUA could really do without the routing key things.
What I have in mind is following black box, either at a SG or an ASP or an
SUA relay node in general :

Incoming message (either from SS7, with MTP routing label and SCCP
parameters, or from IP, with SCTP header and SUA parameters)

==> pass to SRF for analysis and determine :
	- whether the message must be passed to a local user
	- whether the message must be "relayed on" to either an SS7
destination (IP -> SS7 at SG) or to an IP destination (SS7 -> IP at SG or
all-IP case)

Any information can be used/provisioned for this purpose. One may call it an
enhanced GTT, because it can be based on IP address, GT, host name, ...

My comment on DPC+SSN only applied to "valid address information in the
incoming message". Just a point code won't do either as called (who's going
to handle it) as calling (backrouting ?) address. Of course, the SRF may or
may not take this SSN into account. E.g. the SG may forward every SS7 SCCP
message routed on DPC+SSN (and received from certain OPCs) to the ASPs of a
specified AS without further consideration to SSN.

The IP address is strictly an SUA address parameter. For interworking with
SS7, one endpoint only has the DPC+SSN or GT options. You can of course put
an IP(v4) address in your GT, or convert a GT to an IPaddress (ENUM and DNS)
...

Actually, what GTT or SRF should derive locally, is merely a "handle" to the
next hop, e.g.
- a route set number, by which MTP knows the routeset and DPC to go to - an
SCTP association ID, by which SCTP knows the (multihomed) route and IP
address to go to
- of course, this "handle" could be the DPC and/or IP address itself, e.g.
if you use ENUM/DNS means to translate your E.164 stuff.

The SRF will avoid having to have a fully meshed SCTP (or transport)
network.

Greetings,

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Gradischnig, Klaus [mailto:[email-masked]] Sent:
donderdag 31 mei 2001 23:14
To: sigtran
Subject: RE: SUA5: Address Mapping text

Gery,

trying to catch up.

I am confused by your comment:

the text talks about Routing Keys, not address information in the message.
Why is it not allowed to have a DPC as routing key w/o an SSN, thus
specifying that all SSNs for that DPC are served by the RK?

Also, where is the IP address coming from? Not from the SS7 network. 
If it comes from an ASP, then we have an IP-Relay node, which I like. 
Or does it also come from the local GTT?

Klaus

> -----Original Message-----
> From: Verwimp Gery [mailto:[email-masked]]
> Sent: May 11, 2001 8:03 AM
> To: sigtran
> Subject: RE: SUA5: Address Mapping text
> 
> 
> 2 comments :
> 
> - with DPC or IP address, ALWAYS a valid SSN has to be 
> present. With this
> the end-SUA has to address it's user; we have to keep this 
> interface with
> the user.
> 
> - does an ASP still have to know the concept of SG-SGP ?
> 
> greetings,
> 
> ____________________________
> 
> Gery Verwimp
> > SIEMENS ATEA
> > ICN D CS D5
> > 
> > Tel. : +32 14 25 3424
> Fax : +32 14 25 3212
> mailto:[email-masked]
> ____________________________________
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: donderdag 10 mei 2001 12:17
> To: sigtran
> Subject: SUA5: Address Mapping text
> 
> 
> Hi all, 
> 
> There has been some discussion as of late on SUA / GTT / ENUM 
> / etc.  I have
> updated the text.  Please comment.
> 
> br,
> John
> 
> 1.5 Internal Functions Provided in the SUA Layer 
> 
> It is assumed that Global Title Translation (GTT) occurs 
> outside of SUA.
> However, SUA will need to map the output of the GTT process, when
> applicable, to an ASP via an Address Mapping Function (AMF).  
> 
> When SS7 addressing is used by the upper layer protocol, SUA 
> will need to
> determine the correct signaling endpoint.  How this is done is
> implementation specific, but it could involve DNS [ENUM] or local
> configuration information.
> 
> 1.5.1 Address Translation and Mapping at the SG
> 
> The SG MUST provide address translation and mapping functions 
> to direct
> messages received from the SS7 network to the appropriate IP 
> destination.
> 
> In order to support message distribution, the SG maintains an address
> translation table, which maps the incoming SS7 messages to 
> the appropriate
> AS.  The relevant fields of the incoming SS7 message is 
> compared to the
> existing Routing Keys.  The Routing Keys reference an 
> Application Server,
> which will have one or more ASPs processing traffic for the AS.  The
> availability and status of the ASPs is handled by SUA ASP management
> messages.
> 
> Possible SS7 address/routing information that comprise 
> a Routing Key entry includes, for example, OPC, DPC, SIO found in 
> the MTP3 routing label, or other specific fields such as the 
> SCCP subsystem number, or TCAP transaction ID. Some 
> possibilities include:
> 
> 	Global Title (+ SSN optionally)
> 	PC (+ SSN optionally)
> 	Host Name (+ SSN optionally)
> 	IP Address(es) (+ SSN optionally)
> 
> An Application Server maintains a list of ASPs that are 
> available to process
> the traffic.  The list is dynamic, based upon the availability of the
> individual ASPs in the list.  SUA ASP management messages are 
> used to convey
> the status of these ASPs and their availability in failover 
> situations.
> 
> Normally, one or more ASPs areis active in the ASP (i.e., currently
> processing traffic) but in certain failure and transition cases it is
> possible that there may not be an active ASP available. The 
> SG will buffer
> the message destined for this AS for a time T(r) or until an 
> ASP becomes
> available. When no ASP becomes available before expiry of 
> t(r), the SG will
> flush the buffered messages and initiate the appropriate 
> return or refusal
> procedures. 
> 
> Both load-sharing and backup scenarios are supported.
> 
> If there is no Routing Key match for an incoming SS7 message, 
> a default
> treatment MUST be specified.  Possible solutions are to 
> provide a default
> Application Server to direct all unallocated traffic to a 
> (set of) default
> ASP(s), or to drop the messages and provide a notification to 
> management.
> The treatment of unallocated traffic is implementation dependent.
> 
> 1.5.2 Address Translation and Mapping at the ASP
> 
> In order to direct messages to the SS7 network, the ASP must 
> also perform an
> address translation and mapping function in order to choose 
> the proper SG or
> SGP for a given message.  This is accomplished by observing 
> the Destination
> Point Code and other elements of the outgoing message, SS7 
> network status,
> SG and SGP availability, and network appearance configuration tables.
> 
> A remote Signaling Gateway may be composed of one or more 
> SGPs.  that are
> capable of routing SS7 traffic.  As is the case with ASPs, a 
> dynamic list of
> SGPs in an SG can be maintained, taking into account the 
> availability status
> of the individual SGPs, configuration changes and fail-over 
> mechanisms.
> There is, however, no SUA messaging to manage the status of 
> an SGP. Whenever
> an SCTP association to an SGP exists, it is assumed to be 
> available.  Also,
> every SGP of one SG communicating with one ASP regarding one 
> AS provides
> identical SS7 connectivity to this ASP.
> 
> 1.5.3 SCTP Stream Mapping
> 
> The SUA supports SCTP streams. The SG/AS needs to maintain a 
> list of SCTP
> and SUA-users for mapping purposes.  SCCP-users requiring 
> sequenced message
> transfer need to be sent over a stream supporting sequenced delivery.
> 
> SUA MUST use stream 0 for SUA management messages. It is 
> recommended that
> sequenced delivery is usedbe in order to preserve the order 
> of management
> message delivery.
> 
> 
> ---
> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to
> [email-masked]
> 
> 
> ---
> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Robert Gahan <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Good SIGTRAN primer or tutorial ?.
Date: Fri, 1 Jun 2001 09:39:25 +0100
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-SMTP-HELO: relay06.indigo.ie
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [194.125.133.230]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type> <META
content="MSHTML 5.00.2614.3500" name=GENERATOR> <STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial>
<DIV><FONT face=Arial>Hi there, </FONT></DIV> <DIV>&nbsp;</DIV>
<DIV><FONT face=Arial>Can anybody recommend a good sigtran primer
or</FONT></DIV>
<DIV><FONT face=Arial>tutorial. Are any available at this stage ?.
</FONT></DIV> <DIV><FONT face=Arial>&nbsp;&nbsp;&nbsp; </FONT></DIV>
<DIV><FONT face=Arial>Thanks,</FONT></DIV> <DIV><FONT face=Arial>Rob.
</FONT></DIV></FONT></DIV> ---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY></HTML>

</x-html>
Reply-To: [email-masked]
From: srikanth <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: snmp draft for m2ua
Date: Fri, 1 Jun 2001 15:24:20 +0530
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-SMTP-HELO: india.mercurykr.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [165.133.13.60]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hi

Why there is no IETF draft for  SNMP Management information base for M2UA.

srikanth

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Schwarzbauer Hanns Juergen <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Good SIGTRAN primer or tutorial ?.
Date: Fri, 1 Jun 2001 12:14:04 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: gorilla.mchh.siemens.de
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: gorilla.mchh.siemens.de [194.138.158.18]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

There was an E-Mail end of October last year from Andreas Jungmaier pointing
to the following URL:

http://tdrwww.exp-math.uni-essen.de/pages/forschung/for3.html

perhaps this is what you are looking for.

regards

Hannsjuergen

> -----Original Message-----
> From:	Robert Gahan [SMTP:[email-masked]]
> Sent:	Friday, June 01, 2001 10:39 AM
> To:	sigtran
> Subject:	Good SIGTRAN primer or tutorial ?.
> 
> Hi there, 
>  
> Can anybody recommend a good sigtran primer or
> tutorial. Are any available at this stage ?. 
>     
> Thanks,
> Rob. 
> ---
> You are currently subscribed to sigtran as:
[email-masked]
> To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Satish K <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: SG-MGC
Date: Fri, 1 Jun 2001 16:08:47 +0530
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MIMETrack: Itemize by SMTP Server on Mailserver/ConvergSoft(Release 5.0.3 
             (Intl)|21 March 2000) at 06/01/2001 04:13:37 PM, Serialize by 
             Router on Mailserver/ConvergSoft(Release 5.0.3 (Intl)|21 March 
             2000) at 06/01/2001 06:40:38 PM, Serialize complete at
06/01/2001 
             06:40:38 PM
X-SMTP-HELO: mailserver.convergsoft.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [203.197.163.36]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi All,
   Why do we need MGC's in the SS7 Over IP world. 
ie from SG why do we need to connect to MGC not another SG.

satish

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Fri, 01 Jun 2001 07:08:12 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: snmp draft for m2ua
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [161.44.85.169]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

No one has produced a M2UA MIB draft.  Feel free to do so.

Regards,

Ken

At 03:24 PM 6/1/01 +0530, you wrote:
>Hi
>
>Why there is no IETF draft for  SNMP Management information base for M2UA.
>
>srikanth
>
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Miriyala Srinivas-FSM016 <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Fri, 1 Jun 2001 09:45:35 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: motgate2.mot.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: motgate2.mot.com [136.182.1.10]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hello Verwimp,

I think it is really good idea. I am not too excited about the using SRF
becomes it implies that it always have to forward the message to other
nodes. But the concept you mentioned would clarify quite a few things and
addresses all scenarios. 

Regards
Srini

-----Original Message-----
From: Verwimp Gery [mailto:[email-masked]] Sent: Friday, June
01, 2001 3:31 AM
To: sigtran
Subject: RE: SUA5: Address Mapping text

Hi Klaus,

Yes, with this concept of "AMF" (address mapping function ... why not "SRF"
SUA relay function ...) SUA could really do without the routing key things.
What I have in mind is following black box, either at a SG or an ASP or an
SUA relay node in general :

Incoming message (either from SS7, with MTP routing label and SCCP
parameters, or from IP, with SCTP header and SUA parameters)

==> pass to SRF for analysis and determine :
	- whether the message must be passed to a local user
	- whether the message must be "relayed on" to either an SS7
destination (IP -> SS7 at SG) or to an IP destination (SS7 -> IP at SG or
all-IP case)

Any information can be used/provisioned for this purpose. One may call it an
enhanced GTT, because it can be based on IP address, GT, host name, ...

My comment on DPC+SSN only applied to "valid address information in the
incoming message". Just a point code won't do either as called (who's going
to handle it) as calling (backrouting ?) address. Of course, the SRF may or
may not take this SSN into account. E.g. the SG may forward every SS7 SCCP
message routed on DPC+SSN (and received from certain OPCs) to the ASPs of a
specified AS without further consideration to SSN.

The IP address is strictly an SUA address parameter. For interworking with
SS7, one endpoint only has the DPC+SSN or GT options. You can of course put
an IP(v4) address in your GT, or convert a GT to an IPaddress (ENUM and DNS)
...

Actually, what GTT or SRF should derive locally, is merely a "handle" to the
next hop, e.g.
- a route set number, by which MTP knows the routeset and DPC to go to - an
SCTP association ID, by which SCTP knows the (multihomed) route and IP
address to go to
- of course, this "handle" could be the DPC and/or IP address itself, e.g.
if you use ENUM/DNS means to translate your E.164 stuff.

The SRF will avoid having to have a fully meshed SCTP (or transport)
network.

Greetings,

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Gradischnig, Klaus [mailto:[email-masked]] Sent:
donderdag 31 mei 2001 23:14
To: sigtran
Subject: RE: SUA5: Address Mapping text

Gery,

trying to catch up.

I am confused by your comment:

the text talks about Routing Keys, not address information in the message.
Why is it not allowed to have a DPC as routing key w/o an SSN, thus
specifying that all SSNs for that DPC are served by the RK?

Also, where is the IP address coming from? Not from the SS7 network. 
If it comes from an ASP, then we have an IP-Relay node, which I like. 
Or does it also come from the local GTT?

Klaus

> -----Original Message-----
> From: Verwimp Gery [mailto:[email-masked]]
> Sent: May 11, 2001 8:03 AM
> To: sigtran
> Subject: RE: SUA5: Address Mapping text
> 
> 
> 2 comments :
> 
> - with DPC or IP address, ALWAYS a valid SSN has to be 
> present. With this
> the end-SUA has to address it's user; we have to keep this 
> interface with
> the user.
> 
> - does an ASP still have to know the concept of SG-SGP ?
> 
> greetings,
> 
> ____________________________
> 
> Gery Verwimp
> > SIEMENS ATEA
> > ICN D CS D5
> > 
> > Tel. : +32 14 25 3424
> Fax : +32 14 25 3212
> mailto:[email-masked]
> ____________________________________
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: donderdag 10 mei 2001 12:17
> To: sigtran
> Subject: SUA5: Address Mapping text
> 
> 
> Hi all, 
> 
> There has been some discussion as of late on SUA / GTT / ENUM 
> / etc.  I have
> updated the text.  Please comment.
> 
> br,
> John
> 
> 1.5 Internal Functions Provided in the SUA Layer 
> 
> It is assumed that Global Title Translation (GTT) occurs 
> outside of SUA.
> However, SUA will need to map the output of the GTT process, when
> applicable, to an ASP via an Address Mapping Function (AMF).  
> 
> When SS7 addressing is used by the upper layer protocol, SUA 
> will need to
> determine the correct signaling endpoint.  How this is done is
> implementation specific, but it could involve DNS [ENUM] or local
> configuration information.
> 
> 1.5.1 Address Translation and Mapping at the SG
> 
> The SG MUST provide address translation and mapping functions 
> to direct
> messages received from the SS7 network to the appropriate IP 
> destination.
> 
> In order to support message distribution, the SG maintains an address
> translation table, which maps the incoming SS7 messages to 
> the appropriate
> AS.  The relevant fields of the incoming SS7 message is 
> compared to the
> existing Routing Keys.  The Routing Keys reference an 
> Application Server,
> which will have one or more ASPs processing traffic for the AS.  The
> availability and status of the ASPs is handled by SUA ASP management
> messages.
> 
> Possible SS7 address/routing information that comprise 
> a Routing Key entry includes, for example, OPC, DPC, SIO found in 
> the MTP3 routing label, or other specific fields such as the 
> SCCP subsystem number, or TCAP transaction ID. Some 
> possibilities include:
> 
> 	Global Title (+ SSN optionally)
> 	PC (+ SSN optionally)
> 	Host Name (+ SSN optionally)
> 	IP Address(es) (+ SSN optionally)
> 
> An Application Server maintains a list of ASPs that are 
> available to process
> the traffic.  The list is dynamic, based upon the availability of the
> individual ASPs in the list.  SUA ASP management messages are 
> used to convey
> the status of these ASPs and their availability in failover 
> situations.
> 
> Normally, one or more ASPs areis active in the ASP (i.e., currently
> processing traffic) but in certain failure and transition cases it is
> possible that there may not be an active ASP available. The 
> SG will buffer
> the message destined for this AS for a time T(r) or until an 
> ASP becomes
> available. When no ASP becomes available before expiry of 
> t(r), the SG will
> flush the buffered messages and initiate the appropriate 
> return or refusal
> procedures. 
> 
> Both load-sharing and backup scenarios are supported.
> 
> If there is no Routing Key match for an incoming SS7 message, 
> a default
> treatment MUST be specified.  Possible solutions are to 
> provide a default
> Application Server to direct all unallocated traffic to a 
> (set of) default
> ASP(s), or to drop the messages and provide a notification to 
> management.
> The treatment of unallocated traffic is implementation dependent.
> 
> 1.5.2 Address Translation and Mapping at the ASP
> 
> In order to direct messages to the SS7 network, the ASP must 
> also perform an
> address translation and mapping function in order to choose 
> the proper SG or
> SGP for a given message.  This is accomplished by observing 
> the Destination
> Point Code and other elements of the outgoing message, SS7 
> network status,
> SG and SGP availability, and network appearance configuration tables.
> 
> A remote Signaling Gateway may be composed of one or more 
> SGPs.  that are
> capable of routing SS7 traffic.  As is the case with ASPs, a 
> dynamic list of
> SGPs in an SG can be maintained, taking into account the 
> availability status
> of the individual SGPs, configuration changes and fail-over 
> mechanisms.
> There is, however, no SUA messaging to manage the status of 
> an SGP. Whenever
> an SCTP association to an SGP exists, it is assumed to be 
> available.  Also,
> every SGP of one SG communicating with one ASP regarding one 
> AS provides
> identical SS7 connectivity to this ASP.
> 
> 1.5.3 SCTP Stream Mapping
> 
> The SUA supports SCTP streams. The SG/AS needs to maintain a 
> list of SCTP
> and SUA-users for mapping purposes.  SCCP-users requiring 
> sequenced message
> transfer need to be sent over a stream supporting sequenced delivery.
> 
> SUA MUST use stream 0 for SUA management messages. It is 
> recommended that
> sequenced delivery is usedbe in order to preserve the order 
> of management
> message delivery.
> 
> 
> ---
> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to
> [email-masked]
> 
> 
> ---
> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Gradischnig, Klaus" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Fri, 1 Jun 2001 09:46:37 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: dnspri.npac.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: dnspri.npac.com [208.143.33.66]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hallo Gery,

sounds good. Just a few comments in-line.

One thing I don't have a handle on yet is what if anything additionally SUA
has to do to support failure/congestion cases in the all IP (and perhaps
also the SS7 - IP) case? 

Klaus

> -----Original Message-----
> From: Verwimp Gery [mailto:[email-masked]]
> Sent: June 01, 2001 4:31 AM
> To: sigtran
> Subject: RE: SUA5: Address Mapping text
> 
> 
> Hi Klaus,
> 
> Yes, with this concept of "AMF" (address mapping function ... 
> why not "SRF"
> SUA relay function ...) SUA could really do without the 
> routing key things.
> What I have in mind is following black box, either at a SG or 
> an ASP or an
> SUA relay node in general :
> 
> Incoming message (either from SS7, with MTP routing label and SCCP
> parameters, or from IP, with SCTP header and SUA parameters)

You may also want to include the IP address parameters, or?

> 
> ==> pass to SRF for analysis and determine :
> 	- whether the message must be passed to a local user
> 	- whether the message must be "relayed on" to either an SS7
> destination (IP -> SS7 at SG) or to an IP destination (SS7 -> 
> IP at SG or
> all-IP case)
> 
> Any information can be used/provisioned for this purpose. One 
> may call it an
> enhanced GTT, because it can be based on IP address, GT, host 
> name, ...

IP address should be allowed as GT address info. Destination IP address in
the IP label is perhaps also useful in case the node has multiple IP
addresses. 

> 
> My comment on DPC+SSN only applied to "valid address 
> information in the
> incoming message". Just a point code won't do either as 
> called (who's going
> to handle it) as calling (backrouting ?) address. Of course, 
> the SRF may or
> may not take this SSN into account. E.g. the SG may forward 
> every SS7 SCCP
> message routed on DPC+SSN (and received from certain OPCs) to 
> the ASPs of a
> specified AS without further consideration to SSN.
>
> 
> The IP address is strictly an SUA address parameter. For 
> interworking with
> SS7, one endpoint only has the DPC+SSN or GT options. You can 
> of course put
> an IP(v4) address in your GT, or convert a GT to an IPaddress 
> (ENUM and DNS)
> ...
> 
> 
> Actually, what GTT or SRF should derive locally, is merely a 
> "handle" to the
> next hop, e.g.
> - a route set number, by which MTP knows the routeset and DPC to go to
> - an SCTP association ID, by which SCTP knows the 
> (multihomed) route and IP
> address to go to
> - of course, this "handle" could be the DPC and/or IP address 
> itself, e.g.
> if you use ENUM/DNS means to translate your E.164 stuff.
> 
> The SRF will avoid having to have a fully meshed SCTP (or transport)
> network.
> 
> Greetings,
> 
> ____________________________
> 
> Gery Verwimp
> > SIEMENS ATEA
> > ICN D CS D5
> > 
> > Tel. : +32 14 25 3424
> Fax : +32 14 25 3212
> mailto:[email-masked]
> ____________________________________
> 
> 
> -----Original Message-----
> From: Gradischnig, Klaus [mailto:[email-masked]]
> Sent: donderdag 31 mei 2001 23:14
> To: sigtran
> Subject: RE: SUA5: Address Mapping text
> 
> 
> Gery,
> 
> trying to catch up.
> 
> I am confused by your comment:
> 
> the text talks about Routing Keys, not address information in 
> the message.
> Why is it not allowed to have a DPC as routing key w/o an SSN, thus
> specifying that all SSNs for that DPC are served by the RK?
> 
> Also, where is the IP address coming from? Not from the SS7 network. 
> If it comes from an ASP, then we have an IP-Relay node, which I like. 
> Or does it also come from the local GTT?
> 
> Klaus
> 
> > -----Original Message-----
> > From: Verwimp Gery [mailto:[email-masked]]
> > Sent: May 11, 2001 8:03 AM
> > To: sigtran
> > Subject: RE: SUA5: Address Mapping text
> > 
> > 
> > 2 comments :
> > 
> > - with DPC or IP address, ALWAYS a valid SSN has to be 
> > present. With this
> > the end-SUA has to address it's user; we have to keep this 
> > interface with
> > the user.
> > 
> > - does an ASP still have to know the concept of SG-SGP ?
> > 
> > greetings,
> > 
> > ____________________________
> > 
> > Gery Verwimp
> > > SIEMENS ATEA
> > > ICN D CS D5
> > > 
> > > Tel. : +32 14 25 3424
> > Fax : +32 14 25 3212
> > mailto:[email-masked]
> > ____________________________________
> > 
> > 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: donderdag 10 mei 2001 12:17
> > To: sigtran
> > Subject: SUA5: Address Mapping text
> > 
> > 
> > Hi all, 
> > 
> > There has been some discussion as of late on SUA / GTT / ENUM 
> > / etc.  I have
> > updated the text.  Please comment.
> > 
> > br,
> > John
> > 
> > 1.5 Internal Functions Provided in the SUA Layer 
> > 
> > It is assumed that Global Title Translation (GTT) occurs 
> > outside of SUA.
> > However, SUA will need to map the output of the GTT process, when
> > applicable, to an ASP via an Address Mapping Function (AMF).  
> > 
> > When SS7 addressing is used by the upper layer protocol, SUA 
> > will need to
> > determine the correct signaling endpoint.  How this is done is
> > implementation specific, but it could involve DNS [ENUM] or local
> > configuration information.
> > 
> > 1.5.1 Address Translation and Mapping at the SG
> > 
> > The SG MUST provide address translation and mapping functions 
> > to direct
> > messages received from the SS7 network to the appropriate IP 
> > destination.
> > 
> > In order to support message distribution, the SG maintains 
> an address
> > translation table, which maps the incoming SS7 messages to 
> > the appropriate
> > AS.  The relevant fields of the incoming SS7 message is 
> > compared to the
> > existing Routing Keys.  The Routing Keys reference an 
> > Application Server,
> > which will have one or more ASPs processing traffic for the AS.  The
> > availability and status of the ASPs is handled by SUA ASP management
> > messages.
> > 
> > Possible SS7 address/routing information that comprise 
> > a Routing Key entry includes, for example, OPC, DPC, SIO found in 
> > the MTP3 routing label, or other specific fields such as the 
> > SCCP subsystem number, or TCAP transaction ID. Some 
> > possibilities include:
> > 
> > 	Global Title (+ SSN optionally)
> > 	PC (+ SSN optionally)
> > 	Host Name (+ SSN optionally)
> > 	IP Address(es) (+ SSN optionally)
> > 
> > An Application Server maintains a list of ASPs that are 
> > available to process
> > the traffic.  The list is dynamic, based upon the 
> availability of the
> > individual ASPs in the list.  SUA ASP management messages are 
> > used to convey
> > the status of these ASPs and their availability in failover 
> > situations.
> > 
> > Normally, one or more ASPs areis active in the ASP (i.e., currently
> > processing traffic) but in certain failure and transition 
> cases it is
> > possible that there may not be an active ASP available. The 
> > SG will buffer
> > the message destined for this AS for a time T(r) or until an 
> > ASP becomes
> > available. When no ASP becomes available before expiry of 
> > t(r), the SG will
> > flush the buffered messages and initiate the appropriate 
> > return or refusal
> > procedures. 
> > 
> > Both load-sharing and backup scenarios are supported.
> > 
> > If there is no Routing Key match for an incoming SS7 message, 
> > a default
> > treatment MUST be specified.  Possible solutions are to 
> > provide a default
> > Application Server to direct all unallocated traffic to a 
> > (set of) default
> > ASP(s), or to drop the messages and provide a notification to 
> > management.
> > The treatment of unallocated traffic is implementation dependent.
> > 
> > 1.5.2 Address Translation and Mapping at the ASP
> > 
> > In order to direct messages to the SS7 network, the ASP must 
> > also perform an
> > address translation and mapping function in order to choose 
> > the proper SG or
> > SGP for a given message.  This is accomplished by observing 
> > the Destination
> > Point Code and other elements of the outgoing message, SS7 
> > network status,
> > SG and SGP availability, and network appearance 
> configuration tables.
> > 
> > A remote Signaling Gateway may be composed of one or more 
> > SGPs.  that are
> > capable of routing SS7 traffic.  As is the case with ASPs, a 
> > dynamic list of
> > SGPs in an SG can be maintained, taking into account the 
> > availability status
> > of the individual SGPs, configuration changes and fail-over 
> > mechanisms.
> > There is, however, no SUA messaging to manage the status of 
> > an SGP. Whenever
> > an SCTP association to an SGP exists, it is assumed to be 
> > available.  Also,
> > every SGP of one SG communicating with one ASP regarding one 
> > AS provides
> > identical SS7 connectivity to this ASP.
> > 
> > 1.5.3 SCTP Stream Mapping
> > 
> > The SUA supports SCTP streams. The SG/AS needs to maintain a 
> > list of SCTP
> > and SUA-users for mapping purposes.  SCCP-users requiring 
> > sequenced message
> > transfer need to be sent over a stream supporting sequenced 
> delivery.
> > 
> > SUA MUST use stream 0 for SUA management messages. It is 
> > recommended that
> > sequenced delivery is usedbe in order to preserve the order 
> > of management
> > message delivery.
> > 
> > 
> > ---
> > You are currently subscribed to sigtran as: 
> > [email-masked]
> > To unsubscribe send a blank email to
> > [email-masked]
> > 
> > 
> > ---
> > You are currently subscribed to sigtran as: 
> > [email-masked]
> > To unsubscribe send a blank email to 
> > [email-masked]
> > 
> 
> 
> ---
> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to
> [email-masked]
> 
> 
> ---
> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Fri, 1 Jun 2001 17:15:23 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades6.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [194.78.143.126]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Klaus,

Yes, that's still missing : some real SUA management ... Think we can
broaden the scope of the SSNM messages to inform nodes that a certain peer
has dropped out (DUNA, DAVA) ? The address info in these messages should
make clear what kind of node it is).

- Adjacent nodes (to which an SCTP association exists) are notified by
ASP-DOWN/INACTIVE or SCTP-CDI of the dropped-out node, as per the current
procedures.

- If such an adjacent node is a relay node, if notifies it's other
neighbours (or : provisioned list of concerned neighbours) via DUNA.

- The adjacent nodes and the informed nodes shall update their routing
tables (if any) and refrain from sending traffic to the drop-out. Requests
of the current status of the drop-out can be done by DAUD message.

- The adjacent nodes inform their (concerned) neighbours with DAVA if the
drop-out comes back alive (ASP-UP/ACTIVE). They also react with DAVA to a
received DAUD if the node's up.

- The informed nodes consider the drop-out back alive after either a DAVA is
received for this node, or after a certain decay time (if DUNA reason was
"transient").

- Adjacent nodes react with DUNA to a node that has tried to send a message
to an unavailable destination (response method).

These procedures are optional, and most of it happens at a relay node or the
SG.

How do you like them apples ?

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Gradischnig, Klaus [mailto:[email-masked]] Sent:
vrijdag 1 juni 2001 16:47
To: sigtran
Subject: RE: SUA5: Address Mapping text

Hallo Gery,

sounds good. Just a few comments in-line.

One thing I don't have a handle on yet is what if anything additionally SUA
has to do to support failure/congestion cases in the all IP (and perhaps
also the SS7 - IP) case? 

Klaus

> -----Original Message-----
> From: Verwimp Gery [mailto:[email-masked]]
> Sent: June 01, 2001 4:31 AM
> To: sigtran
> Subject: RE: SUA5: Address Mapping text
> 
> 
> Hi Klaus,
> 
> Yes, with this concept of "AMF" (address mapping function ... 
> why not "SRF"
> SUA relay function ...) SUA could really do without the 
> routing key things.
> What I have in mind is following black box, either at a SG or 
> an ASP or an
> SUA relay node in general :
> 
> Incoming message (either from SS7, with MTP routing label and SCCP
> parameters, or from IP, with SCTP header and SUA parameters)

You may also want to include the IP address parameters, or?

> 
> ==> pass to SRF for analysis and determine :
> 	- whether the message must be passed to a local user
> 	- whether the message must be "relayed on" to either an SS7
> destination (IP -> SS7 at SG) or to an IP destination (SS7 -> 
> IP at SG or
> all-IP case)
> 
> Any information can be used/provisioned for this purpose. One 
> may call it an
> enhanced GTT, because it can be based on IP address, GT, host 
> name, ...

IP address should be allowed as GT address info. Destination IP address in
the IP label is perhaps also useful in case the node has multiple IP
addresses. 

> 
> My comment on DPC+SSN only applied to "valid address 
> information in the
> incoming message". Just a point code won't do either as 
> called (who's going
> to handle it) as calling (backrouting ?) address. Of course, 
> the SRF may or
> may not take this SSN into account. E.g. the SG may forward 
> every SS7 SCCP
> message routed on DPC+SSN (and received from certain OPCs) to 
> the ASPs of a
> specified AS without further consideration to SSN.
>
> 
> The IP address is strictly an SUA address parameter. For 
> interworking with
> SS7, one endpoint only has the DPC+SSN or GT options. You can 
> of course put
> an IP(v4) address in your GT, or convert a GT to an IPaddress 
> (ENUM and DNS)
> ...
> 
> 
> Actually, what GTT or SRF should derive locally, is merely a 
> "handle" to the
> next hop, e.g.
> - a route set number, by which MTP knows the routeset and DPC to go to
> - an SCTP association ID, by which SCTP knows the 
> (multihomed) route and IP
> address to go to
> - of course, this "handle" could be the DPC and/or IP address 
> itself, e.g.
> if you use ENUM/DNS means to translate your E.164 stuff.
> 
> The SRF will avoid having to have a fully meshed SCTP (or transport)
> network.
> 
> Greetings,
> 
> ____________________________
> 
> Gery Verwimp
> > SIEMENS ATEA
> > ICN D CS D5
> > 
> > Tel. : +32 14 25 3424
> Fax : +32 14 25 3212
> mailto:[email-masked]
> ____________________________________
> 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 1 Jun 2001 10:33:27 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA: Changeover between ASPs
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      KAA24121
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.231]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Manns Juergen,

No.  I refer to M3UA.  And traffic will be diverted to another ASP, not
another SGP.

--Brian

On Fri, 01 Jun 2001, Schwarzbauer Hanns Juergen wrote:

> comments inline
> 
> Furthernore: the subject says "M3UA..." but you obviously refer to M2PA. 
> 

> > Does that help?
> 	[HJS]  not at all, as this picture tells nothing about the potential
> 	change-over processes occurring in the SS7 network! In case you
redirect
> 	the SS7 traffic to another SGP I seriously doubt the proposal.

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 1 Jun 2001 10:50:49 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: [Fwd: Re: M2PA: Multiple streams]
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      KAA24585
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-231.dallas.net [209.44.42.231]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hanns Juergen,

The SDL's also have the signals Local_Processor_Outage, Congestion_Accept,
and Congestion_Discard telling L2 in an instantaneous fashion when L3 is
unable to accept received MSUs.  Therefore, in the SDL's L2 know in advance
of delivering MSUs to L3 whether L3 can accept the MSU.

This is all fine for SDL diagrams which are an illustration of the concepts
in the spec and which do not form part of the standard, but in the real
world of state machine programming you tend to not know such things in
advance.

Also, as far as the SDLs are concerned there is no delay in any of the
signals (they are frictionless).

My point (and I do have one) is that in M2PA SCTP is acknowledging MSUs
without consideration of the receive congestion state of the link and
without consideration for local processor outage status.
This clears the message from the sender's SCTP retransmit buffers and make
it unretrievable from SCTP.

In M2UA, the SS7 L2 is acknowledging MSUs with a potentially outdated
consideration of the receive congestion stat and local processor outage
status.  This clears the sending L2's retransmit buffer and makes buffer
collection impossible on that MSU.  If M2UA at the ASP controlled when
acknolwedgements were made by the SS7 link by acknowledging the receipt of
MSUs, proper order could be restored.

--Brian

On Fri, 01 Jun 2001, Schwarzbauer Hanns Juergen wrote:

> 	[HJS]  sorry beeing ignorant on this sequence number, but as far
> 	as my interpretation of the SDLs given in Q.703 is concerned:
> 	when basic reception control is informed about a "Signal Unit "
> 	(see Q.703 Figure 14 (sheets 2 and 3 of 7) DAEDR -> RC) and this
> 	is not an LSSU, it immediately prepares the acknowledgement of
> 	that MSU. There is no feedback from MTP L3 indicationg it has
> 	accepted the "received message".  In my understanding it is
> 	always assumed that messages accepted by MTP L2 are also
> 	successfully delivered to MTP L3 except MTP L3 used some more
> 	general signals to prevent MTP L2 from working as usual, e.g.
> 	LPO.

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Fri, 01 Jun 2001 13:56:45 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M3UA: Changeover between ASPs
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

Thanks for the detailed explanation.  I think it is reasonable for M3UA to
support your redundancy model.  However, I would suggest the following
changes:

*  if you are not going to use Broadcast-Standby, then let's delete it.  I
wouldn't mind deleting Override-Standby also.

*  since there is no Data Ack message, I don't see a major problem with
having Correlation ID in all data messages if it is useful for this
redundancy model.  It would only add 8 bytes of overhead. 

Greg, others - any thoughts regarding these changes?

Regards,

Ken

At 12:54 AM 6/1/01 -0500, you wrote:
>Ken,
>
>I agree with you whole-heartedly on the Override-Standby.  It's
>useless.  However, I also believe that Load-Share is useless as
>well.  Let me offer a proposal for a Broadcast redundancy model,
>show you how I intend to use it, and show you why I need a
>Correlation Id, at least as an optional parameter which must
>be used in some circumstances.
>
>Bear with me.
>
>
>I would like to propose two new Traffic Mode Types with text as
>follows (I had mentioned this to Greg before):
>
>In Section 3.5.5 change the following:
>
>.   Traffic Mode Type: 32-bit (unsigned integer)
>.
>.      The Traffic Mode Type parameter identifies the traffic mode of
>.      operation of the ASP within an AS.  The valid values for Type are
>.      shown in the following table.
>.
>.           1       Over-ride
>.           2       Load-share
>.           3       Over-ride (Standby)
>.           4       Load-share (Standby)
>|           5       Broadcast
>|           6       Broadcast (Standby)
>.   
>.      Within a particular Routing Context, only one Traffic Mode Type
>.      can be used.  The Over-ride value indicates that the ASP is 
>.      operating in Over-ride mode, and the ASP takes over all 
>.      traffic in an Application Server (i.e., primary/back-up operation), 
>.      over-riding any currently active ASPs in the AS.  In Load-share 
>.      mode, the ASP will share in the traffic distribution with any other 
>.      currently active ASPs.  The Standby versions of the Over-ride and 
>.      Load-share Types indicate that the ASP is declaring itself ready to 
>.      accept traffic but leaves it up to the sender as to when the traffic

>.      is started.  Over-ride (Standby) indicates that the traffic sender 
>.      continues to use the currently active ASP until it can no longer 
>.      send/receive traffic (i.e., the currently active ASP transitions to 
>.      Down or Inactive).  At this point the sender MUST move the standby 
>.      ASP to Active and commence traffic.  Load-share (Standby) is similar

>.      - the sender continues to load-share to the current ASPs until it is

>.      determined that there is insufficient resources in 
>.      the Load-share group.  When there are insufficient ASPs, the sender 
>.      MUST move the ASP to Active.
>|      In Broadcast mode, the ASP will receive the identical traffic
>|      distribution as any other currently active ASPs.  The Standby
>|      version of the Broadcast Type indicates that the ASP is declaring
>|      itself as ready to accept traffic but leaves it up to the sender
>|      as to when the traffic is started.  Broadcast (Standby) is
>|      similar to other Standby modes in that the sending continues to
>|      broadcast traffic to the current ASPs until it is determined that
>|      there are insufficient resources in the Broadcast group.  When
>|      there are insufficient ASPs, the sender MUST move the ASP to
>|      Active.
>
>In Section 3.5.6 add ASPAC (broadcast (standby)) with the others.
>
>Add to Section 4.1.1:
>
>
>.   From the list of ASPs within the AS table, an Active ASP is selected 
>.   and a DATA message is constructed and issued on the corresponding SCTP 
>.   Association.  If more than one ASP is active (i.e., traffic is to be 
>.   load-shared across all the active ASPs), one of the active ASPs from 
>.   the list is selected.  The selection algorithm is implementation 
>.   dependent but could, for example, be round-robin or based on, for 
>.   example, the SLS or ISUP CIC.  The appropriate selection algorithm must

>.   be chosen carefully as it is dependent on application assumptions and 
>.   understanding of the degree of state coordination between the active 
>.   ASPs in the AS. 
>|
>|   In the Broadcast mode, all active ASP(s) are selected and a DATA
>|   message is constructed and issued on each of the corresponding SCTP
>|   Association(s).
>|
>
>Alter to Section 4.3.3.4 as follows:
>
>
>|   There are six modes of Application Server traffic handling in the SG 
>|   M3UA - Over-ride, Over-ride (Standby), Loadshare, Load-share 
>|   (Standby), Broadcast, and Broadcast (Standby).  The Traffic Mode
>.   Type parameter in the ASPAC message indicates the traffic handling
>.   mode used in a particular Application Server. If the SG determines
>.   that the mode indicated in an ASPAC is unsupported or incompatible
>     ...
>
>Add to the end of Section 4.3.3.4 as follows:
>
>|   In the case of a Broadcast mode AS, reception of an ASPAC message at
>|   an SG or IPSP causes the direction of traffic to the ASP sending the
>|   ASPAC, in addition to all other ASPs that are currently active in
>|   the AS.  The SG MUST broadcast traffic to all of the active ASPs
>|   within the AS.
>|
>|   As in the Load-share mode, an SG or IPSP, upon reception of an ASPAC
>|   for the first ASP in a Broadcast AS, MAY choose not to direct
>|   traffic to a newly active ASP until it determines that there are
>|   sufficient resources to handle the expected load (e.g., until there
>|   are sufficient ASPs "Active" in the AS).
>|
>|   In the case of Broadcast (Standby) mode, the traffic is not started
>|   to the ASP until the SG or IPSP determines that there are
>|   insufficient resources available in the AS.  This is likely when one
>|   of the active broadcast ASPs transitions to the "Inactive" or "Down"
>|   state.  At this point the ASP that sent the Broadcast (Standby)
>|   ASPAC is moved to the Active state and traffic is started.  A second
>|   ASP-Active Ack message with a new Traffic Mode Type ("Broadcast"
>|   previously "Broadcast (Standby)") is sent to the ASP.  A Notify
>|   ("Insufficient ASP resources active in AS") message is not sent in
>|   this case.
>|
>|   All ASPs within a broadcast mode AS must coordinate between
>|   themselves to determine which portion of the broadcast traffic they
>|   will handle.
>
>In the middle of Section 4.3.3.5 add:
>
>|   In the case of a Broadcast mode AS, the SG moves the ASP to the
>|   "Inactive" state and the AS traffic is broadcast only to the
>|   remaining "active" ASPs.  A NTFY(Insufficient ASP resources active
>|   in AS) may be sent to all inactive ASPs, if required.  However, if a
>|   Broadcast (Standby) ASP is available, it may be now immediately
>|   included in the broadcast group and a Notify message is not sent.
>|   An ASPIA Ack message is sent to the ASP after all traffic is halted
>|   and Layer Management is informed with an ASP-INACTIVE indication
>|   primitive.
>
>And here's the rub: also add to Section 4.3.3.5:
>
>|   Whenever an ASP in a Broadcast mode AS becomes active, the SG MUST
>|   tag the first DATA message broadcast in each SCTP stream with a
>|   unique Correlation Id parameter.  The purpose of this Correlation Id
>|   is to permite the newly active ASP to synchronize its processing of
>|   the traffic in each ordered stream with other ASPs in the broadcast
>|   group.
>
>
>Modify Section 4.3.3.6 to:
>
>
>.   In the case where a Notify (AS-Pending) message is sent by an SG that 
>.   now has no ASPs active to service the traffic, or a NTFY(Insufficient 
>.   ASP resources active in AS) is sent in the Loadshare
>|   or Broadcast modes, the Notify 
>.   does not explicitly compel the ASP(s) receiving the message to become 
>.   active. The ASPs remain in control of what (and when) traffic action is

>.   taken.
>
>
>In my previous proposal make the Correlation Id parameter in the DATA
>message Optional and you can remove the Correlation Id Ack if you'd
>like.
>
>If you would like to rework this so that Broadcast is a separate
>algorithm under Loadshare, that's fine too.  Just as long as the ASP can
>require Broadcast algorithm and require the addition of a Correlation Id
>to messages in each stream upon going active, I see no problem.
>
>Now, as promised, here is the implementation: (This is not conjecture, I
>have built them this way before.)
>
>I have break down my ISUP application server into CIC ranges which
>correspond to ISUP circuit management groups.  (Basically that is one AS
>per 24 circuits.)
>
>I arrange at the SG to distribute messages over streams in each of the
>16 (or more) associations by OPC/DPC/SLS/CIC to the maximum number of
>streams permissible.  I have 16 ASPs which I register against all of the
>AS's in Broadcast Mode.
>
>Upon going up with a sufficient number of ASPs active, the ASPs begin
>receiving traffic and each initial DATA message in each stream contains
>a Correlation Id which the ASP uses as a sequence number to start
>numbering the messages in each stream (I cannot be sure that the SSNs
>will be synchronized at the SG).
>
>Each ASP knows the other ASPs that are active in the broadcast group by
>inter-ASP communication.  Each ASP knows the assignment of the other
>ASPs to traffic (say, each ASP processes one of 16 streams according to
>it's ASP number in the pool).  For it's assigned trafffic the ASP is
>Master.  For the other 15 of 16 streams the ASP is Slave.
>
>For messages received on the streams for which the ASP is Master the ASP
>processes the message through its ISUP state machines and responds with
>control messages and reply ISUP messages back to the SG.  For messages
>received on the streams for which the ASP is Slave, the ASP processes
>the message through its ISUP state machines but does not dispatch the
>controll messages or ISUP replies.  It only moves through the state
>transitions.
>
>After processing state transitions for streams upon which the ASP is
>Master, the ASP also broadcasts the Stream Id and Correlation Id
>associated with the message to the slave ASPs for that stream.  This
>checkpoints the slaves.
>
>Each ASP, when processing messages on Slave streams should buffer
>incoming messages long enough that the checkpoint from the Master for
>the stream (or separate inter-ASP heartbeat) verifies the viability of
>the Master.  Therefore, each ASP is a Leader on its Master stream and a
>Follower on its slave streams.
>
>When an ASP fails, either through lost of inter-ASP checkpoint or
>heartbeat, a prearranged ASP takes over as Master for the failed ASPs
>streams beginning distribution of control and ISUP responses at the
>point which minimizes duplication and discard.
>
>With some good software design ;) this loosley coupled interlocking
>leader-follower arrangement can perform well, has extremely low
>inter-ASP sychronization overheads and has minimal message loss and
>call-state mishandling.  Many low-reliability or low-performance ASPs
>can be grouped into large arrays that scale well.
>
>The difficulty in the arrangement come when adding an ASP to the group.
>It must have a marker in the message streams upon which to start
>synchonizing its behaviour.  It must replicate state from one of its
>peers for the marked point before starting slave operation and
>subsequently master operation on the traffic.  (The Broadcast (Standby)
>mode is really useless: I don't intend to use it.)
>
>This is where the Correlation Id come in.  I need it to mark the traffic
>for synchronization with my ASP peers.  I would prefer if it was
>contained in all DATA messages, however, if the SG will place it in the
>first DATA message broadcast on any stream within a time interval from
>the transition of an ASP from the "inactive" to "active" state within
>the broadcast group, then the ASP can infer the correlation Id of the
>other messages from the stream and the SSN.
>
>
>Does this explain the need a little better?
>
>
>
>
>On Thu, 31 May 2001, Ken Morneault wrote:
>
> > 
> > 
> > Brian,
> > 
> > See below.
> > 
> > Ken
> > 
> > At 12:24 PM 5/31/01 -0500, Brian F. G. Bidulock wrote:
> > >Ken,
> > >
> > >Per your 1) and 2):
> > >
> > >The M3UA ASP state diagrams do not distinguish between
> > >SCTP CDI fatal and non-fatal.  The diagrams show the
> > >ASP always moving to the DOWN state as a result of an
> > >SCTP CDI.  The SG, in this case is required to send
> > >messages to the standby ASP.
> > 
> > 
> > Sorry, I do not value the Override-Standby option in ASP 
> > Active and would not use it.  The decision regarding failover 
> > should be made by the ASPs not the SG.  Clearly, the 
> > SG does not have enough information to determine a 
> > failover condition.  
> > 
> > See Section 5.2 for failover examples. 
> > 
> > There is no way to guarantee that there will
> > be no messages lost during an ungraceful failover.
> > Even with a "Correlation ID", it is highly likely that
> > messages will be lost.  More importantly, some
> > User Part state information will be lost (i.e. calls
> > that are in setup phase).
> > 
> > Further, going back to your original message, how does
> > M3UA determine when the message has been
> > processed.  M3UA has no idea of when the
> > message has been processed and the state information
> > has been checkpointed by the User Part to the Standby 
> > ASP.
> > 
> > 
> > >As far as T(r) is concerned, the message have already
> > >been delivered (or not) before T(r) is started.  I did
> > >not have a problem with messages which arrive *after*
> > >the SCTP CDI, just those that are sent *before* the
> > >SCTP CDI.  So, T(r) doesn't help.
> > >
> > >I don't see where you have solved the problem that a
> > >Correlation Id would easily solve.
> > 
> > My email only intended to layout scenarios of
> > interest to see where and if problem(s) existed.   
> > 
> > >--Brian
> > >
>
>-- 
>Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
>[email-masked]    ¦ world; the unreasonable one persists in  ¦
>http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA: Changeover between ASPs
Date: Fri, 1 Jun 2001 14:21:14 -0400 
X-Mailer: Internet Mail Service (5.5.2653.19)
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.59">
<TITLE>RE: M3UA: Changeover between ASPs</TITLE> </HEAD>
<BODY>

<P><FONT SIZE=2>Hi Ken,</FONT>
</P>

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
SIZE=2>From: &nbsp; Ken Morneault [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
<BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Friday, June 01, 2001 1:57 PM</FONT>
<BR><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT> <BR><FONT
SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: M3UA:
Changeover between ASPs</FONT> </P>
<BR>
<BR>

<P><FONT SIZE=2>Brian,</FONT>
</P>

<P><FONT SIZE=2>Thanks for the detailed explanation.&nbsp; I think it is
reasonable</FONT> <BR><FONT SIZE=2>for M3UA to support your redundancy
model.&nbsp; However,</FONT> <BR><FONT SIZE=2>I would suggest the following
changes:</FONT> </P>

<P><FONT SIZE=2>*&nbsp; if you are not going to use Broadcast-Standby, then
let's</FONT> <BR><FONT SIZE=2>delete it.&nbsp; I wouldn't mind deleting
Override-Standby also.</FONT> </P>

<P><FONT SIZE=2>[Greg] I wouldn't mind getting rid of all the Standby stuff
myself - it causes some complexity in the procedures and I'm not aware of
anybody implementing this (although an issue related to this came up at the
Bay cough discussions?).&nbsp; It was added because there was some input
that it could speed the fail-over (the standby ASP has given
&quot;permission&quot; to the SG to fail over traffic without buffering and
waiting for an ASP-Active).&nbsp;&nbsp; </FONT></P> <BR>

<P><FONT SIZE=2>*&nbsp; since there is no Data Ack message, I don't see a
major </FONT> <BR><FONT SIZE=2>problem with having Correlation ID in all
data messages if it</FONT> <BR><FONT SIZE=2>is useful for this redundancy
model.&nbsp; It would only add 8 bytes</FONT> <BR><FONT SIZE=2>of overhead.
</FONT>
</P>

<P><FONT SIZE=2>Greg, others - any thoughts regarding these changes?</FONT>
</P>

<P><FONT SIZE=2>[Greg] I'm still studying this - Brian has given me way too
much homework lately&nbsp; 2;^)</FONT> </P>

<P><FONT SIZE=2>Cheers</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp; Greg</FONT> </P>
<BR>

<P><FONT SIZE=2>Regards,</FONT>
</P>

<P><FONT SIZE=2>Ken</FONT>
</P>

<P><FONT SIZE=2>At 12:54 AM 6/1/01 -0500, you wrote:</FONT> <BR><FONT
SIZE=2>&gt;Ken,</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;I agree with you whole-heartedly on the
Override-Standby.&nbsp; It's</FONT> <BR><FONT SIZE=2>&gt;useless.&nbsp;
However, I also believe that Load-Share is useless as</FONT> <BR><FONT
SIZE=2>&gt;well.&nbsp; Let me offer a proposal for a Broadcast redundancy
model,</FONT> <BR><FONT SIZE=2>&gt;show you how I intend to use it, and show
you why I need a</FONT> <BR><FONT SIZE=2>&gt;Correlation Id, at least as an
optional parameter which must</FONT> <BR><FONT SIZE=2>&gt;be used in some
circumstances.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Bear with me.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;I would like to propose two new Traffic Mode Types with
text as</FONT> <BR><FONT SIZE=2>&gt;follows (I had mentioned this to Greg
before):</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;In Section 3.5.5 change the following:</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;.&nbsp;&nbsp; Traffic Mode Type: 32-bit (unsigned
integer)</FONT> <BR><FONT SIZE=2>&gt;.</FONT>
<BR><FONT SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Traffic Mode Type
parameter identifies the traffic mode of</FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; operation of the ASP within an
AS.&nbsp; The valid values for Type are</FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shown in the following
table.</FONT> <BR><FONT SIZE=2>&gt;.</FONT>
<BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Over-ride</FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Load-share</FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Over-ride (Standby)</FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Load-share (Standby)</FONT> <BR><FONT
SIZE=2>&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Broadcast</FONT> <BR><FONT
SIZE=2>&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Broadcast (Standby)</FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Within a particular Routing
Context, only one Traffic Mode Type</FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; can be used.&nbsp; The Over-ride
value indicates that the ASP is </FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; operating in Over-ride mode, and
the ASP takes over all </FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; traffic in an Application Server
(i.e., primary/back-up operation), </FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; over-riding any currently active
ASPs in the AS.&nbsp; In Load-share </FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mode, the ASP will share in the
traffic distribution with any other </FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; currently active ASPs.&nbsp; The
Standby versions of the Over-ride and </FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Load-share Types indicate that
the ASP is declaring itself ready to </FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; accept traffic but leaves it up
to the sender as to when the traffic </FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is started.&nbsp; Over-ride
(Standby) indicates that the traffic sender </FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; continues to use the currently
active ASP until it can no longer </FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; send/receive traffic (i.e., the
currently active ASP transitions to </FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Down or Inactive).&nbsp; At this
point the sender MUST move the standby </FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP to Active and commence
traffic.&nbsp; Load-share (Standby) is similar </FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - the sender continues to
load-share to the current ASPs until it is </FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; determined that there is
insufficient resources in </FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the Load-share group.&nbsp; When
there are insufficient ASPs, the sender </FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MUST move the ASP to
Active.</FONT> <BR><FONT SIZE=2>&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In
Broadcast mode, the ASP will receive the identical traffic</FONT> <BR><FONT
SIZE=2>&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; distribution as any other
currently active ASPs.&nbsp; The Standby</FONT> <BR><FONT
SIZE=2>&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; version of the Broadcast Type
indicates that the ASP is declaring</FONT> <BR><FONT
SIZE=2>&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; itself as ready to accept traffic
but leaves it up to the sender</FONT> <BR><FONT
SIZE=2>&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; as to when the traffic is
started.&nbsp; Broadcast (Standby) is</FONT> <BR><FONT
SIZE=2>&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; similar to other Standby modes in
that the sending continues to</FONT> <BR><FONT
SIZE=2>&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; broadcast traffic to the current
ASPs until it is determined that</FONT> <BR><FONT
SIZE=2>&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; there are insufficient resources
in the Broadcast group.&nbsp; When</FONT> <BR><FONT
SIZE=2>&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; there are insufficient ASPs, the
sender MUST move the ASP to</FONT> <BR><FONT
SIZE=2>&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Active.</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;In Section 3.5.6 add ASPAC (broadcast (standby)) with
the others.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Add to Section 4.1.1:</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;.&nbsp;&nbsp; From the list of ASPs within the AS
table, an Active ASP is selected </FONT> <BR><FONT SIZE=2>&gt;.&nbsp;&nbsp;
and a DATA message is constructed and issued on the corresponding SCTP
</FONT> <BR><FONT SIZE=2>&gt;.&nbsp;&nbsp; Association.&nbsp; If more than
one ASP is active (i.e., traffic is to be </FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp; load-shared across all the active ASPs), one of the
active ASPs from </FONT> <BR><FONT SIZE=2>&gt;.&nbsp;&nbsp; the list is
selected.&nbsp; The selection algorithm is implementation </FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp; dependent but could, for example, be round-robin or
based on, for </FONT> <BR><FONT SIZE=2>&gt;.&nbsp;&nbsp; example, the SLS or
ISUP CIC.&nbsp; The appropriate selection algorithm must </FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp; be chosen carefully as it is dependent on
application assumptions and </FONT> <BR><FONT SIZE=2>&gt;.&nbsp;&nbsp;
understanding of the degree of state coordination between the active </FONT>
<BR><FONT SIZE=2>&gt;.&nbsp;&nbsp; ASPs in the AS. </FONT> <BR><FONT
SIZE=2>&gt;|</FONT>
<BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; In the Broadcast mode, all active ASP(s)
are selected and a DATA</FONT> <BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; message is
constructed and issued on each of the corresponding SCTP</FONT> <BR><FONT
SIZE=2>&gt;|&nbsp;&nbsp; Association(s).</FONT> <BR><FONT
SIZE=2>&gt;|</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Alter to Section 4.3.3.4 as follows:</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; There are six modes of Application Server
traffic handling in the SG </FONT> <BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; M3UA -
Over-ride, Over-ride (Standby), Loadshare, Load-share </FONT> <BR><FONT
SIZE=2>&gt;|&nbsp;&nbsp; (Standby), Broadcast, and Broadcast
(Standby).&nbsp; The Traffic Mode</FONT> <BR><FONT SIZE=2>&gt;.&nbsp;&nbsp;
Type parameter in the ASPAC message indicates the traffic handling</FONT>
<BR><FONT SIZE=2>&gt;.&nbsp;&nbsp; mode used in a particular Application
Server. If the SG determines</FONT> <BR><FONT SIZE=2>&gt;.&nbsp;&nbsp; that
the mode indicated in an ASPAC is unsupported or incompatible</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; ...</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Add to the end of Section 4.3.3.4 as follows:</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; In the case of a Broadcast mode AS,
reception of an ASPAC message at</FONT> <BR><FONT SIZE=2>&gt;|&nbsp;&nbsp;
an SG or IPSP causes the direction of traffic to the ASP sending the</FONT>
<BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; ASPAC, in addition to all other ASPs that
are currently active in</FONT> <BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; the
AS.&nbsp; The SG MUST broadcast traffic to all of the active ASPs</FONT>
<BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; within the AS.</FONT> <BR><FONT
SIZE=2>&gt;|</FONT>
<BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; As in the Load-share mode, an SG or IPSP,
upon reception of an ASPAC</FONT> <BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; for the
first ASP in a Broadcast AS, MAY choose not to direct</FONT> <BR><FONT
SIZE=2>&gt;|&nbsp;&nbsp; traffic to a newly active ASP until it determines
that there are</FONT> <BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; sufficient
resources to handle the expected load (e.g., until there</FONT> <BR><FONT
SIZE=2>&gt;|&nbsp;&nbsp; are sufficient ASPs &quot;Active&quot; in the
AS).</FONT> <BR><FONT SIZE=2>&gt;|</FONT>
<BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; In the case of Broadcast (Standby) mode,
the traffic is not started</FONT> <BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; to the
ASP until the SG or IPSP determines that there are</FONT> <BR><FONT
SIZE=2>&gt;|&nbsp;&nbsp; insufficient resources available in the AS.&nbsp;
This is likely when one</FONT> <BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; of the
active broadcast ASPs transitions to the &quot;Inactive&quot; or
&quot;Down&quot;</FONT> <BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; state.&nbsp; At
this point the ASP that sent the Broadcast (Standby)</FONT> <BR><FONT
SIZE=2>&gt;|&nbsp;&nbsp; ASPAC is moved to the Active state and traffic is
started.&nbsp; A second</FONT> <BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; ASP-Active
Ack message with a new Traffic Mode Type (&quot;Broadcast&quot;</FONT>
<BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; previously &quot;Broadcast
(Standby)&quot;) is sent to the ASP.&nbsp; A Notify</FONT> <BR><FONT
SIZE=2>&gt;|&nbsp;&nbsp; (&quot;Insufficient ASP resources active in
AS&quot;) message is not sent in</FONT> <BR><FONT SIZE=2>&gt;|&nbsp;&nbsp;
this case.</FONT> <BR><FONT SIZE=2>&gt;|</FONT>
<BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; All ASPs within a broadcast mode AS must
coordinate between</FONT> <BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; themselves to
determine which portion of the broadcast traffic they</FONT> <BR><FONT
SIZE=2>&gt;|&nbsp;&nbsp; will handle.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;In the middle of Section 4.3.3.5 add:</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; In the case of a Broadcast mode AS, the
SG moves the ASP to the</FONT> <BR><FONT SIZE=2>&gt;|&nbsp;&nbsp;
&quot;Inactive&quot; state and the AS traffic is broadcast only to
the</FONT> <BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; remaining &quot;active&quot;
ASPs.&nbsp; A NTFY(Insufficient ASP resources active</FONT> <BR><FONT
SIZE=2>&gt;|&nbsp;&nbsp; in AS) may be sent to all inactive ASPs, if
required.&nbsp; However, if a</FONT> <BR><FONT SIZE=2>&gt;|&nbsp;&nbsp;
Broadcast (Standby) ASP is available, it may be now immediately</FONT>
<BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; included in the broadcast group and a
Notify message is not sent.</FONT> <BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; An
ASPIA Ack message is sent to the ASP after all traffic is halted</FONT>
<BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; and Layer Management is informed with an
ASP-INACTIVE indication</FONT> <BR><FONT SIZE=2>&gt;|&nbsp;&nbsp;
primitive.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;And here's the rub: also add to Section 4.3.3.5:</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; Whenever an ASP in a Broadcast mode AS
becomes active, the SG MUST</FONT> <BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; tag
the first DATA message broadcast in each SCTP stream with a</FONT> <BR><FONT
SIZE=2>&gt;|&nbsp;&nbsp; unique Correlation Id parameter.&nbsp; The purpose
of this Correlation Id</FONT> <BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; is to
permite the newly active ASP to synchronize its processing of</FONT>
<BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; the traffic in each ordered stream with
other ASPs in the broadcast</FONT> <BR><FONT SIZE=2>&gt;|&nbsp;&nbsp;
group.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Modify Section 4.3.3.6 to:</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;.&nbsp;&nbsp; In the case where a Notify (AS-Pending)
message is sent by an SG that </FONT> <BR><FONT SIZE=2>&gt;.&nbsp;&nbsp; now
has no ASPs active to service the traffic, or a NTFY(Insufficient </FONT>
<BR><FONT SIZE=2>&gt;.&nbsp;&nbsp; ASP resources active in AS) is sent in
the Loadshare</FONT> <BR><FONT SIZE=2>&gt;|&nbsp;&nbsp; or Broadcast modes,
the Notify </FONT> <BR><FONT SIZE=2>&gt;.&nbsp;&nbsp; does not explicitly
compel the ASP(s) receiving the message to become </FONT> <BR><FONT
SIZE=2>&gt;.&nbsp;&nbsp; active. The ASPs remain in control of what (and
when) traffic action is </FONT> <BR><FONT SIZE=2>&gt;.&nbsp;&nbsp;
taken.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;In my previous proposal make the Correlation Id
parameter in the DATA</FONT> <BR><FONT SIZE=2>&gt;message Optional and you
can remove the Correlation Id Ack if you'd</FONT> <BR><FONT
SIZE=2>&gt;like.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;If you would like to rework this so that Broadcast is a
separate</FONT> <BR><FONT SIZE=2>&gt;algorithm under Loadshare, that's fine
too.&nbsp; Just as long as the ASP can</FONT> <BR><FONT SIZE=2>&gt;require
Broadcast algorithm and require the addition of a Correlation Id</FONT>
<BR><FONT SIZE=2>&gt;to messages in each stream upon going active, I see no
problem.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Now, as promised, here is the implementation: (This is
not conjecture, I</FONT> <BR><FONT SIZE=2>&gt;have built them this way
before.)</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;I have break down my ISUP application server into CIC
ranges which</FONT> <BR><FONT SIZE=2>&gt;correspond to ISUP circuit
management groups.&nbsp; (Basically that is one AS</FONT> <BR><FONT
SIZE=2>&gt;per 24 circuits.)</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;I arrange at the SG to distribute messages over streams
in each of the</FONT> <BR><FONT SIZE=2>&gt;16 (or more) associations by
OPC/DPC/SLS/CIC to the maximum number of</FONT> <BR><FONT SIZE=2>&gt;streams
permissible.&nbsp; I have 16 ASPs which I register against all of the</FONT>
<BR><FONT SIZE=2>&gt;AS's in Broadcast Mode.</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Upon going up with a sufficient number of ASPs active,
the ASPs begin</FONT> <BR><FONT SIZE=2>&gt;receiving traffic and each
initial DATA message in each stream contains</FONT> <BR><FONT SIZE=2>&gt;a
Correlation Id which the ASP uses as a sequence number to start</FONT>
<BR><FONT SIZE=2>&gt;numbering the messages in each stream (I cannot be sure
that the SSNs</FONT> <BR><FONT SIZE=2>&gt;will be synchronized at the
SG).</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Each ASP knows the other ASPs that are active in the
broadcast group by</FONT> <BR><FONT SIZE=2>&gt;inter-ASP
communication.&nbsp; Each ASP knows the assignment of the other</FONT>
<BR><FONT SIZE=2>&gt;ASPs to traffic (say, each ASP processes one of 16
streams according to</FONT> <BR><FONT SIZE=2>&gt;it's ASP number in the
pool).&nbsp; For it's assigned trafffic the ASP is</FONT> <BR><FONT
SIZE=2>&gt;Master.&nbsp; For the other 15 of 16 streams the ASP is
Slave.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;For messages received on the streams for which the ASP
is Master the ASP</FONT> <BR><FONT SIZE=2>&gt;processes the message through
its ISUP state machines and responds with</FONT> <BR><FONT
SIZE=2>&gt;control messages and reply ISUP messages back to the SG.&nbsp;
For messages</FONT> <BR><FONT SIZE=2>&gt;received on the streams for which
the ASP is Slave, the ASP processes</FONT> <BR><FONT SIZE=2>&gt;the message
through its ISUP state machines but does not dispatch the</FONT> <BR><FONT
SIZE=2>&gt;controll messages or ISUP replies.&nbsp; It only moves through
the state</FONT> <BR><FONT SIZE=2>&gt;transitions.</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;After processing state transitions for streams upon
which the ASP is</FONT> <BR><FONT SIZE=2>&gt;Master, the ASP also broadcasts
the Stream Id and Correlation Id</FONT> <BR><FONT SIZE=2>&gt;associated with
the message to the slave ASPs for that stream.&nbsp; This</FONT> <BR><FONT
SIZE=2>&gt;checkpoints the slaves.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Each ASP, when processing messages on Slave streams
should buffer</FONT> <BR><FONT SIZE=2>&gt;incoming messages long enough that
the checkpoint from the Master for</FONT> <BR><FONT SIZE=2>&gt;the stream
(or separate inter-ASP heartbeat) verifies the viability of</FONT> <BR><FONT
SIZE=2>&gt;the Master.&nbsp; Therefore, each ASP is a Leader on its Master
stream and a</FONT> <BR><FONT SIZE=2>&gt;Follower on its slave
streams.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;When an ASP fails, either through lost of inter-ASP
checkpoint or</FONT> <BR><FONT SIZE=2>&gt;heartbeat, a prearranged ASP takes
over as Master for the failed ASPs</FONT> <BR><FONT SIZE=2>&gt;streams
beginning distribution of control and ISUP responses at the</FONT> <BR><FONT
SIZE=2>&gt;point which minimizes duplication and discard.</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;With some good software design ;) this loosley coupled
interlocking</FONT> <BR><FONT SIZE=2>&gt;leader-follower arrangement can
perform well, has extremely low</FONT> <BR><FONT SIZE=2>&gt;inter-ASP
sychronization overheads and has minimal message loss and</FONT> <BR><FONT
SIZE=2>&gt;call-state mishandling.&nbsp; Many low-reliability or
low-performance ASPs</FONT> <BR><FONT SIZE=2>&gt;can be grouped into large
arrays that scale well.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;The difficulty in the arrangement come when adding an
ASP to the group.</FONT> <BR><FONT SIZE=2>&gt;It must have a marker in the
message streams upon which to start</FONT> <BR><FONT SIZE=2>&gt;synchonizing
its behaviour.&nbsp; It must replicate state from one of its</FONT>
<BR><FONT SIZE=2>&gt;peers for the marked point before starting slave
operation and</FONT> <BR><FONT SIZE=2>&gt;subsequently master operation on
the traffic.&nbsp; (The Broadcast (Standby)</FONT> <BR><FONT SIZE=2>&gt;mode
is really useless: I don't intend to use it.)</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;This is where the Correlation Id come in.&nbsp; I need
it to mark the traffic</FONT> <BR><FONT SIZE=2>&gt;for synchronization with
my ASP peers.&nbsp; I would prefer if it was</FONT> <BR><FONT
SIZE=2>&gt;contained in all DATA messages, however, if the SG will place it
in the</FONT> <BR><FONT SIZE=2>&gt;first DATA message broadcast on any
stream within a time interval from</FONT> <BR><FONT SIZE=2>&gt;the
transition of an ASP from the &quot;inactive&quot; to &quot;active&quot;
state within</FONT> <BR><FONT SIZE=2>&gt;the broadcast group, then the ASP
can infer the correlation Id of the</FONT> <BR><FONT SIZE=2>&gt;other
messages from the stream and the SSN.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Does this explain the need a little better?</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;On Thu, 31 May 2001, Ken Morneault wrote:</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Brian,</FONT> <BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; See below.</FONT> <BR><FONT SIZE=2>&gt; &gt;
</FONT>
<BR><FONT SIZE=2>&gt; &gt; Ken</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; At 12:24 PM 5/31/01 -0500, Brian F. G. Bidulock
wrote:</FONT> <BR><FONT SIZE=2>&gt; &gt; &gt;Ken,</FONT> <BR><FONT
SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;Per your 1) and 2):</FONT> <BR><FONT
SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;The M3UA ASP state diagrams do not
distinguish between</FONT> <BR><FONT SIZE=2>&gt; &gt; &gt;SCTP CDI fatal and
non-fatal.&nbsp; The diagrams show the</FONT> <BR><FONT SIZE=2>&gt; &gt;
&gt;ASP always moving to the DOWN state as a result of an</FONT> <BR><FONT
SIZE=2>&gt; &gt; &gt;SCTP CDI.&nbsp; The SG, in this case is required to
send</FONT> <BR><FONT SIZE=2>&gt; &gt; &gt;messages to the standby
ASP.</FONT> <BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Sorry, I do not value the Override-Standby option
in ASP </FONT> <BR><FONT SIZE=2>&gt; &gt; Active and would not use it.&nbsp;
The decision regarding failover </FONT> <BR><FONT SIZE=2>&gt; &gt; should be
made by the ASPs not the SG.&nbsp; Clearly, the </FONT> <BR><FONT
SIZE=2>&gt; &gt; SG does not have enough information to determine a </FONT>
<BR><FONT SIZE=2>&gt; &gt; failover condition.&nbsp; </FONT> <BR><FONT
SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; See Section 5.2 for failover examples. </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; There is no way to guarantee that there
will</FONT> <BR><FONT SIZE=2>&gt; &gt; be no messages lost during an
ungraceful failover.</FONT> <BR><FONT SIZE=2>&gt; &gt; Even with a
&quot;Correlation ID&quot;, it is highly likely that</FONT> <BR><FONT
SIZE=2>&gt; &gt; messages will be lost.&nbsp; More importantly, some</FONT>
<BR><FONT SIZE=2>&gt; &gt; User Part state information will be lost (i.e.
calls</FONT> <BR><FONT SIZE=2>&gt; &gt; that are in setup phase).</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Further, going back to your original message, how
does</FONT> <BR><FONT SIZE=2>&gt; &gt; M3UA determine when the message has
been</FONT> <BR><FONT SIZE=2>&gt; &gt; processed.&nbsp; M3UA has no idea of
when the</FONT> <BR><FONT SIZE=2>&gt; &gt; message has been processed and
the state information</FONT> <BR><FONT SIZE=2>&gt; &gt; has been
checkpointed by the User Part to the Standby </FONT> <BR><FONT SIZE=2>&gt;
&gt; ASP.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;As far as T(r) is concerned, the message have
already</FONT> <BR><FONT SIZE=2>&gt; &gt; &gt;been delivered (or not) before
T(r) is started.&nbsp; I did</FONT> <BR><FONT SIZE=2>&gt; &gt; &gt;not have
a problem with messages which arrive *after*</FONT> <BR><FONT SIZE=2>&gt;
&gt; &gt;the SCTP CDI, just those that are sent *before* the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;SCTP CDI.&nbsp; So, T(r) doesn't help.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;I don't see where you have solved the problem
that a</FONT> <BR><FONT SIZE=2>&gt; &gt; &gt;Correlation Id would easily
solve.</FONT> <BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; My email only intended to layout scenarios
of</FONT> <BR><FONT SIZE=2>&gt; &gt; interest to see where and if problem(s)
existed.&nbsp;&nbsp; </FONT> <BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;--Brian</FONT> <BR><FONT SIZE=2>&gt; &gt;
&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;-- </FONT>
<BR><FONT SIZE=2>&gt;Brian F. G. Bidulock&nbsp;&nbsp;&nbsp; ¦ The reasonable
man adapts himself to the ¦</FONT> <BR><FONT
SIZE=2>&gt;[email-masked]&nbsp;&nbsp;&nbsp; ¦ world; the unreasonable
one persists in&nbsp; ¦</FONT> <BR><FONT SIZE=2>&gt;<A
HREF="http://www.openss7.org/" TARGET="_blank">http://www.openss7.org/</A> ¦
trying&nbsp; to adapt the&nbsp; world&nbsp; to himself. ¦</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp; ¦ Therefore&nbsp; all&nbsp; progress&nbsp; depends on the ¦</FONT>
<BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp; ¦ unreasonable man. -- George Bernard Shaw ¦</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;---</FONT>
<BR><FONT SIZE=2>&gt;You are currently subscribed to sigtran as:
[email-masked]</FONT> <BR><FONT SIZE=2>&gt;To unsubscribe send a blank
email to [email-masked] </FONT> </P>
<BR>
<BR>

<P><FONT SIZE=2>---</FONT>
<BR><FONT SIZE=2>You are currently subscribed to sigtran as:
[email-masked]</FONT> <BR><FONT SIZE=2>To unsubscribe send a
blank email to [email-masked]</FONT> </P>

---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY>
</HTML>

</x-html>
Date: Fri, 1 Jun 2001 13:53:16 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA: Changeover between ASPs
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      NAA27535
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.231]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken, Greg,

I would certainly find it useful if in Load-Share and Broadcast modes if the
SG would indicate "AS Insufficient Resources Pending" in an n+k arrangement
to all "Inactive" ASPs when the number of active ASPs falls to "n" rather
than indicating "AS Insufficient Resources" when the number of active ASPs
falls to "n-1".

"n-1" is a little late.  Then the ASPs can cover any pending shortfall by
going "Active" before the shortfall occurs.  Then it would be possible to
get rid of Load-Share(Standby) and Broadcast(Standby).

Now, Over-Ride...  Would it not be possbile to have any "Active" ASP other
than the current primary as a potential fail-over target?
Then when the number of active ASPs in an Over-Ride group falls to 1, the SG
could indicate "AS Insufficient Resources Pending" to the inactive ASPs to
let them know that someone had better fill in for the secondary?  In an n+k
arrangement there would be 1 primary and the other active ASPs would be
secondary, tertiary, etc.  The SG could warn when the number of active ASPs
fall to "n" so that the one of the "k" inactive ASPs can go active.

This would make the semantics of all three traffic modes identical in that
the same NTFY is sent on the same ASP state transitions.
Would that get rid of Standby?  Does that also address the failover response
concerns?

--Brian

On Fri, 01 Jun 2001, Sidebottom, Greg [BCNR:7M01:EXCH] wrote:

> 
>    Hi Ken,
>    
>     -----Original Message-----
>    From:   Ken Morneault [[1]mailto:[email-masked]]
>    Sent:   Friday, June 01, 2001 1:57 PM
>    To:     sigtran
>    Subject:        Re: M3UA: Changeover between ASPs
>    
>    Brian,
>    
>    Thanks for the detailed explanation.  I think it is reasonable
>    for M3UA to support your redundancy model.  However,
>    I would suggest the following changes:
>    
>    *  if you are not going to use Broadcast-Standby, then let's
>    delete it.  I wouldn't mind deleting Override-Standby also.
>    
>    [Greg] I wouldn't mind getting rid of all the Standby stuff myself -
>    it causes some complexity in the procedures and I'm not aware of
>    anybody implementing this (although an issue related to this came up
>    at the Bay cough discussions?).  It was added because there was some
>    input that it could speed the fail-over (the standby ASP has given
>    "permission" to the SG to fail over traffic without buffering and
>    waiting for an ASP-Active).
>    
>    *  since there is no Data Ack message, I don't see a major
>    problem with having Correlation ID in all data messages if it
>    is useful for this redundancy model.  It would only add 8 bytes
>    of overhead.
>    
>    Greg, others - any thoughts regarding these changes?
>    
>    [Greg] I'm still studying this - Brian has given me way too much
>    homework lately  2;^)
>    
>    Cheers
>    
>        Greg
>    
>    Regards,
>    
>    Ken
>    

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SG-MGC
Date: Fri, 1 Jun 2001 17:54:06 -0400 
X-Mailer: Internet Mail Service (5.5.2653.19)
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.59">
<TITLE>RE: SG-MGC</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi Satish,</FONT>
</P>

<P><FONT SIZE=2>The short answer is that it is not just about
transport.&nbsp; Applications run above the transport and these are resident
at MGCs (and not SGs).&nbsp; So in the Sigtran model it is the SGs job to
transport ISUP/TCAP/... signalling to a destination that knows what to do
with it (i.e., an MGC or&nbsp; SS7 end point in the case of the call
processing application).&nbsp;&nbsp;&nbsp; </FONT></P>

<P><FONT SIZE=2>Cheers,</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; Greg</FONT> </P>

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
SIZE=2>From: &nbsp; Satish K [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]
</FONT> <BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Friday, June 01, 2001 6:39
AM</FONT> <BR><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT>
<BR><FONT SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SG-MGC</FONT> </P>

<P><FONT SIZE=2>Hi All,</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; Why do we need MGC's in the SS7 Over IP world.
</FONT> <BR><FONT SIZE=2>ie from SG why do we need to connect to MGC not
another SG.</FONT> </P>

<P><FONT SIZE=2>satish</FONT>
</P>
<BR>

<P><FONT SIZE=2>---</FONT>
<BR><FONT SIZE=2>You are currently subscribed to sigtran as:
[email-masked]</FONT> <BR><FONT SIZE=2>To unsubscribe send a
blank email to [email-masked]</FONT> </P>

---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY>
</HTML>

</x-html>
Date: Sat, 2 Jun 2001 00:55:25 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: M2UA: Traffic Modes
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      AAA04166
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-209.dallas.net [209.44.42.209]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

I would like to propose two more Traffic Modes for M2UA: these would be
(drum roll...) Load-Share and Broadcast mode.  Although Load-Share mode is
not immediately obvious, I think that from discussions of a Broadcast mode
for M3UA you can see that M2UA can benefit from the same Broadcast redunancy
model as M3UA.

In Broadcast mode, multiple ASPs could register against the same IID in a
Broadcast Mode AS.  The SG would broadcast to all ASPs which are registered
against the IID and "active".

In Load-Share mode, it would still be quite possible for the messages
originating at an IID to be Load- Shared over ASPs based on a distribution
algorithm.
One usable distribution algorithm would be on the basis of the SLS in the RL
of the MSU.  (Think HSL here and the possibility that one ASP may not be
capable of handling the traffic from a single IID).

--Brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Sun, 03 Jun 2001 15:45:45 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA: Traffic Modes
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

I don't mind adding Traffic Modes that people plan to use.  It sounds like
you plan to use Broadcast.
Do you (or anyone else) intend to use Loadshare?

Unfortunately, I just went through the document to limit the text for
Override mode.  I'm in the process of trying to get the next revision of
M2UA to the editor, so please send any comments you have soon.

Regards,

Ken

At 12:55 AM 6/2/01 -0500, you wrote:
>Ken,
>
>I would like to propose two more Traffic Modes for M2UA:
>these would be (drum roll...) Load-Share and Broadcast
>mode.  Although Load-Share mode is not immediately
>obvious, I think that from discussions of a Broadcast
>mode for M3UA you can see that M2UA can benefit from
>the same Broadcast redunancy model as M3UA.
>
>In Broadcast mode, multiple ASPs could register against
>the same IID in a Broadcast Mode AS.  The SG would
>broadcast to all ASPs which are registered against the
>IID and "active".
>
>In Load-Share mode, it would still be quite possible
>for the messages originating at an IID to be Load-
>Shared over ASPs based on a distribution algorithm.
>One usable distribution algorithm would be on the
>basis of the SLS in the RL of the MSU.  (Think HSL
>here and the possibility that one ASP may not be
>capable of handling the traffic from a single IID).
>
>--Brian
>
>-- 
>Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
>[email-masked]    ¦ world; the unreasonable one persists in  ¦
>http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Sun, 03 Jun 2001 12:57:19 -0700
From: Jacob Heitz <[email-masked]>
Organization: Lucent Technologies, Internetworking Systems, Software 
              Engineering, Alameda
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 i86pc)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: Traffic Modes
X-MIME-Autoconverted: from 8bit to quoted-printable by drawbridge.ascend.com
id 
                      MAA15606
X-SMTP-HELO: drawbridge.ascend.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [198.4.92.1]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

I have no use for either broadcast or loadshare.
These modes could be added as an extension draft.

Ken Morneault wrote:
> 
> Brian,
> 
> I don't mind adding Traffic Modes that people plan
> to use.  It sounds like you plan to use Broadcast.
> Do you (or anyone else) intend to use Loadshare?
> 
> Unfortunately, I just went through the document to
> limit the text for Override mode.  I'm in the process
> of trying to get the next revision of M2UA to the
> editor, so please send any comments you have
> soon.
> 
> Regards,
> 
> Ken
> 
> At 12:55 AM 6/2/01 -0500, you wrote:
> >Ken,
> >
> >I would like to propose two more Traffic Modes for M2UA:
> >these would be (drum roll...) Load-Share and Broadcast
> >mode.  Although Load-Share mode is not immediately
> >obvious, I think that from discussions of a Broadcast
> >mode for M3UA you can see that M2UA can benefit from
> >the same Broadcast redunancy model as M3UA.
> >
> >In Broadcast mode, multiple ASPs could register against
> >the same IID in a Broadcast Mode AS.  The SG would
> >broadcast to all ASPs which are registered against the
> >IID and "active".
> >
> >In Load-Share mode, it would still be quite possible
> >for the messages originating at an IID to be Load-
> >Shared over ASPs based on a distribution algorithm.
> >One usable distribution algorithm would be on the
> >basis of the SLS in the RL of the MSU.  (Think HSL
> >here and the possibility that one ASP may not be
> >capable of handling the traffic from a single IID).
> >
> >--Brian
> >
> >--
> >Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> >[email-masked]    ¦ world; the unreasonable one persists in  ¦
> >http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
> >                         ¦ Therefore  all  progress  depends on the ¦
> >                         ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Sun, 3 Jun 2001 17:05:18 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: Traffic Modes
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      RAA04264
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.209]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

I can see a good deal of advantage to rationalizing the AS/ASP handling
messaging and syntax of M2UA, M3UA and other UAs.  Can we not provide the
same codepoints at least for these Traffic Modes.  M2UA may not wish to
exemplify Load-Share behaviour, but is there any reason for not having the
same codepoints and semantics as other UAs?

Gee, I'd really like to write this stuff once and have it function for all
UAs.

What is soon?

On Sun, 03 Jun 2001, Ken Morneault wrote:

> 
> 
> Brian,
> 
> I don't mind adding Traffic Modes that people plan
> to use.  It sounds like you plan to use Broadcast.
> Do you (or anyone else) intend to use Loadshare?
> 
> Unfortunately, I just went through the document to
> limit the text for Override mode.  I'm in the process
> of trying to get the next revision of M2UA to the
> editor, so please send any comments you have
> soon.
> 
> Regards,
> 
> Ken
> 

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Gradischnig, Klaus" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Mon, 4 Jun 2001 07:21:18 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: dnspri.npac.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: dnspri.npac.com [208.143.33.66]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Gery,

sounds interesting -- as all your proposals -- even if oranges might be
better.

Now, what kind of address would be contained in the DUNA/DAVA messages? An
IP address? And would this be useful unless relay on IP adddress is
possible? Or do we want to replay the discussion of GT management?

And, what about congestion?

Klaus

> -----Original Message-----
> From: Verwimp Gery [mailto:[email-masked]]
> Sent: June 01, 2001 11:15 AM
> To: sigtran
> Subject: RE: SUA5: Address Mapping text
> 
> 
> Hi Klaus,
> 
> Yes, that's still missing : some real SUA management ... Think we can
> broaden the scope of the SSNM messages to inform nodes that a 
> certain peer
> has dropped out (DUNA, DAVA) ? The address info in these 
> messages should
> make clear what kind of node it is).
> 
> - Adjacent nodes (to which an SCTP association exists) are notified by
> ASP-DOWN/INACTIVE or SCTP-CDI of the dropped-out node, as per 
> the current
> procedures.
> 
> - If such an adjacent node is a relay node, if notifies it's other
> neighbours (or : provisioned list of concerned neighbours) via DUNA.
> 
> - The adjacent nodes and the informed nodes shall update their routing
> tables (if any) and refrain from sending traffic to the 
> drop-out. Requests
> of the current status of the drop-out can be done by DAUD message.
> 
> - The adjacent nodes inform their (concerned) neighbours with 
> DAVA if the
> drop-out comes back alive (ASP-UP/ACTIVE). They also react 
> with DAVA to a
> received DAUD if the node's up.
> 
> - The informed nodes consider the drop-out back alive after 
> either a DAVA is
> received for this node, or after a certain decay time (if 
> DUNA reason was
> "transient").
> 
> - Adjacent nodes react with DUNA to a node that has tried to 
> send a message
> to an unavailable destination (response method).
> 
> These procedures are optional, and most of it happens at a 
> relay node or the
> SG.
> 
> How do you like them apples ?
> 
> ____________________________
> 
> Gery Verwimp
> > SIEMENS ATEA
> > ICN D CS D5
> > 
> > Tel. : +32 14 25 3424
> Fax : +32 14 25 3212
> mailto:[email-masked]
> ____________________________________
> 
> 
> -----Original Message-----
> From: Gradischnig, Klaus [mailto:[email-masked]]
> Sent: vrijdag 1 juni 2001 16:47
> To: sigtran
> Subject: RE: SUA5: Address Mapping text
> 
> 
> Hallo Gery,
> 
> sounds good. Just a few comments in-line.
> 
> One thing I don't have a handle on yet is what if anything 
> additionally SUA
> has to do to support failure/congestion cases in the all IP 
> (and perhaps
> also the SS7 - IP) case? 
> 
> Klaus
> 
> > -----Original Message-----
> > From: Verwimp Gery [mailto:[email-masked]]
> > Sent: June 01, 2001 4:31 AM
> > To: sigtran
> > Subject: RE: SUA5: Address Mapping text
> > 
> > 
> > Hi Klaus,
> > 
> > Yes, with this concept of "AMF" (address mapping function ... 
> > why not "SRF"
> > SUA relay function ...) SUA could really do without the 
> > routing key things.
> > What I have in mind is following black box, either at a SG or 
> > an ASP or an
> > SUA relay node in general :
> > 
> > Incoming message (either from SS7, with MTP routing label and SCCP
> > parameters, or from IP, with SCTP header and SUA parameters)
> 
> You may also want to include the IP address parameters, or?
> 
> > 
> > ==> pass to SRF for analysis and determine :
> > 	- whether the message must be passed to a local user
> > 	- whether the message must be "relayed on" to either an SS7
> > destination (IP -> SS7 at SG) or to an IP destination (SS7 -> 
> > IP at SG or
> > all-IP case)
> > 
> > Any information can be used/provisioned for this purpose. One 
> > may call it an
> > enhanced GTT, because it can be based on IP address, GT, host 
> > name, ...
> 
> IP address should be allowed as GT address info. Destination 
> IP address in
> the IP label is perhaps also useful in case the node has multiple IP
> addresses. 
> 
> > 
> > My comment on DPC+SSN only applied to "valid address 
> > information in the
> > incoming message". Just a point code won't do either as 
> > called (who's going
> > to handle it) as calling (backrouting ?) address. Of course, 
> > the SRF may or
> > may not take this SSN into account. E.g. the SG may forward 
> > every SS7 SCCP
> > message routed on DPC+SSN (and received from certain OPCs) to 
> > the ASPs of a
> > specified AS without further consideration to SSN.
> >
> > 
> > The IP address is strictly an SUA address parameter. For 
> > interworking with
> > SS7, one endpoint only has the DPC+SSN or GT options. You can 
> > of course put
> > an IP(v4) address in your GT, or convert a GT to an IPaddress 
> > (ENUM and DNS)
> > ...
> > 
> > 
> > Actually, what GTT or SRF should derive locally, is merely a 
> > "handle" to the
> > next hop, e.g.
> > - a route set number, by which MTP knows the routeset and 
> DPC to go to
> > - an SCTP association ID, by which SCTP knows the 
> > (multihomed) route and IP
> > address to go to
> > - of course, this "handle" could be the DPC and/or IP address 
> > itself, e.g.
> > if you use ENUM/DNS means to translate your E.164 stuff.
> > 
> > The SRF will avoid having to have a fully meshed SCTP (or transport)
> > network.
> > 
> > Greetings,
> > 
> > ____________________________
> > 
> > Gery Verwimp
> > > SIEMENS ATEA
> > > ICN D CS D5
> > > 
> > > Tel. : +32 14 25 3424
> > Fax : +32 14 25 3212
> > mailto:[email-masked]
> > ____________________________________
> > 
> 
> 
> ---
> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Majnik Matej RDSP <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: SCTP & M3UA developement
Date: Mon, 4 Jun 2001 14:39:51 +0200
X-Mailer: Internet Mail Service (5.5.2448.0)
X-SMTP-HELO: cisc01.iskratel.si
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: cisc01.iskratel.si [193.2.48.125]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi all,

how long (approx) does it take to develop SCTP and M3UA protocols?

thanx,

Matej

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 4 Jun 2001 12:30:40 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M3UA M2UA: ASP Partitioning
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      MAA14336
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-207.dallas.net [209.44.42.207]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

All,

I understand that ASP to ASP communications is outside the scope of both the
M2UA and M3UA documents, however, I am trying to find a solution to the
problem where ASPs lose communication with each other.  Take the a simple
two ASP case in the same AS as follows:

               +-------+           +-------+
               |       |           |       |
               |  ASP  +-----------+  ASP  |
               |   1   |           |   2   |
               +---+---+           +---+---+
                   |                   |
                   |                   |
     Association   +-------+   +-------+  Association
                           |   |
                           |   |
                         +-+---+-+
                         |       |
                         |  SGP  |
                         |       |
                         +-------+

Now, a couple of comments:  The ASPs are geographically separated (otherwise
there isn't much point in having them use separate associations).
Therefore, the ASP-ASP communications link can suffer failures.  When the
ASP-ASP communications fails we have the following problem:

               +-------+           +-------+
               |       |           |       |
               |  ASP  +--   X   --+  ASP  |
               |   1   |           |   2   |
               +---+---+           +---+---+
                   |                   |
                   |                   |
     Association   +-------+   +-------+  Association
                           |   |
                           |   |
                         +-+---+-+
                         |       |
                         |  SGP  |
                         |       |
                         +-------+

In the above diagram, ASP2 no longer knows the state of ASP1.  Nor can ASP2
tell whether ASP1 has failed or whether simply communications to ASP1 has
failed.  That is ASP2 cannot locally determine whether the above is the case
or whether the following diagram is the case:

               X X X X X           +-------+
                                   |       |
               X  ASP  X--   X   --+  ASP  |
                   1               |   2   |
               X X X X X           +---+---+
                   |                   |
                                       |
     Association       X  -+   +-------+  Association
                           |   |
                           |   |
                         +-+---+-+
                         |       |
                         |  SGP  |
                         |       |
                         +-------+

In both cases, the SG is aware of what the state of ASP1 is with regards to
being able to exchange information with the SS7 network.

I would like to see a mechanism in the UAs which allows ASP2 to be notified
of the change in state of ASP1 with respect to the SG.  This would require
an ASP identifier which is provided to the SG with the ASP-Up and a
notification (NTFY) sent to other ASPs in the AS when an ASP makes some
state transitions.  These notifications can be completely advisory (in that
it is still up to the ASP to take action on them or ignore them).

The addition of an ASP Id would also help the SG determine whether it has
multiple associations open to the same ASP.

--Brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 4 Jun 2001 14:08:58 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M3UA: Packing of DATA Payloads
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      OAA16686
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.207]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

I see a number of difficulties in the packing and unpacking, and filtering
of DATA Payload information.  Perhaps not suprisingly, the MTP primitive
MTP-TRANSFER does not contain the MTP Routing Label in the data payload.
The MTP RL is the MTP Level 3 Header (much like an IP header) and is not
part of the payload transferred to an from the MTP-User.

The MTP-TRANSFER primitive is defined in Q.701 as having the following
parameters:

        OPC (see 2.2/Q.704)
        DPC (see 2.2/Q.704)
        SLS (see 2.2/Q.704)
        SIO (see 14.2/Q.704)
        User data (see 2.3.8/Q.703)

You will find the same list of parameters in Table 9/T1.112.1.

In neither list is the NI (Network Indicator) or MP (Message Priority)
listed.  This is, IMHO, because the assignment of these values is to be
peformed by MTP and is not at the discretion of the MTP-User.

In comparing this primitive to the Payload Data Message (DATA) in Section
3.3.1 and bearing in mind the statements of Section 4.1.1 with regards to
MTP-Transfer, and considering IPSP operation, I have the following problems:

When M3UA receives an MTP-TRANSFER primitive from the NIF or MTP-User, M3UA
is required to pack a routing label into the Payload of a DATA message.
Because the MTP-TRANSFER primitive does not contain NI or MP parameters,
M3UA will have to generate them.
Also, M3UA will have to choose some variant for the packing of the DATA
Payload.  The receiving M3UA will have to unpack the same data to be able to
generate an MTP-TRANSFER primitive to its MTP-User.

This seems ridiculous, particularly in the IPSP case, where the packing and
unpacking is rather arbitrary.  It makes far more sense to pass the OPC,
DPC, SLS and SIO as separate parameters of the DATA message and leave the
User data from the MTP-TRANSFER primitive as the Payload Data.

You will note that MP is *not* part of the MTP-TRANSFER primitive and there
is no need to distinguish between ITU (w/o MP), ANSI, and TTC approaches in
the Payload Data when the proper parameters are added to the message.  It is
the responsibility of MTP Level 3 to determine the Message Priority of a
MTP-User message and not the responsibility of the MTP-User.  The same is
true for NI and it no longer becomes necessary to include a Network
Appearance parameter at all.  (More on Network Appearance later...)

The format of the routing label, by the way, can be dependent upon SIO, and
in some networks it is.  For example, one SIO value can be assigned for
National ISUP (where the routing label is formatted using, say 24-bit point
code) and another assigned for International ISUP (where the routing label
is formatted using 14-bit point code).  See Q.704 (07/96) Section 2.2.1,
last paragraph on Page 4.

Treating the OPC, DPC, SLS and SIO as separate from the message is no
different than placing the Affected PC in a parameter for the MTP-PAUSE,
MTP-RESUME, and MTP-STATUS primitives.  The point codes should be split out
with TLV parameters similar to those used to represent point codes in the
DUNA and DAVA messages.  SLS and SIO will require their own parameters.
Because these parameters are mandatory parameters of the MTP-TRANSFER
primitive, it may be useful to group them and place them in a single TLV as
follows:

    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 = 28           |          Length = 24          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Originating Point Code                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Destination Point Code                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Signalling Link Selection   |       Service Indicator       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Tag = 3            |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                        Protocol Data                          /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where now the Protocol Data would only contain MTP-User data.

Note that I have removed the "Network Appearance" parameter.  This is
because it is useless.  The Network Appearance parameter is based on the
premise that it somehow defines the point code format used.
This is not the case, as the Service Indicator Octet (and NI) must also be
taken into consideration when determining the point code format.

By the same token, Network Appearance is useless in DUNA and DAVA messages.
There is no network indicator provided in MTP-PAUSE and MTP-RESUME
primitives.

On the other hand, for Q.701 7.2.6 operation with indication of SIF
permitted in TFP/TFA messages, the Affected PC parameters of DUNA and DAVA
need to be expanded to include the SIF bits present in these indications.

Actually, Network Appearance should be struck from the whole document.

--Brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 05 Jun 2001 09:39:24 +0530
From: Vijay Kumar Choudhary <[email-masked]>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en,pdf
To: "sigtran" <[email-masked]>
Subject: subscribe sigtran
X-SMTP-HELO: india.mercurykr.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [165.133.13.60]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

subscribe sigtran
Regards,
Vijay

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 4 Jun 2001 23:26:15 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: M2UA: SCTP lifetime
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-207.dallas.net [209.44.42.207]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

Did you realize that setting 2 seconds lifetimes on any messages for M2UA
serves no useful purpose.  MTP Level 3 heartbeats using SLTM/SLTA for each
signalling link every 0.5-1.0 seconds and only attempt twice.  So signalling
links will fail if a DATA message is blocked for 1.0 to 2.0 seconds anyway
(whether in SCTP or M2UA or MTP2) and the test is performed every 0.5 to 1.0
seconds.

Besides the fact that there is delay from M2UA to MTP2, across the SS7
network and back through the MTP2, M2UA and back to MTP3 means that the SLTM
test is pretty much guaranteed to fail the link long before a 2 second
lifetime is reached by SCTP in one direction...

It might be a good idea to strike this paragraph.  The implementation should
be able to set any lifetimes that they deem fit, even no lifetimes.

--Brian

>   1.5.3.2  SCTP Send Primitive
>   
>   M2UA shall set the lifetime parameter in the SEND primitive to SCTP 
>   when sending a message.  When SCTP times out a message, M2UA shall
>   abort the SCTP association and follow the same procedure as for a
>   failed SCTP association.
>   
>   The default value for the lifetime shall be 2 seconds.  Some messages,
>   like STATUS_FLUSH_BUFFERS may need a shorter lifetime.  This is for
>   further study.

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 04 Jun 2001 22:35:59 -0700
From: Jacob Heitz <[email-masked]>
Organization: Lucent Technologies, Internetworking Systems, Software 
              Engineering, Alameda
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: SCTP lifetime
X-SMTP-HELO: drawbridge.ascend.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: drawbridge.ascend.com [198.4.92.1]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

The purpose of this is to handle congestion in SCTP.
A congested link is one that takes too long to deliver its payload. The
lifetime is a good approximation of that time.

While it is acceptable for MTP2 to delay delivery for several seconds (as
long as SIB is used), such delay is not acceptable for M2UA. It may be ok
for M2UA to delay an MSU for a few seconds sometimes, but some M2UA messages
are very sensitive to delays. Take EVENT_RPO_EXIT and STATUS_FLUSH_BUFFERS
for examples.

It is not uncommon to find IP networks spanning a continent with sub 100mS
round trip times. M2UA needs a fast IP network and 2 seconds does not seem
excessive to me.

Congestion indication messages should keep an M2UA link fairly clear. If
congestion were to occur due to effects in the IP network, a changeover is
in order. Observance of the SCTP lifetime will ensure this.

SLTM/SLTA will not serve this purpose. The interval timer for sending SLTM
is 30-90 seconds, not 0.5-1.0 seconds.
The timeout value to get an SLTA is 4-12 seconds. You are correct about the
two attempts.
These two timers are specified in Q.707.

It is correct that these timers should be so long. They are not protecting
delay sensitive M2UA control messages such as STATUS_FLUSH_BUFFERS.

"Brian F. G. Bidulock" wrote:
> 
> Ken,
> 
> Did you realize that setting 2 seconds lifetimes on any
> messages for M2UA serves no useful purpose.  MTP Level 3
> heartbeats using SLTM/SLTA for each signalling link every
> 0.5-1.0 seconds and only attempt twice.  So signalling
> links will fail if a DATA message is blocked for 1.0 to
> 2.0 seconds anyway (whether in SCTP or M2UA or MTP2) and
> the test is performed every 0.5 to 1.0 seconds.
> 
> Besides the fact that there is delay from M2UA to MTP2,
> across the SS7 network and back through the MTP2, M2UA
> and back to MTP3 means that the SLTM test is pretty
> much guaranteed to fail the link long before a 2 second
> lifetime is reached by SCTP in one direction...
> 
> It might be a good idea to strike this paragraph.  The
> implementation should be able to set any lifetimes that
> they deem fit, even no lifetimes.
> 
> --Brian
> 
> >   1.5.3.2  SCTP Send Primitive
> >
> >   M2UA shall set the lifetime parameter in the SEND primitive to SCTP
> >   when sending a message.  When SCTP times out a message, M2UA shall
> >   abort the SCTP association and follow the same procedure as for a
> >   failed SCTP association.
> >
> >   The default value for the lifetime shall be 2 seconds.  Some messages,
> >   like STATUS_FLUSH_BUFFERS may need a shorter lifetime.  This is for
> >   further study.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 5 Jun 2001 00:58:33 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: SCTP lifetime
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-207.dallas.net [209.44.42.207]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Jacob,

On Mon, 04 Jun 2001, Jacob Heitz wrote:

(snip)
> 
> While it is acceptable for MTP2 to delay delivery for
> several seconds (as long as SIB is used), such delay

This is not a correct statement.  It is acceptable for MTP2 to delay
acknowledgement for several seconds if SIB is used (not delay delivery).

> is not acceptable for M2UA. It may be ok for M2UA to
> delay an MSU for a few seconds sometimes, but some

It is no more acceptable that M2UA delay *delivery* of messages for several
seconds that it is for MTP2.

> M2UA messages are very sensitive to delays. Take
> EVENT_RPO_EXIT and STATUS_FLUSH_BUFFERS for examples.
> 
> It is not uncommon to find IP networks spanning a
> continent with sub 100mS round trip times. M2UA needs
> a fast IP network and 2 seconds does not seem excessive
> to me.
> 
> Congestion indication messages should keep an M2UA link
> fairly clear. If congestion were to occur due to effects
> in the IP network, a changeover is in order. Observance
> of the SCTP lifetime will ensure this.
> 
> SLTM/SLTA will not serve this purpose. The interval timer
> for sending SLTM is 30-90 seconds, not 0.5-1.0 seconds.
> The timeout value to get an SLTA is 4-12 seconds. You
> are correct about the two attempts.
> These two timers are specified in Q.707.

I always set them at 0.5-1.0 for the SLTA.  Works better.

> 
> It is correct that these timers should be so long. They
> are not protecting delay sensitive M2UA control messages
> such as STATUS_FLUSH_BUFFERS.
> 

They don't protect anything.  They just say when things have already taken
too long.

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 04 Jun 2001 23:15:45 -0700
From: Jacob Heitz <[email-masked]>
Organization: Lucent Technologies, Internetworking Systems, Software 
              Engineering, Alameda
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: SCTP lifetime
X-SMTP-HELO: drawbridge.ascend.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: drawbridge.ascend.com [198.4.92.1]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

"Brian F. G. Bidulock" wrote:
> >
> > While it is acceptable for MTP2 to delay delivery for
> > several seconds (as long as SIB is used), such delay
> 
> This is not a correct statement.  It is acceptable
> for MTP2 to delay acknowledgement for several seconds
> if SIB is used (not delay delivery).

After SIB ends, the receiver may send negative acknowledgement. This will
cause the sender to retransmit. It will cause delay. It is acceptable in
Q.703. Q.703 SDLs even have a "Congestion discard" variable to discard
received MSUs during the busy condition.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
X-OpenMail-Hops: 2
Date: Tue, 5 Jun 2001 15:17:02 +0900
Subject: Is SCTP suitable for client-server model
TO: "sigtran" <[email-masked]>
X-SMTP-HELO: omail01.samsung.co.kr
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: omail01.samsung.co.kr [203.254.197.73]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hello All,

I have following doubts.

*        Is SCTP suitable for client server like communication model ?

*        If yes, then in case where multiple co-located clients binds to say
same server,
         is not there redundant heartbeat msgs. per association.

*        If above is correct, then does SCTP optimize such scenario.

thanks,

regards,
- nalin

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 04 Jun 2001 23:32:53 -0700
From: Jacob Heitz <[email-masked]>
Organization: Lucent Technologies, Internetworking Systems, Software 
              Engineering, Alameda
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: Is SCTP suitable for client-server model
X-SMTP-HELO: drawbridge.ascend.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: drawbridge.ascend.com [198.4.92.1]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

[email-masked] wrote:
> 
> Hello All,
> 
> I have following doubts.
> 
> *        Is SCTP suitable for client server like communication model ?
> 
> *        If yes, then in case where multiple co-located clients binds to
say same server,
>          is not there redundant heartbeat msgs. per association.

Yes.

> 
> *        If above is correct, then does SCTP optimize such scenario.

A heartbeat protects each association. One association may fail without
other colocated associations failing. Having said that, you may not require
such protection. In that case, you are free to make the optimization in your
implementation. The frequency of heartbeats is completely determined by the
sender of the heartbeats, so your optimization will not break your peer
entities.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Schwarzbauer Hanns Juergen <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA: Changeover between ASPs
Date: Tue, 5 Jun 2001 09:18:16 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-MIME-Autoconverted: from 8bit to quoted-printable by
gorilla.mchh.siemens.de 
                      id JAA05653
X-SMTP-HELO: gorilla.mchh.siemens.de
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: gorilla.mchh.siemens.de [194.138.158.18]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

see my comments inline below

> -----Original Message-----
> From:	Ken Morneault [SMTP:[email-masked]]
> Sent:	Friday, June 01, 2001 7:57 PM
> To:	sigtran
> Subject:	Re: M3UA: Changeover between ASPs
> 
> 
> 
> Brian,
> 
> Thanks for the detailed explanation.  I think it is reasonable
> for M3UA to support your redundancy model.  However,
> I would suggest the following changes:
> 
> *  if you are not going to use Broadcast-Standby, then let's
> delete it.  I wouldn't mind deleting Override-Standby also.
> 
> *  since there is no Data Ack message, I don't see a major 
> problem with having Correlation ID in all data messages if it
> is useful for this redundancy model.  It would only add 8 bytes
> of overhead. 
	[HJS]  I still see no advantage having this Correlation ID in the
data messages. If the usage is left to the implementation, even worse. 
	The question what happens, if a message (indicating that an other
message has been successfully processed) has been queued in the ASP for
sending and the association breaks before sending this message is still
open.

> Greg, others - any thoughts regarding these changes?
> 
> Regards,
> 
> Ken
> 
> At 12:54 AM 6/1/01 -0500, you wrote:
> >Ken,
> >
> >I agree with you whole-heartedly on the Override-Standby.  It's
> >useless.  However, I also believe that Load-Share is useless as
> >well.  Let me offer a proposal for a Broadcast redundancy model,
> >show you how I intend to use it, and show you why I need a
> >Correlation Id, at least as an optional parameter which must
> >be used in some circumstances.
> >
> >Bear with me.
> >
> >
> >I would like to propose two new Traffic Mode Types with text as
> >follows (I had mentioned this to Greg before):
> >
> >In Section 3.5.5 change the following:
> >
> >.   Traffic Mode Type: 32-bit (unsigned integer)
> >.
> >.      The Traffic Mode Type parameter identifies the traffic mode of
> >.      operation of the ASP within an AS.  The valid values for Type are
> >.      shown in the following table.
> >.
> >.           1       Over-ride
> >.           2       Load-share
> >.           3       Over-ride (Standby)
> >.           4       Load-share (Standby)
> >|           5       Broadcast
> >|           6       Broadcast (Standby)
> >.   
> >.      Within a particular Routing Context, only one Traffic Mode Type
> >.      can be used.  The Over-ride value indicates that the ASP is 
> >.      operating in Over-ride mode, and the ASP takes over all 
> >.      traffic in an Application Server (i.e., primary/back-up
operation), 
> >.      over-riding any currently active ASPs in the AS.  In Load-share 
> >.      mode, the ASP will share in the traffic distribution with any
other 
> >.      currently active ASPs.  The Standby versions of the Over-ride and 
> >.      Load-share Types indicate that the ASP is declaring itself ready
to 
> >.      accept traffic but leaves it up to the sender as to when the
traffic 
> >.      is started.  Over-ride (Standby) indicates that the traffic sender

> >.      continues to use the currently active ASP until it can no longer 
> >.      send/receive traffic (i.e., the currently active ASP transitions
to 
> >.      Down or Inactive).  At this point the sender MUST move the standby

> >.      ASP to Active and commence traffic.  Load-share (Standby) is
similar 
> >.      - the sender continues to load-share to the current ASPs until it
is 
> >.      determined that there is insufficient resources in 
> >.      the Load-share group.  When there are insufficient ASPs, the
sender 
> >.      MUST move the ASP to Active.
> >|      In Broadcast mode, the ASP will receive the identical traffic
> >|      distribution as any other currently active ASPs.  The Standby
> >|      version of the Broadcast Type indicates that the ASP is declaring
> >|      itself as ready to accept traffic but leaves it up to the sender> 
> >|      as to when the traffic is started.  Broadcast (Standby) is
> >|      similar to other Standby modes in that the sending continues to
> >|      broadcast traffic to the current ASPs until it is determined that
> >|      there are insufficient resources in the Broadcast group.  When
> >|      there are insufficient ASPs, the sender MUST move the ASP to
> >|      Active.
> >
> >In Section 3.5.6 add ASPAC (broadcast (standby)) with the others.
> >
> >Add to Section 4.1.1:
> >
> >
> >.   From the list of ASPs within the AS table, an Active ASP is selected 
> >.   and a DATA message is constructed and issued on the corresponding
SCTP 
> >.   Association.  If more than one ASP is active (i.e., traffic is to be 
> >.   load-shared across all the active ASPs), one of the active ASPs from 
> >.   the list is selected.  The selection algorithm is implementation 
> >.   dependent but could, for example, be round-robin or based on, for 
> >.   example, the SLS or ISUP CIC.  The appropriate selection algorithm
must 
> >.   be chosen carefully as it is dependent on application assumptions and

> >.   understanding of the degree of state coordination between the active 
> >.   ASPs in the AS. 
> >|
> >|   In the Broadcast mode, all active ASP(s) are selected and a DATA
> >|   message is constructed and issued on each of the corresponding SCTP
> >|   Association(s).
> >|
> >
> >Alter to Section 4.3.3.4 as follows:
> >
> >
> >|   There are six modes of Application Server traffic handling in the SG 
> >|   M3UA - Over-ride, Over-ride (Standby), Loadshare, Load-share 
> >|   (Standby), Broadcast, and Broadcast (Standby).  The Traffic Mode
> >.   Type parameter in the ASPAC message indicates the traffic handling
> >.   mode used in a particular Application Server. If the SG determines
> >.   that the mode indicated in an ASPAC is unsupported or incompatible
> >     ...
> >
> >Add to the end of Section 4.3.3.4 as follows:
> >
> >|   In the case of a Broadcast mode AS, reception of an ASPAC message at
> >|   an SG or IPSP causes the direction of traffic to the ASP sending the
> >|   ASPAC, in addition to all other ASPs that are currently active in
> >|   the AS.  The SG MUST broadcast traffic to all of the active ASPs
> >|   within the AS.
> >|
> >|   As in the Load-share mode, an SG or IPSP, upon reception of an ASPAC
> >|   for the first ASP in a Broadcast AS, MAY choose not to direct
> >|   traffic to a newly active ASP until it determines that there are
> >|   sufficient resources to handle the expected load (e.g., until there
> >|   are sufficient ASPs "Active" in the AS).
> >|
> >|   In the case of Broadcast (Standby) mode, the traffic is not started
> >|   to the ASP until the SG or IPSP determines that there are
> >|   insufficient resources available in the AS.  This is likely when one
> >|   of the active broadcast ASPs transitions to the "Inactive" or "Down"
> >|   state.  At this point the ASP that sent the Broadcast (Standby)
> >|   ASPAC is moved to the Active state and traffic is started.  A second
> >|   ASP-Active Ack message with a new Traffic Mode Type ("Broadcast"
> >|   previously "Broadcast (Standby)") is sent to the ASP.  A Notify
> >|   ("Insufficient ASP resources active in AS") message is not sent in
> >|   this case.
> >|
> >|   All ASPs within a broadcast mode AS must coordinate between
> >|   themselves to determine which portion of the broadcast traffic they
> >|   will handle.
> >
> >In the middle of Section 4.3.3.5 add:
> >
> >|   In the case of a Broadcast mode AS, the SG moves the ASP to the
> >|   "Inactive" state and the AS traffic is broadcast only to the
> >|   remaining "active" ASPs.  A NTFY(Insufficient ASP resources active
> >|   in AS) may be sent to all inactive ASPs, if required.  However, if a
> >|   Broadcast (Standby) ASP is available, it may be now immediately
> >|   included in the broadcast group and a Notify message is not sent.> 
> >|   An ASPIA Ack message is sent to the ASP after all traffic is halted
> >|   and Layer Management is informed with an ASP-INACTIVE indication
> >|   primitive.
> >
> >And here's the rub: also add to Section 4.3.3.5:
> >
> >|   Whenever an ASP in a Broadcast mode AS becomes active, the SG MUST
> >|   tag the first DATA message broadcast in each SCTP stream with a
> >|   unique Correlation Id parameter.  The purpose of this Correlation Id
> >|   is to permite the newly active ASP to synchronize its processing of
> >|   the traffic in each ordered stream with other ASPs in the broadcast
> >|   group.
> >
> >
> >Modify Section 4.3.3.6 to:
> >
> >
> >.   In the case where a Notify (AS-Pending) message is sent by an SG that

> >.   now has no ASPs active to service the traffic, or a NTFY(Insufficient

> >.   ASP resources active in AS) is sent in the Loadshare
> >|   or Broadcast modes, the Notify 
> >.   does not explicitly compel the ASP(s) receiving the message to become

> >.   active. The ASPs remain in control of what (and when) traffic action
is 
> >.   taken.
> >
> >
> >In my previous proposal make the Correlation Id parameter in the DATA
> >message Optional and you can remove the Correlation Id Ack if you'd
> >like.
> >
> >If you would like to rework this so that Broadcast is a separate
> >algorithm under Loadshare, that's fine too.  Just as long as the ASP can
> >require Broadcast algorithm and require the addition of a Correlation Id
> >to messages in each stream upon going active, I see no problem.
> >
> >Now, as promised, here is the implementation: (This is not conjecture, I
> >have built them this way before.)
> >
> >I have break down my ISUP application server into CIC ranges which
> >correspond to ISUP circuit management groups.  (Basically that is one AS
> >per 24 circuits.)
> >
> >I arrange at the SG to distribute messages over streams in each of the
> >16 (or more) associations by OPC/DPC/SLS/CIC to the maximum number of
> >streams permissible.  I have 16 ASPs which I register against all of the
> >AS's in Broadcast Mode.
> >
> >Upon going up with a sufficient number of ASPs active, the ASPs begin
> >receiving traffic and each initial DATA message in each stream contains
> >a Correlation Id which the ASP uses as a sequence number to start
> >numbering the messages in each stream (I cannot be sure that the SSNs
> >will be synchronized at the SG).
> >
> >Each ASP knows the other ASPs that are active in the broadcast group by
> >inter-ASP communication.  Each ASP knows the assignment of the other
> >ASPs to traffic (say, each ASP processes one of 16 streams according to
> >it's ASP number in the pool).  For it's assigned trafffic the ASP is
> >Master.  For the other 15 of 16 streams the ASP is Slave.
> >
> >For messages received on the streams for which the ASP is Master the ASP
> >processes the message through its ISUP state machines and responds with
> >control messages and reply ISUP messages back to the SG.  For messages
> >received on the streams for which the ASP is Slave, the ASP processes
> >the message through its ISUP state machines but does not dispatch the
> >controll messages or ISUP replies.  It only moves through the state
> >transitions.
> >
> >After processing state transitions for streams upon which the ASP is
> >Master, the ASP also broadcasts the Stream Id and Correlation Id
> >associated with the message to the slave ASPs for that stream.  This
> >checkpoints the slaves.
> >
> >Each ASP, when processing messages on Slave streams should buffer
> >incoming messages long enough that the checkpoint from the Master for
> >the stream (or separate inter-ASP heartbeat) verifies the viability of
> >the Master.  Therefore, each ASP is a Leader on its Master stream and a
> >Follower on its slave streams.
> >
> >When an ASP fails, either through lost of inter-ASP checkpoint or
> >heartbeat, a prearranged ASP takes over as Master for the failed ASPs> 
> >streams beginning distribution of control and ISUP responses at the
> >point which minimizes duplication and discard.
> >
> >With some good software design ;) this loosley coupled interlocking
> >leader-follower arrangement can perform well, has extremely low
> >inter-ASP sychronization overheads and has minimal message loss and
> >call-state mishandling.  Many low-reliability or low-performance ASPs
> >can be grouped into large arrays that scale well.
> >
> >The difficulty in the arrangement come when adding an ASP to the group.
> >It must have a marker in the message streams upon which to start
> >synchonizing its behaviour.  It must replicate state from one of its
> >peers for the marked point before starting slave operation and
> >subsequently master operation on the traffic.  (The Broadcast (Standby)
> >mode is really useless: I don't intend to use it.)
> >
> >This is where the Correlation Id come in.  I need it to mark the traffic
> >for synchronization with my ASP peers.  I would prefer if it was
> >contained in all DATA messages, however, if the SG will place it in the
> >first DATA message broadcast on any stream within a time interval from
> >the transition of an ASP from the "inactive" to "active" state within
> >the broadcast group, then the ASP can infer the correlation Id of the
> >other messages from the stream and the SSN.
> >
> >
> >Does this explain the need a little better?
> >
> >
> >
> >
> >On Thu, 31 May 2001, Ken Morneault wrote:
> >
> > > 
> > > 
> > > Brian,
> > > 
> > > See below.
> > > 
> > > Ken
> > > 
> > > At 12:24 PM 5/31/01 -0500, Brian F. G. Bidulock wrote:
> > > >Ken,
> > > >
> > > >Per your 1) and 2):
> > > >
> > > >The M3UA ASP state diagrams do not distinguish between
> > > >SCTP CDI fatal and non-fatal.  The diagrams show the
> > > >ASP always moving to the DOWN state as a result of an
> > > >SCTP CDI.  The SG, in this case is required to send
> > > >messages to the standby ASP.
> > > 
> > > 
> > > Sorry, I do not value the Override-Standby option in ASP 
> > > Active and would not use it.  The decision regarding failover 
> > > should be made by the ASPs not the SG.  Clearly, the 
> > > SG does not have enough information to determine a 
> > > failover condition.  
> > > 
> > > See Section 5.2 for failover examples. 
> > > 
> > > There is no way to guarantee that there will
> > > be no messages lost during an ungraceful failover.
> > > Even with a "Correlation ID", it is highly likely that
> > > messages will be lost.  More importantly, some
> > > User Part state information will be lost (i.e. calls
> > > that are in setup phase).
> > > 
> > > Further, going back to your original message, how does
> > > M3UA determine when the message has been
> > > processed.  M3UA has no idea of when the
> > > message has been processed and the state information
> > > has been checkpointed by the User Part to the Standby 
> > > ASP.
> > > 
> > > 
> > > >As far as T(r) is concerned, the message have already
> > > >been delivered (or not) before T(r) is started.  I did
> > > >not have a problem with messages which arrive *after*
> > > >the SCTP CDI, just those that are sent *before* the
> > > >SCTP CDI.  So, T(r) doesn't help.
> > > >
> > > >I don't see where you have solved the problem that a
> > > >Correlation Id would easily solve.
> > > 
> > > My email only intended to layout scenarios of
> > > interest to see where and if problem(s) existed.   
> > > 
> > > >--Brian
> > > >
> >
> >-- 
> >Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> >[email-masked]    ¦ world; the unreasonable one persists in  ¦
> >http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
> >                         ¦ Therefore  all  progress  depends on the ¦
> >                         ¦ unreasonable man. -- George Bernard Shaw ¦
> >
> >
> >---
> >You are currently subscribed to sigtran as: [email-masked]
> >To unsubscribe send a blank email to
[email-masked] 
> 
> 
> 
> ---
> You are currently subscribed to sigtr> an as:
[email-masked]
> To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Tue, 5 Jun 2001 10:39:06 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x2.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x2.nokia.com [131.228.20.22]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi all,

Catching up on some email ...

> Simple : in an all IP-environment, you may also route on GT 
> or hostname. The AMF then has the responsibility of mapping this 
> to an SCTP association (IP-address) and either the same GT/hostname 
> or a new one (the destination might also be a relay node) !!

Agreed.

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Tue, 5 Jun 2001 10:26:07 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades6.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mailhost2.atea.be [194.78.143.126]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Klaus,

SCON messages for congestion ! BTW does SCTP inform it's upper layer of
congestion (status information) ?
Congestion level and importance value are both in the range (0..7).

The info would be the (global) IP address, and the receiver of
DUNA/DAVA/SCON should preferrably know what node it represents. Since the
nodes are almost neighbours, this seems reasonable. No replay of GT
discussion.

bye;

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Gradischnig, Klaus [mailto:[email-masked]] Sent:
maandag 4 juni 2001 14:21
To: sigtran
Subject: RE: SUA5: Address Mapping text

Gery,

sounds interesting -- as all your proposals -- even if oranges might be
better.

Now, what kind of address would be contained in the DUNA/DAVA messages? An
IP address? And would this be useful unless relay on IP adddress is
possible? Or do we want to replay the discussion of GT management?

And, what about congestion?

Klaus

> -----Original Message-----
> From: Verwimp Gery [mailto:[email-masked]]
> Sent: June 01, 2001 11:15 AM
> To: sigtran
> Subject: RE: SUA5: Address Mapping text
> 
> 
> Hi Klaus,
> 
> Yes, that's still missing : some real SUA management ... Think we can
> broaden the scope of the SSNM messages to inform nodes that a 
> certain peer
> has dropped out (DUNA, DAVA) ? The address info in these 
> messages should
> make clear what kind of node it is).
> 
> - Adjacent nodes (to which an SCTP association exists) are notified by
> ASP-DOWN/INACTIVE or SCTP-CDI of the dropped-out node, as per 
> the current
> procedures.
> 
> - If such an adjacent node is a relay node, if notifies it's other
> neighbours (or : provisioned list of concerned neighbours) via DUNA.
> 
> - The adjacent nodes and the informed nodes shall update their routing
> tables (if any) and refrain from sending traffic to the 
> drop-out. Requests
> of the current status of the drop-out can be done by DAUD message.
> 
> - The adjacent nodes inform their (concerned) neighbours with 
> DAVA if the
> drop-out comes back alive (ASP-UP/ACTIVE). They also react 
> with DAVA to a
> received DAUD if the node's up.
> 
> - The informed nodes consider the drop-out back alive after 
> either a DAVA is
> received for this node, or after a certain decay time (if 
> DUNA reason was
> "transient").
> 
> - Adjacent nodes react with DUNA to a node that has tried to 
> send a message
> to an unavailable destination (response method).
> 
> These procedures are optional, and most of it happens at a 
> relay node or the
> SG.
> 
> How do you like them apples ?
> 
> ____________________________
> 
> Gery Verwimp
> > SIEMENS ATEA
> > ICN D CS D5
> > 
> > Tel. : +32 14 25 3424
> Fax : +32 14 25 3212
> mailto:[email-masked]
> ____________________________________
> 
> 
> -----Original Message-----
> From: Gradischnig, Klaus [mailto:[email-masked]]
> Sent: vrijdag 1 juni 2001 16:47
> To: sigtran
> Subject: RE: SUA5: Address Mapping text
> 
> 
> Hallo Gery,
> 
> sounds good. Just a few comments in-line.
> 
> One thing I don't have a handle on yet is what if anything 
> additionally SUA
> has to do to support failure/congestion cases in the all IP 
> (and perhaps
> also the SS7 - IP) case? 
> 
> Klaus
> 
> > -----Original Message-----
> > From: Verwimp Gery [mailto:[email-masked]]
> > Sent: June 01, 2001 4:31 AM
> > To: sigtran
> > Subject: RE: SUA5: Address Mapping text
> > 
> > 
> > Hi Klaus,
> > 
> > Yes, with this concept of "AMF" (address mapping function ... 
> > why not "SRF"
> > SUA relay function ...) SUA could really do without the 
> > routing key things.
> > What I have in mind is following black box, either at a SG or 
> > an ASP or an
> > SUA relay node in general :
> > 
> > Incoming message (either from SS7, with MTP routing label and SCCP
> > parameters, or from IP, with SCTP header and SUA parameters)
> 
> You may also want to include the IP address parameters, or?
> 
> > 
> > ==> pass to SRF for analysis and determine :
> > 	- whether the message must be passed to a local user
> > 	- whether the message must be "relayed on" to either an SS7
> > destination (IP -> SS7 at SG) or to an IP destination (SS7 -> 
> > IP at SG or
> > all-IP case)
> > 
> > Any information can be used/provisioned for this purpose. One 
> > may call it an
> > enhanced GTT, because it can be based on IP address, GT, host 
> > name, ...
> 
> IP address should be allowed as GT address info. Destination 
> IP address in
> the IP label is perhaps also useful in case the node has multiple IP
> addresses. 
> 
> > 
> > My comment on DPC+SSN only applied to "valid address 
> > information in the
> > incoming message". Just a point code won't do either as 
> > called (who's going
> > to handle it) as calling (backrouting ?) address. Of course, 
> > the SRF may or
> > may not take this SSN into account. E.g. the SG may forward 
> > every SS7 SCCP
> > message routed on DPC+SSN (and received from certain OPCs) to 
> > the ASPs of a
> > specified AS without further consideration to SSN.
> >
> > 
> > The IP address is strictly an SUA address parameter. For 
> > interworking with
> > SS7, one endpoint only has the DPC+SSN or GT options. You can 
> > of course put
> > an IP(v4) address in your GT, or convert a GT to an IPaddress 
> > (ENUM and DNS)
> > ...
> > 
> > 
> > Actually, what GTT or SRF should derive locally, is merely a 
> > "handle" to the
> > next hop, e.g.
> > - a route set number, by which MTP knows the routeset and 
> DPC to go to
> > - an SCTP association ID, by which SCTP knows the 
> > (multihomed) route and IP
> > address to go to
> > - of course, this "handle" could be the DPC and/or IP address 
> > itself, e.g.
> > if you use ENUM/DNS means to translate your E.164 stuff.
> > 
> > The SRF will avoid having to have a fully meshed SCTP (or transport)
> > network.
> > 
> > Greetings,
> > 
> > ____________________________
> > 
> > Gery Verwimp
> > > SIEMENS ATEA
> > > ICN D CS D5
> > > 
> > > Tel. : +32 14 25 3424
> > Fax : +32 14 25 3212
> > mailto:[email-masked]
> > ____________________________________
> > 
> 
> 
> ---
> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Vinay Kashyap <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUA5: Address Mapping text
Date: Tue, 5 Jun 2001 14:09:14 +0530
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MIMETrack: Itemize by SMTP Server on Mailserver/ConvergSoft(Release 5.07a 
             |May 14, 2001) at 06/05/2001 02:08:20 PM, Serialize by Router
on 
             Mailserver/ConvergSoft(Release 5.07a |May 14, 2001) at
06/05/2001 
             02:35:53 PM, Serialize complete at 06/05/2001 02:35:53 PM
X-SMTP-HELO: mailserver.convergsoft.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [203.197.163.36]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi ,
       I wanted info.. regarding Testing M3UA & SCTP layers . Is there any
simulation tool available in the net to download? what are the methods for
testing these layers?

Regards
vinay
----- Original Message -----
From: <[email-masked]>
To: sigtran <[email-masked]> Sent: Tuesday, June 05, 2001
1:14 PM
Subject: RE: SUA5: Address Mapping text

> Hi Klaus,
>
> > trying to catch up.
>
> Me too!
>
> > the text talks about Routing Keys, not address information in
> > the message. Why is it not allowed to have a DPC as routing key w
> > /o an SSN, thus specifying that all SSNs for that DPC are served by
> > the RK?
>
> The text is due for an update.
>
> > Also, where is the IP address coming from? Not from the SS7 network.
> > If it comes from an ASP, then we have an IP-Relay node, which I like.
> > Or does it also come from the local GTT?
>
> We are in the process of refining text for an AMF (addressing mapping
> function).  The AMF maps from the SS7 address to the SCTP association.
> If no SCTP association exists, then one will have to be initialized.
>
> The AMF will need to use the routing keys as help for determining
> the best SCTP association to use.
>
> best regards,
> John
>
>
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Tue, 5 Jun 2001 11:02:41 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades6.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mailhost2.atea.be [194.78.143.126]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi John,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] Sent: dinsdag
5 juni 2001 9:51
To: sigtran
Subject: RE: SUA5: Address Mapping text

Hi Gery,

> Yes, with this concept of "AMF" (address mapping function ... 
> why not "SRF" SUA relay function ...) 

AMF is best, because we will need the address mapping to an SCTP
association, even if the signaling is end-to-end.  In fact, one could
characterize the relay as a sort of proxy.
The originating end need not care if the relay or a 2nd endoing is actually
recieving the messages.

[GV] : Hmm. Proxy implies "single point of failure" somehow ... a relay node
typically is not.

> SUA could really do without the routing key things.
> What I have in mind is following black box, either at a SG or 
> an ASP or an SUA relay node in general :
> 
> Incoming message (either from SS7, with MTP routing label and SCCP
> parameters, or from IP, with SCTP header and SUA parameters)
> 
> ==> pass to SRF for analysis and determine :
> 	- whether the message must be passed to a local user
> 	- whether the message must be "relayed on" to either an SS7
> destination (IP -> SS7 at SG) or to an IP destination (SS7 -> 
> IP at SG or all-IP case)
> 
> Any information can be used/provisioned for this purpose. One 
> may call it an enhanced GTT, because it can be based on IP address, 
> GT, host name, ...

I think that this is not sufficient, as the routing keys are needed in order
to provide the glue between the ASPs and the SS7 node they represent
(allowing for loadsharing configurations as well).

[GV] : Yes, ok, the AMF database consists of Routing Keys; just as the GT
database consists of GT rules. My point is you don't need to exchange these
between SUA peers. I'd rather see this concept turn up in a MIB, where
Routing Keys are used for provisioning. You also don't do dynamic GT
management ...

> My comment on DPC+SSN only applied to "valid address 
> information in the incoming message". Just a point code won't 
> do either as called (who's going to handle it) as calling 
> (backrouting ?) address. Of course, the SRF may or
> may not take this SSN into account. E.g. the SG may forward 
> every SS7 SCCP message routed on DPC+SSN (and received from certain 
> OPCs) to the ASPs of a specified AS without further consideration 
> to SSN.

I still have to take a look at support for DPC, I think it can be supported
with some restrictions.

> The IP address is strictly an SUA address parameter. For 
> interworking with SS7, one endpoint only has the DPC+SSN or 
> GT options. You can of course put an IP(v4) address in your GT, 
> or convert a GT to an IPaddress (ENUM and DNS) ...

Agreed.

> Actually, what GTT or SRF should derive locally, is merely a 
> "handle" to the next hop, e.g.
> - a route set number, by which MTP knows the routeset and DPC to go to
> - an SCTP association ID, by which SCTP knows the 
> (multihomed) route and IP address to go to
> - of course, this "handle" could be the DPC and/or IP address 
> itself, e.g. if you use ENUM/DNS means to translate your E.164 stuff.

Agreed.

> The SRF will avoid having to have a fully meshed SCTP (or transport)
> network.

Partially agreed.  I think in many configurations, a meshed SCTP network
will be needed between certain network nodes.  For example, if I have an IP
HLR, I may need need a fully meshed SCTP network between the ASPs in the IP
HLR and the SUA relay node ... but then other operators would see the relay
node, not the IP HLR directly.

[GV] : Connecting all ASPs comprising an IP HLR (for inter-ASP
communication) is something else. But you have a point in saying that if an
SG has an end-to-end connection with the IP HLR, there has to be an SCTP
association between the SG and all these ASPs !

br,
Gery

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: test program for m3ua & SCTP was: SUA5: Address Mapping text
Date: Tue, 5 Jun 2001 12:19:18 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x2.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x2.nokia.com [131.228.20.22]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

>        I wanted info.. regarding Testing M3UA & SCTP layers . 
> Is there any simulation tool available in the net to download? 
>´what are the methods for testing these layers?

If you need a protocol analyzer, look here:

http://www.ethereal.com/

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Tue, 5 Jun 2001 13:08:05 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x2.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x2.nokia.com [131.228.20.22]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Gery,

> AMF is best, because we will need the address mapping to an
> SCTP association, even if the signaling is end-to-end.  In 
> fact, one could characterize the relay as a sort of proxy.
> The originating end need not care if the relay or a 2nd 
> endoing is actually recieving the messages.
> 
> [GV] : Hmm. Proxy implies "single point of failure" somehow 
> ... a relay node typically is not.

Can you expand on this?  How is the relay not a single point of failure?

> [GV] : Yes, ok, the AMF database consists of Routing Keys; 
> just as the GT database consists of GT rules. My point is you 
> don't need to exchange these between SUA peers. I'd rather see 
> this concept turn up in a MIB, where Routing Keys are used for 
> provisioning. You also don't do dynamic GT management ...

So, what you are saying is that we don't need a dynamic registration
process, the AMF and/or MIB will handle that.
Am I right?

> Partially agreed.  I think in many configurations, a meshed SCTP
> network will be needed between certain network nodes.  For
> example, if I have an IP HLR, I may need need a fully meshed
> SCTP network between the ASPs in the IP HLR and the SUA
> relay node ... but then other operators would see the relay
> node, not the IP HLR directly.
> 
> [GV] : Connecting all ASPs comprising an IP HLR (for inter-ASP
> communication) is something else. But you have a point in 
> saying that if an SG has an end-to-end connection with the IP HLR, 
> there has to be an SCTP association between the SG and all these ASPs !

I don't want the former (inter-asp communication, within an AS, is out of
scope) but did want to make sure we didn't forget the later (SG-ASP
connections).

br,
John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Tue, 5 Jun 2001 13:09:59 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x2.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x2.nokia.com [131.228.20.22]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Gery,

> SCON messages for congestion! 

Just some further clarification:

SCON is application level congestion (if one of the ASPs is experiencing
congestion) not IP layer congestion.

> BTW does SCTP inform it's upper layer of congestion (status information)?

As I understand, this would be (SCTP) implementation specific.

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Tue, 5 Jun 2001 13:13:07 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades6.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [194.78.143.126]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi John,

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] Sent: dinsdag
5 juni 2001 12:08
To: sigtran
Subject: RE: SUA5: Address Mapping text

Hi Gery,

> AMF is best, because we will need the address mapping to an
> SCTP association, even if the signaling is end-to-end.  In 
> fact, one could characterize the relay as a sort of proxy.
> The originating end need not care if the relay or a 2nd 
> endoing is actually recieving the messages.
> 
> [GV] : Hmm. Proxy implies "single point of failure" somehow 
> ... a relay node typically is not.

Can you expand on this?  How is the relay not a single point of failure?

[GV] : well, with AMF you'd have the choice between n active relay points
e.g. just as you could have n active endpoints ...

> [GV] : Yes, ok, the AMF database consists of Routing Keys; 
> just as the GT database consists of GT rules. My point is you 
> don't need to exchange these between SUA peers. I'd rather see 
> this concept turn up in a MIB, where Routing Keys are used for 
> provisioning. You also don't do dynamic GT management ...

So, what you are saying is that we don't need a dynamic registration
process, the AMF and/or MIB will handle that.
Am I right?

[GV] : Yes, I really think the UAs are not the place to specify which ASP
handles what traffic. M3UA is (getting) overloaded with this stuff. For SUA,
it would really be a nightmare ...

> Partially agreed.  I think in many configurations, a meshed SCTP
> network will be needed between certain network nodes.  For
> example, if I have an IP HLR, I may need need a fully meshed
> SCTP network between the ASPs in the IP HLR and the SUA
> relay node ... but then other operators would see the relay
> node, not the IP HLR directly.
> 
> [GV] : Connecting all ASPs comprising an IP HLR (for inter-ASP
> communication) is something else. But you have a point in 
> saying that if an SG has an end-to-end connection with the IP HLR, 
> there has to be an SCTP association between the SG and all these ASPs !

I don't want the former (inter-asp communication, within an AS, is out of
scope) but did want to make sure we didn't forget the later (SG-ASP
connections).

br,
John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: SUA: Address Mapping Function & Relay Node text
Date: Tue, 5 Jun 2001 15:39:14 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x3.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x3.nokia.com [131.228.20.26]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi all,

I'm trying to put to bed SUA v6.  There has been some discussion on SUA's
Address Mapping Function, Relay Function, and registration.

Please look this text over (if you care) and comment.  I hope to get this
cleared-up ASAP!

thanks,
John

1.4.6 Relay function

For network scalability purposes, the SUA may be enhanced with a relay
functionality to determine the next hop SCTP association towards the
destination SUA endpoint.

The determination of the next hop may be based on Global Title information
(e.g. E.164 number), in analogy with SCCP GTT in SS7 networks, modelled in
[ITU-T Q.714]. It may also be based on Hostname information.

This allows for greater scalability, reliability and flexibility in
wide-scale deployments of SUA.  The usage of a relay function is a
deployment decision.

1.5 Internal Functions Provided in the SUA Layer 

In order to perform its addressing and relaying capabilities, the SUA makes
use of a Address Mapping Function (AMF). This function is considered part of
SUA, but the way it is realized is left implementation / deployment
dependent (local tables, DNS (ENUM), LDAP, etc.)

The AMF is invoked when a message is received at the incoming interface. The
AMF is responsible for resolving the address presented in the incoming
SCCP/SUA message to SCTP associations to destinations within the IP network.
The AMF will select the appropriate SCTP association based upon routing key
information available. The destination might be the end SUA node or a SUA
relay node. The Routing Keys reference an Application Server, which will
have one or more ASPs processing traffic for the AS.  The availability and
status of the ASPs is handled by SUA ASP management messages.

Possible SS7 address/routing information that comprise a Routing Key entry
includes, for example, OPC, DPC, SIO found in the MTP3 routing label, or
other specific fields such as the SCCP subsystem number.

It is expected that the routing keys are provisioned via a MIB or external
process, such as a database.  

1.5.1 Address Mapping at the SG

Normally, one or more ASPs are active in the AS (i.e., currently processing
traffic) but in certain failure and transition cases it is possible that
there may not be an active ASP available. The SG will buffer the message
destined for this AS for a time t(r) or until an ASP becomes available. When
no ASP becomes available before expiry of t(r), the SG will flush the
buffered messages and initiate the appropriate return or refusal procedures.

If there is no Routing Key match for an incoming message, a default
treatment MUST be specified.  Possible solutions are to provide a default
Application Server to direct all unallocated traffic to a (set of) default
ASP(s), or to drop the messages and provide a notification to management.
The treatment of unallocated traffic is implementation dependent.

1.5.2 Address Mapping at the ASP

In order to direct messages to the SS7 network, the ASP must also perform an
address mapping in order to choose the proper SG for a given message.  This
is accomplished by observing the Destination Point Code and other elements
of the outgoing message, SS7 network status, SG availability, and network
appearance configuration tables.

A remote Signaling Gateway may be composed of one or more SGPs. There is,
however, no SUA messaging to manage the status of an SGP. Whenever an SCTP
association to an SGP exists, it is assumed to be available.  Also, every
SGP of one SG communicating with one ASP regarding one AS provides identical
SS7 connectivity to this ASP.

1.5.3 Address Mapping Function at a Relay Node

The relay function is invoked when :

- routing is on Global Title,
- routing is on Hostname.

Translation/resolution of the above address information must yield either of
the following :

- Route on SSN : SCTP association ID towards the destination node + SSN +
Network Appearance (optional)
- Route on GT : SCTP association ID towards next relay node + (new) GT + SSN
(optional) + Network Appearance (optional) - Routing on Hostname : SCTP
association ID towards next relay node + (new) Hostname + SSN (optional) +
Network Appearance (optional) - A local SUA-user (combined relay/end node)

To prevent looping, a hop counter is used. The originating end node (be it
an SS7 or an IP node) sets the value of the hop counter to the maximum value
(15 or less). Each time the relay function is invoked within an intermediate
(relay) node, the hop counter must be decremented. When the value reaches
zero, and the translation result is still "Route on GT" or "Route on
Hostname", the return or refusal procedures are invoked with reason "Hop
counter violation".

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Tue, 5 Jun 2001 16:09:24 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x2.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x2.nokia.com [131.228.20.22]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Gery,

> > [GV] : Hmm. Proxy implies "single point of failure" somehow 
> > ... a relay node typically is not.
> 
> Can you expand on this?  How is the relay not a single point
> of failure?
> 
> [GV] : well, with AMF you'd have the choice between n active 
> relay points e.g. just as you could have n active endpoints ...

I think we are bogged down on terminology, as you could have n relays,
proxies ....

> [GV] : Yes, I really think the UAs are not the place to 
> specify which ASP handles what traffic. M3UA is (getting) 
> overloaded with this stuff. For SUA, it would really be a nightmare ...

Exactly.  Anyone pinning their hopes on routing key provisioning in SUA?

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 5 Jun 2001 08:40:44 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: M3UA: Changeover between ASPs
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], sigtran 
                  <[email-masked]>
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      IAA31420
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-207.dallas.net [209.44.42.207]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hanns Juergen,

On Tue, 05 Jun 2001, Schwarzbauer, Hanns Juergen wrote:

> The question what happens, if a message (indicating that an other
> message has been successfully processed) has been queued in the
> ASP for sending and the association breaks before sending this
> message is still open.

It is the responsibility of the ASP to communicate with its other ASPs using
an unspecified implementation dependent ASP to ASP protocol concerning the
state of the ASP's internal processing of received MSUs.

Correlation Id in this case is just used as an identifier to indicate
*which* MSU we are talking about.

--Brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 5 Jun 2001 08:48:03 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: M2UA: SCTP lifetime
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], sigtran 
                  <[email-masked]>
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-207.dallas.net [209.44.42.207]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Jacob,

Congestion discard does not mean that the MSU is discarded from the system.
It means that there is no room in the receivers RB.  It is like sending
arwnd of 0 and then no longer acking TSNs.  Messages are held in the
sender's retransmit buffer and are not discarded from the system.
Discarding messages from the system is unacceptable to the extents outlined
in Q.706.

On Mon, 04 Jun 2001, Jacob Heitz wrote:
> 
> After SIB ends, the receiver may send negative 
> acknowledgement. This will cause the sender to
> retransmit. It will cause delay. It is acceptable
> in Q.703. Q.703 SDLs even have a "Congestion discard"
> variable to discard received MSUs during the busy
> condition.
> 

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Tue, 05 Jun 2001 07:55:54 -0700
From: Jacob Heitz <[email-masked]>
Organization: Lucent Technologies, Internetworking Systems, Software 
              Engineering, Alameda
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 i86pc)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: SCTP lifetime
X-SMTP-HELO: drawbridge.ascend.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: drawbridge.ascend.com [198.4.92.1]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

I did not say MSUs will be discarded by the system.
I said MSUs will be discarded by the receiver and retransmitted by the
sender. They will be delayed by the system.

"Brian F. G. Bidulock" wrote:
> 
> Jacob,
> 
> Congestion discard does not mean that the MSU is
> discarded from the system.  It means that there is
> no room in the receivers RB.  It is like sending
> arwnd of 0 and then no longer acking TSNs.  Messages
> are held in the sender's retransmit buffer and
> are not discarded from the system.  Discarding
> messages from the system is unacceptable to the
> extents outlined in Q.706.
> 
> On Mon, 04 Jun 2001, Jacob Heitz wrote:
> >
> > After SIB ends, the receiver may send negative
> > acknowledgement. This will cause the sender to
> > retransmit. It will cause delay. It is acceptable
> > in Q.703. Q.703 SDLs even have a "Congestion discard"
> > variable to discard received MSUs during the busy
> > condition.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 5 Jun 2001 10:25:22 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: M2UA: SCTP lifetime
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], sigtran 
                  <[email-masked]>
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-207.dallas.net [209.44.42.207]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Jacob,

As long as they are not delayed more or more often than is required by
Q.706.

On Tue, 05 Jun 2001, Jacob Heitz wrote:

> I did not say MSUs will be discarded by the system.
> I said MSUs will be discarded by the receiver and
> retransmitted by the sender. They will be delayed
> by the system.
> 
> "Brian F. G. Bidulock" wrote:
> > 
> > Jacob,
> > 
> > Congestion discard does not mean that the MSU is
> > discarded from the system.  It means that there is
> > no room in the receivers RB.  It is like sending
> > arwnd of 0 and then no longer acking TSNs.  Messages
> > are held in the sender's retransmit buffer and
> > are not discarded from the system.  Discarding
> > messages from the system is unacceptable to the
> > extents outlined in Q.706.
> > 
> > On Mon, 04 Jun 2001, Jacob Heitz wrote:
> > >
> > > After SIB ends, the receiver may send negative
> > > acknowledgement. This will cause the sender to
> > > retransmit. It will cause delay. It is acceptable
> > > in Q.703. Q.703 SDLs even have a "Congestion discard"
> > > variable to discard received MSUs during the busy
> > > condition.
> 

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
X-Lotus-FromDomain: HTLUK
To: "sigtran" <[email-masked]>
Date: Tue, 5 Jun 2001 16:52:36 +0100
Subject: Re: M2UA: SCTP lifetime
X-SMTP-HELO: hagrid.orange.co.uk
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: smtpout10.orange.co.uk [193.35.135.133]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi,

Correct, but note if the messages are throttled at the transmit end for long
enough (T6 is 3-6 sec) due to SIBs then transmit congestion could very
likely result in the transmit/retransmit buffers.

Amish

Congestion discard does not mean that the MSU is discarded from the system.
It means that there is no room in the receivers RB.  It is like sending
arwnd of 0 and then no longer acking TSNs.  Messages are held in the
sender's retransmit buffer and are not discarded from the system.
Discarding messages from the system is unacceptable to the extents outlined
in Q.706.

On Mon, 04 Jun 2001, Jacob Heitz wrote:
>
> After SIB ends, the receiver may send negative
> acknowledgement. This will cause the sender to
> retransmit. It will cause delay. It is acceptable
> in Q.703. Q.703 SDLs even have a "Congestion discard"
> variable to discard received MSUs during the busy
> condition.
>

****************************************************************************
*** Important. This E-mail is intended for the above named person and may be
confidential and/or legally privileged. If this has come to you in error you
must take no action based on it, nor must you copy or show it to anyone;
please inform the sender immediately.
****************************************************************************
***

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 6 Jun 2001 8:35:1 +0500
From: "Srivats P." <[email-masked]>
Reply-To: [email-masked]
To: "sigtran" <[email-masked]>
Subject: Re: Re: sg-sg communication
Organization: Mercury Corporation, India
X-mailer: FoxMail 2.1 [en]
X-SMTP-HELO: india.mercurykr.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [165.133.13.60]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Vipin,

The draft does not impose this limitation. In fact, the M2UA draft
recommends both client and server operation for SG and ASP.
As per draft-ietf-sigtran-m2ua-07.txt section 1.3.5

"1.3.5 Client/Server Model
It is recommended that the SG and ASP be able to support both client and
server operation. The peer endpoints using M2UA SHOULD be configured so that
one always takes on the role of client and the other the role of server for
initiating SCTP associations. The default orientation would be for the SG to
take on the role of server while the ASP is the client. In this case, ASPs
SHOULD initiate the SCTP association to the SG."

Srivats

At 6/5/01 6:14:00 AM, you wrote:
>Hi Srikanth
>
>When we talk about M2PA then an SG can either be a
>client or a server. You can configure one of them 
>as a client and one of them as a server depending 
>on your implementation.
>For other UAs like IUA, M2UA or M3UA SG can only
>be a server which accepts connection requests from
>ASPs.
>
>Vipin
>
>
>--- srikanth <[email-masked]> wrote:
>> 
>> 
>> 
>> 
>> Hi,
>> 
>>     How can we make  a SG both a Client and Server
>> using local management
>> and GUI.Can you suggest please.
>> 
>> Thanks
>> srikanth
>> 
>> 
>> 
>> 
>> 
>> ---
>> You are currently subscribed to sigtran as:
>> [email-masked]
>> To unsubscribe send a blank email to
>> [email-masked]
>> 
>> 
>
>
>__________________________________________________
>Do You Yahoo!?
>Get personalized email addresses from Yahoo! Mail - only $35 
>a year!  http://personal.mail.yahoo.com/
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 6 Jun 2001 03:22:01 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA Implementation
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.207]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Satish,

Yes, it appears to be implementation dependent.

On Thu, 31 May 2001, Satish K wrote:

> Folks,
>    M3UA draft does not say what is Max No of SGPs on SG and ASPs on AS.
>    Is it Implementation dependent.
> Thanks
> Satish 

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 6 Jun 2001 03:33:33 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: M3UA not clear in IETF Doc
Reply-To: [email-masked]
Mail-Followup-To: Satish K <[email-masked]>, 
                  [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      DAA13940
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.207]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Satish,

Perhaps the following diagram might help:

              +------------+
              |            |
              |  MTP-User  |
              |            |
              +------------+
                  ^    |
 MTP-TRANSFER-IND |    | MTP-TRANSFER-REQ
                  |    |
                  |    |
                  |    v
              +------------+
              |            |
              |  M3UA-ASP  |
              |            |
              +------------+
                  ^    |
                  |    |
             DATA |    | DATA
                  |    |
                  |    v
              +------------+
              |    SCTP    |
              +------------+
                  |
                  |
                  |  /|
                  | / |  Network
                  |/  |
                      |
                      |
              +------------+
              |    SCTP    |
              +------------+
                  ^    |
                  |    |
             DATA |    | DATA
                  |    |
                  |    v
              +------------+
              |            |
              |  M3UA-SGP  |
              |            |
              +------------+
                  ^    |
                  |    |
                  |    |
 MTP-TRANSFER-IND |    | MTP-TRANSFER-REQ
                  |    v
              +------------+
              |            |
              |    MTP     |
              |            |
              |            |
              +------------+

Normally the MTP-User is directly attached to the MTP and MSUs are
transferred between the two using MTP-TRANSFER request (MTP-User to MTP) and
MTP-TRANSFER indication (MTP to MTP-User).  M3UA extends this interface over
an SCTP association and uses DATA messages in either direction to implement
the MTP-TRANSFER primitives.

--Brian

On Thu, 31 May 2001, Satish K wrote:

> Hi All,
>    It is not clear for us the functionalties of M3UA at SG and ASP with
> respect to
>    handling Primitives like MTP-Transfer Request and MTP-Transfer
> Indication.
> 
> in the IETF Draft M3UA-06.txt
> 
>   In section 4.1.1 it says
>        "On receiving an MTP-Transfer request primitive from an upper
layer,
> or
> 	the nodal inter-working function at an SG, the M3UA layer sends a
> 	corresponding DATA message (see Section 3) to its M3UA peer.  The
M3UA
> 	peer receiving the Data message sends an MTP-Transfer indication."
> 
>    In section 5.3.2.1 it says
>    "5.3.2.1 Support for MTP-Transfer Request at the SG
>       When the M3UA on the SG has received Data messages from its peer
> 	destined to the SS7 network it will do the following:
> 	  - Evaluate the optional fields of the Data message if present to
> 	    determine the network appearance
> 	  - Map the Protocol data of the Data message into an MTP-Transfer
> 	    Request primitive
> 	  - Pass the MTP-Transfer Request primitive to the MTP3 of the
> 	    concerned network appearance."
>                             SG                        ASP
>                              |                         |
>         <---MTP-Transfer req.|<------Data Message------|
>                              |                         |
> 
>    In section 5.3.2.1 it says
> 	"5.3.2.2 Support for MTP-Transfer Indication at the SG
> 		When the MTP3 on the SG has data to pass its user parts, it
will use
> 		the MTP-Transfer Indication primitive.  The M3UA on the SG
will do the
> 		following when it receives an MTP-Transfer Indication:
> 		  - Determine the correct ASP
> 		  - Determine the correct association to the chosen ASP
> 		  - Determine the correct stream in the association (e.g.,
based on SLS)
> 		  - Determine whether to complete the optional fields of the
Data message
> 		  - Map the MTP-Transfer Indication primitive into the
Protocol Data field
> of an M3UA 		    Data message
> 		  - Send the Data message to the remote M3UA peer in the
ASP, over the
> SCTP 				    association"
>                            SG                        ASP
>                             |                         |
>        --MTP-Transfer ind.->|------Data Message------>|
>                             |                         |
> 
> Its not clear for us is MTP-Transfer req used for M3UA sending peer to
peer
> or sending it to the ULP. can any one help us in this regard.
> 
> Thanks
> Satish K
> 

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Gopalaswamy, Sridhar" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2PA
Date: Wed, 6 Jun 2001 18:18:45 +0200
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: ztxmail05.ztx.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [161.114.1.209]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi,
	
	Had a couple of questions on M2PA

	1. Message length in Common Header  ( common to all UAs )
	Section 2.1.3 of draft-ietf-sigtran-m2pa-02.txt ( is this the latest
or have later revisions been issued ?).
		
			The message length defines the length of the message
in octets, not including the header.

	while that of M2UA states ( Section 3.1.4 of revision 07 of m2ua )

			The Message Length defines the length of the message
in octets, including the header. The Message....

	Now , when one defines common header across all UAs , does this mean
just that all UA pkts will contain a common header or also 
	that their formats will be consistent across the UAs ? ( or is this
a typo - if so which one is correct ? )

	2. Section 4.1.2 proposes modelling a link to an association (with
stream 0 used to carry LSSU and stream 1 data). Has the other alternative of
modelling links to streams within a single association been considered ?  I
went through the archives but I havent seen any thread that discusses this.
In the second alternative , we could still use stream 0 for LSSU , but the
data format of the LSSU now includes informatio on which stream or link it
is referring to. Does anyone have information on the cost ( performance and
otherwise) of this choice ( having more streams within an association vs
having more associations ) in general within SCTP ? 

Thanks 
Rgds
g sridhar

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Gradischnig, Klaus" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Wed, 6 Jun 2001 14:18:30 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: dnspri.npac.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: dnspri.npac.com [208.143.33.66]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi John:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: June 05, 2001 3:56 AM
> To: sigtran
> Subject: RE: SUA5: Address Mapping text
> 
> 
> Hi Klaus,
> 
> > Now, what kind of address would be contained in the DUNA/DAVA 
> > messages? An IP address? And would this be useful unless relay on 
> > IP adddress is possible? 
> 
> The relay node would be for the IP case.  The DUNA, DAVA should 
> just be used in the SG to ASP case.  I'm not envisioning anything
> more (right now).
> 

I think Gery's proposal has merit and DUNA/DAVA should be useable in an
all-IP scenario.

> > Or do we want to replay the discussion of GT management?
> 
> No we don't.

Good, though it was interesting.

>  
> > And, what about congestion?
> 
> Can you detail a little more about what you see as a problem?

I am not sure there is a problem, that's why I am asking. In an all IP case
with relays, is SCON or something equivalent useful/needed?

> John

Cheers, Klaus

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 6 Jun 2001 14:49:54 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2PA
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      OAA25431
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-207.dallas.net [209.44.42.207]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Gopalaswamy,

See the thread "M2PA: Multiple Streams"...

Also, LSSU cannot be placed on a separate stream because they must by
synchronized with MSUs to determine which MSUs they apply to.

--Brian

On Wed, 06 Jun 2001, Gopalaswamy, Sridhar wrote:

(snip)
> 
> 	2. Section 4.1.2 proposes modelling a link to an association (with
> stream 0 used to carry LSSU and stream 1 data). Has the other alternative
of
> modelling links to streams within a single association been considered ?
I
> went through the archives but I havent seen any thread that discusses
this.
> In the second alternative , we could still use stream 0 for LSSU , but the
> data format of the LSSU now includes informatio on which stream or link it
> is referring to. Does anyone have information on the cost ( performance
and
> otherwise) of this choice ( having more streams within an association vs
> having more associations ) in general within SCTP ? 
> 

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Satish K <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: IDD Review change in time
Date: Thu, 7 Jun 2001 09:34:38 +0530
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-SMTP-HELO: mail.convergsoft.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [203.197.163.45]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi all,
   Review of M3UA is done at 4:00Pm.
Thanks
Satish

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Gopalaswamy, Sridhar" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M2PA
Date: Thu, 7 Jun 2001 09:22:08 +0200
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: zcamail03.zca.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [161.114.32.103]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

	You mean seperate 'association' not stream because with the current
spec they are placed on a seperate stream ??
g s

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Wednesday,
June 06, 2001 9:50 PM
To: sigtran
Subject: Re: M2PA

Gopalaswamy,

See the thread "M2PA: Multiple Streams"...

Also, LSSU cannot be placed on a separate stream because they must by
synchronized with MSUs to determine which MSUs they apply to.

--Brian

On Wed, 06 Jun 2001, Gopalaswamy, Sridhar wrote:

(snip)
> 
> 	2. Section 4.1.2 proposes modelling a link to an association (with
> stream 0 used to carry LSSU and stream 1 data). Has the other alternative
of
> modelling links to streams within a single association been considered ?
I
> went through the archives but I havent seen any thread that discusses
this.
> In the second alternative , we could still use stream 0 for LSSU , but the
> data format of the LSSU now includes informatio on which stream or link it
> is referring to. Does anyone have information on the cost ( performance
and
> otherwise) of this choice ( having more streams within an association vs
> having more associations ) in general within SCTP ? 
> 

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 7 Jun 2001 03:10:11 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: M2PA
Reply-To: [email-masked]
Mail-Followup-To: "Gopalaswamy, Sridhar" <[email-masked]>, 
                  [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      DAA05060
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-197.dallas.net [209.44.41.197]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Gopalaswamy,

No, I actually meant separate 'streams'.  The current spec has a problem
which is detailed in the other thread.

Processor Outage: (PROCESSOR_OUTAGE PROCESSOR_OUTAGE_ENDED)

Consider what an SS7 link does.  When one end discovers processor outage and
sends SIPO it also stops acknowledging MSUs and discards MSUs which were
received after it discovered processor outage.  This is so that the sending
end does not strike from its retransmit buffer messages which were not
acknolwedged by SIPO sending end and these messages remain available for
retrieval and retransmission on an alternative link.

Now, in M2PA, how does the sender know when to strike a message from its
(i.e, SCTP's) retransmission buffer?  Receiving Processor Outage on another
stream (or any stream for that matter) serves no purpose.  SCTP continues
sending until its transmission and retransmission buffers are empty.  These
messages are no longer available to the sending side for retransmission on
an alternative link, so if the processor outage is of long term, they will
be ultimately discarded undermining MTP3's reliability requirements.

Receive Congestion: (BUSY BUSY_ENDED)

Consider what an SS7 link does.  When one end discovers receive congestion
it SIBs and continues accepting MSUs and may acknowledge them until it hits
dicard level of receive congestion.  Once it hits discard level of receive
congestion it begins discarding MSUs and witholding acknoledgements while
continuing to SIB.  Again, the sender does not strike these messages from
it's retransmission buffer and if T6 expires they remain available to
retransmission on an alternative link.

Now, in M2PA, how does the sender know when to strike a message from its
retransmission buffer?  Receiving Busy on any stream tells it nothing.  SCTP
continues sending and the receiver continues accepting and acknolwedging.
These messages are no longer available and if T6 should expire, they are
lost to the system, again undermining MTP3's reliablity requirements.

In Service: (IN_SERVICE)

Because no data messages are sent on a stream before the IN_SERVICE state,
the first data message itself would be sufficient to indicate the in service
state.

So, existing LSSU equivalents are quite useless.

If you consider that the way to `fix' the M2PA spec is to place forward and
backward sequence number back into the message stream so that each MSUs can
be separately acknowledged by ULP independent of SCTP and an RTB maintained
by M2PA for retrieval, then it is necessary to synchronize SIBs and SIPOs
with the MSUs so that the SIBs and SIPOs carry the backwards sequence number
of the MSU to which they apply.  Otherwise, how would the sender know which
sent MSU to apply the T6 timer to?  Which message would the sender know the
MSU it sent to which SIPO applies?  If one is putting the SN's back into the
message and one needs the LI for TTC, why not just place the entire L2
message in the stream?  MSUs and LSSUs together?

I haven't seen any of these issues addressed except in the proposals which I
put forth on other M2PA threads.

--Brian

On Thu, 07 Jun 2001, Gopalaswamy, Sridhar wrote:
>
> Brian,
> 
> You mean seperate 'association' not stream because with the current
> spec they are placed on a seperate stream ??
>
> g s
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, June 06, 2001 9:50 PM
> To: sigtran
> Subject: Re: M2PA
> 
> 
> Gopalaswamy,
> 
> See the thread "M2PA: Multiple Streams"...
> 
> Also, LSSU cannot be placed on a separate stream because
> they must by synchronized with MSUs to determine which
> MSUs they apply to.
> 
> --Brian
> 

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Thu, 7 Jun 2001 14:14:52 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x1.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x1.nokia.com [131.228.20.21]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Klaus,

> > The relay node would be for the IP case.  The DUNA, DAVA should 
> > just be used in the SG to ASP case.  I'm not envisioning anything
> > more (right now).
> 
> I think Gery's proposal has merit and DUNA/DAVA should be 
> useable in an all-IP scenario.

I'm working that in, I think it is do-able.

> > Can you detail a little more about what you see as a problem?
> 
> I am not sure there is a problem, that's why I am asking. In 
> an all IP case with relays, is SCON or something equivalent 
> useful/needed?

Well, I am sure that someone will say it is a problem, so let me see if I
can work that in too.

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Thu, 7 Jun 2001 14:16:38 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x3.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x3.nokia.com [131.228.20.26]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Klaus,

> > I'm  hoping that we don't handle SCCP-layer congestion here.
> > Failover we should verify that it can be handled.  It can
> > be handled (I think) if we are not using a relay, however,
> > when using a relay, it may be problematic.  I don't want
> > to go down the 'let's (re)build the SS7 network over IP'
> 
> I'd hope we would make it better. SCCP (management) is 
> notoriously weak when you cross network boundaries, like you 
> don't even know who originated an (X/L)UDTS. It still amazes 
> me that it (seemingly) works so well for something it was never 
> really designed for. 

This is one of the reasons I don't want to re-invent the SS7 Network using
IP ;P

> If SUA is not at least as good as SCCP or better it might loose 
> out to TI-SCCP ;-)

The plan is to make it better!

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: Address Mapping Function & Relay Node text
Date: Thu, 7 Jun 2001 14:24:28 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x3.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x3.nokia.com [131.228.20.26]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Klaus,

> Replace previous sentence by:
> 
> It may also be based on Hostname information, IP address, or pointcode
> contained in the called party address.

Sounds good.

> Question: If the next node is a relay node, is the RK still 
> identifying an AS? Or would it be a set of ASs?

In my opinion, the routing keys refer to the neighbor, i.e. - the AS of the
relay node.

> Add: IP addresses and host names can also be used as Routing Key
> information.

Got it.

> > - routing is on Global Title,
> > - routing is on Hostname.
> 
> Add:
> 
>   - routing is on SSN + PC or SSN + IP Address and the PC/IP 
>     Address is not the one of the relay node

Got it.

Thanks,
John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Cc: [email-masked], [email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 07 Jun 2001 09:45:06 -0500
To: "sigtran" <[email-masked]>
From: Al Varney <[email-masked]>
Subject: Re: M2PA
Original-Cc: "sigtran" <[email-masked]>, 
             [email-masked]
X-SMTP-HELO: ihemail2.firewall.lucent.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ihemail2.lucent.com [192.11.222.163]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<html>
At 03:10 06/07/2001 -0500, Brian F. G. Bidulock wrote:<br> <br>
<blockquote type=cite cite>No, I actually meant separate 'streams'.&nbsp;
The current spec has a<br>
problem which is detailed in the other thread.</blockquote><br> &nbsp;&nbsp;
Personally, I agree with most of Brian's comments.<br> <br>
<blockquote type=cite cite>Receive Congestion: (BUSY BUSY_ENDED)<br> <br>
Consider what an SS7 link does.&nbsp; When one end discovers receive<br>
congestion it SIBs and continues accepting MSUs and may<br> acknowledge them
until it hits dicard level of receive<br> congestion.&nbsp; Once it hits
discard level of receive congestion it<br>
begins discarding MSUs and witholding acknoledgements while<br> continuing
to SIB. </blockquote><br>
&nbsp;&nbsp; Minor nit:<br>
<br>
&nbsp;&nbsp; I question the &quot;and may acknowledge them until ...&quot;
phrase.&nbsp; I thought the desired hysteresis for Layer 2 Flow Control
(quote from T1.111.3)<br>
<br>
<font face="Times New Roman, Times" size=2>NOTE: Congestion onset and
abatement detection is an implementation dependent function. Sufficient
hysteresis should be<br>
provided in the implementation to prevent excessive oscillation between
congested and noncongested states.<br>
<br>
</font>would suggest that, once you have sent SIB, all ACKs (and NACKs)
should stop until congestion ends.&nbsp; So, withholding of acknowledgements
should begin at the beginning of congestion detection, when you start
sending SIB, not at the &quot;discard level&quot; of receive congestion.<br>
<br>
&nbsp;&nbsp; Sending a SIB followed by ACK(s) effectively tells the other
end that receive congestion has ended.&nbsp; Not that I haven't seen
implementations do so.&nbsp; The worst send SIB when the receive buffer is
empty, making it difficult to stop T7....<br> <br>
<br>
Al Varney - Lucent Technologies&nbsp; +1 630 224-7493&nbsp;&nbsp;&nbsp;
[email-masked]

---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </html>

</x-html>
Date: Thu, 7 Jun 2001 11:16:39 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: M2PA
Reply-To: [email-masked]
Mail-Followup-To: Al Varney <[email-masked]>, 
                  [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      LAA12521
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-244.dallas.net [209.44.42.244]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Al,

You are correct, as always.  In what I was describing, however, it makes
matters worse.  Acknowledgments are withheld from the start of SIB but MSUs
are still accepted for acknowledgment should receive congestion abate at a
later point.  Once the discard level is reached, MSUs are discarded as well
as acknowledgements withheld.

Should the link fail due to T6, both the accepted MSUs (which exist in both
the RB of the receiver and the RTB of the sender) and the discarded MSUs
(which exist only in the RTB of the sender) will be sent on an alternative
signalling link.

This is definitely not the case with M2PA which continues to transfer
messages in SCTP's TB/RTB to the receiver and strikes them from subsequent
retrieval, given that there is receive congestion (potentially between MTP2
and 3 at the receiver) this can be a large number of MSUs if the SCTP TB is
deep.

--Brian

Al Varney wrote:                               (Thu, 07 Jun 2001 09:45:06)
> 
>    At 03:10 06/07/2001 -0500, Brian F. G. Bidulock wrote:
>    
>      No, I actually meant separate 'streams'.  The current spec has a
>      problem which is detailed in the other thread.
>      
>       Personally, I agree with most of Brian's comments.
>    
>      Receive Congestion: (BUSY BUSY_ENDED)
>      Consider what an SS7 link does.  When one end discovers receive
>      congestion it SIBs and continues accepting MSUs and may
>      acknowledge them until it hits dicard level of receive
>      congestion.  Once it hits discard level of receive congestion it
>      begins discarding MSUs and witholding acknoledgements while
>      continuing to SIB.
>      
>       Minor nit:
>       I question the "and may acknowledge them until ..." phrase.  I
>    thought the desired hysteresis for Layer 2 Flow Control (quote from
>    T1.111.3)
>    NOTE: Congestion onset and abatement detection is an implementation
>    dependent function. Sufficient hysteresis should be
>    provided in the implementation to prevent excessive oscillation
>    between congested and noncongested states.
>    would suggest that, once you have sent SIB, all ACKs (and NACKs)
>    should stop until congestion ends.  So, withholding of
>    acknowledgements should begin at the beginning of congestion
>    detection, when you start sending SIB, not at the "discard level" of
>    receive congestion.
>       Sending a SIB followed by ACK(s) effectively tells the other end
>    that receive congestion has ended.  Not that I haven't seen
>    implementations do so.  The worst send SIB when the receive buffer is
>    empty, making it difficult to stop T7....
>    Al Varney - Lucent Technologies  +1 630 224-7493    [email-masked]
>    ---
>    You are currently subscribed to sigtran as: [email-masked]
>    To unsubscribe send a blank email to
>    [email-masked]

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Miriyala Srinivas-FSM016 <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Address Mapping Function & Relay Node text
Date: Thu, 7 Jun 2001 11:57:55 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: motgate.mot.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: motgate.mot.com [129.188.136.100]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hello John,

Along with the IP and Hostname as routing keys you may want to add GT also.
Since once could make the routinmg decisions at SRF (Relay Node) using GT
information.

Regards
Srini

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] Sent:
Thursday, June 07, 2001 6:24 AM
To: sigtran
Subject: RE: Address Mapping Function & Relay Node text

Hi Klaus,

> Replace previous sentence by:
> 
> It may also be based on Hostname information, IP address, or pointcode
> contained in the called party address.

Sounds good.

> Question: If the next node is a relay node, is the RK still 
> identifying an AS? Or would it be a set of ASs?

In my opinion, the routing keys refer to the neighbor, i.e. - the AS of the
relay node.

> Add: IP addresses and host names can also be used as Routing Key
> information.

Got it.

> > - routing is on Global Title,
> > - routing is on Hostname.
> 
> Add:
> 
>   - routing is on SSN + PC or SSN + IP Address and the PC/IP 
>     Address is not the one of the relay node

Got it.

Thanks,
John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Long, Hanping" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M2UA draft 7 questions (SCTP congestion at ASP)
Date: Thu, 7 Jun 2001 17:45:51 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: ganymede.or.intel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: jffdns01.or.intel.com [134.134.248.3]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi All:

I can understand Brian's point. But since MTP3/MTP2 have been existing for a
long time, LPO is received at MTP2, and is not supposed to be received at
MTP3 from MTP2. I think the best way will be resolving this problem without
modification at the current MTP3/MTP2 interface.  

To handle the SCTP congestion at ASP, we would like to propose a solution in
which a Congestion Indication (with maximum congestion level, LEVEL_3) is
sent from M2UA to MTP3 at ASP wheneven M2UA receives the SCTP congestion,
which will stop the data transmission at MTP3 but ASP can still recieve data
from SG. After the SCTP congestion is abated, M2UA at ASP will send another
Congestion Indication to recover the original SS7 link congestion level.

regards,
Hanping

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Wednesday,
May 23, 2001 3:25 AM
To: sigtran
Cc: [email-masked] Subject: Re: M2UA draft 7
questions

On Tue, 22 May 2001, Tom George wrote:
> 
> If I read section 1.5.5 (last paragraph) correctly, it has M2UA
> reporting Local Processor Outage to its _upper layer_, MTP3. This does
> not sound like a good idea. LPO is supposed to mean that that there is a
> problem at a level higher than level 2. In Q.703, the LPO primitive goes
> from Level 3 to Level 2.
> 
> Did you maybe mean Remote Proc Outage in that last paragraph?
> 

In Q.703, LPO is diagrammed as coming from an implementation specific
function and going to L2.  Although Q.704 talks about local blocking (LPO),
it does not diagram this in the SDLs as such except on Figure 37/Q.704
(sheet 2 bis of 10).  Q.2210 does indicate LPO as going from MGMT to MTP L3
(TLAC) and also from MGMT to MTP L2.

MTP L3 needs to know if it is locally blocked on a link (LPO) for it to
peform its procedures correctly according to the text (which takes
precedence over the diagrams).

M2UA, sitting just beneath the MTP2-MTP3 interface, is aware of LPO
conditions which the MTP3 management may not be aware.
This primitive to L3 is really a notification to MGMT to send LPO (local
blocking) to L3 per the specs.

So, why does it not sound like a good idea?

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Thu, 07 Jun 2001 23:48:45 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA: SCTP lifetime
Cc: [email-masked]
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian, Jacob,

Sorry, I've been away from my email not that it mattered to much since this
text was added by Jacob.

Would it be sufficient to change the "SHALL" to a "MAY" for those that would
like to use a "lifetime"?

Ken

At 10:25 AM 6/5/01 -0500, Brian F. G. Bidulock wrote:
>Jacob,
>
>As long as they are not delayed more or
>more often than is required by Q.706.
>
>On Tue, 05 Jun 2001, Jacob Heitz wrote:
>
> > I did not say MSUs will be discarded by the system.
> > I said MSUs will be discarded by the receiver and
> > retransmitted by the sender. They will be delayed
> > by the system.
> > 
> > "Brian F. G. Bidulock" wrote:
> > > 
> > > Jacob,
> > > 
> > > Congestion discard does not mean that the MSU is
> > > discarded from the system.  It means that there is
> > > no room in the receivers RB.  It is like sending
> > > arwnd of 0 and then no longer acking TSNs.  Messages
> > > are held in the sender's retransmit buffer and
> > > are not discarded from the system.  Discarding
> > > messages from the system is unacceptable to the
> > > extents outlined in Q.706.
> > > 
> > > On Mon, 04 Jun 2001, Jacob Heitz wrote:
> > > >
> > > > After SIB ends, the receiver may send negative
> > > > acknowledgement. This will cause the sender to
> > > > retransmit. It will cause delay. It is acceptable
> > > > in Q.703. Q.703 SDLs even have a "Congestion discard"
> > > > variable to discard received MSUs during the busy
> > > > condition.
> > 
>
>-- 
>Brian F. G. Bidulock
>[email-masked]
>http://www.openss7.org/
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Fri, 08 Jun 2001 00:08:35 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: RE: M2UA draft 7 questions (SCTP congestion at ASP)
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hanping,

Your suggestion is pretty much what Jacob as already proposed (it was
discussed in this very thread - see previous emails).  I plan to change text
to Jacob's proposal.

Ken

At 05:45 PM 6/7/01 -0700, Long, Hanping wrote:
>Hi All:
>
>I can understand Brian's point. But since MTP3/MTP2 have been existing for
a
>long time, LPO is received at MTP2, and is not supposed to be received at
>MTP3 from MTP2. I think the best way will be resolving this problem without
>modification at the current MTP3/MTP2 interface.  
>
>To handle the SCTP congestion at ASP, we would like to propose a solution
in
>which a Congestion Indication (with maximum congestion level, LEVEL_3) is
>sent from M2UA to MTP3 at ASP wheneven M2UA receives the SCTP congestion,
>which will stop the data transmission at MTP3 but ASP can still recieve
data
>from SG. After the SCTP congestion is abated, M2UA at ASP will send another
>Congestion Indication to recover the original SS7 link congestion level.
>
>regards,
>Hanping
>
>
>-----Original Message-----
>From: Brian F. G. Bidulock [mailto:[email-masked]]
>Sent: Wednesday, May 23, 2001 3:25 AM
>To: sigtran
>Cc: [email-masked]
>Subject: Re: M2UA draft 7 questions
>
>
>On Tue, 22 May 2001, Tom George wrote:
> > 
> > If I read section 1.5.5 (last paragraph) correctly, it has M2UA
> > reporting Local Processor Outage to its _upper layer_, MTP3. This does
> > not sound like a good idea. LPO is supposed to mean that that there is a
> > problem at a level higher than level 2. In Q.703, the LPO primitive goes
> > from Level 3 to Level 2.
> > 
> > Did you maybe mean Remote Proc Outage in that last paragraph?
> > 
>
>In Q.703, LPO is diagrammed as coming from an implementation
>specific function and going to L2.  Although Q.704 talks about
>local blocking (LPO), it does not diagram this in the SDLs as
>such except on Figure 37/Q.704 (sheet 2 bis of 10).  Q.2210
>does indicate LPO as going from MGMT to MTP L3 (TLAC) and also
>from MGMT to MTP L2.
>
>MTP L3 needs to know if it is locally blocked on a link (LPO)
>for it to peform its procedures correctly according to the
>text (which takes precedence over the diagrams).
>
>M2UA, sitting just beneath the MTP2-MTP3 interface, is aware
>of LPO conditions which the MTP3 management may not be aware.
>This primitive to L3 is really a notification to MGMT to send
>LPO (local blocking) to L3 per the specs.
>
>So, why does it not sound like a good idea?
>
>-- 
>Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
>[email-masked]    ¦ world; the unreasonable one persists in  ¦
>http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
>[email-masked]
>
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 7 Jun 2001 23:10:04 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA draft 7 questions (SCTP congestion at ASP)
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      XAA24866
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-149.dallas.net [209.44.41.149]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hanping,

On Thu, 07 Jun 2001, Long, Hanping wrote:
>
> I can understand Brian's point. But since MTP3/MTP2 have been existing for
a
> long time, LPO is received at MTP2, and is not supposed to be received at
> MTP3 from MTP2. I think the best way will be resolving this problem
without
> modification at the current MTP3/MTP2 interface.  

Let me try this once again.  It appears that you believe that local
processor outage is not a signal given to MTP3.  This is an incorrect view.
I refer you to Table 13/Q.2210 which shows the signals between the MTP-3 and
a Management System.
I draw your attention to 2 defined signals:

  MMTP-LOCAL_PROCESSOR_OUTAGE_request     MS to MTP-3 (TLAC)
  MMTP-LOCAL_PROCESSOR_RECOVERED_request  MS to MTP-3 (TLAC)

This table even identifies the same MTP subsystem (TLAC) which is
responsible for local blocking on links.  Local blocking is a term which
includes processor outage.

There can be no disagreement with sending LPO signals to MTP on the basis of
looking at Q.703 diagrams.

I happen to be looking at the 1996 version of Q.2210, which has been around
for some time.  This is the standard and defined MTP3 interface and it is
completely appropriate and necessary to signal LPO and LPR to MTP-3 when
local processor outage is detected and recovers.  Nor does it conflict with
Q.704, which shows management blocking signals being applied to TLAC.

> 
> To handle the SCTP congestion at ASP, we would like to propose a solution
in
> which a Congestion Indication (with maximum congestion level, LEVEL_3) is
> sent from M2UA to MTP3 at ASP wheneven M2UA receives the SCTP congestion,
> which will stop the data transmission at MTP3 but ASP can still recieve
data
> from SG. After the SCTP congestion is abated, M2UA at ASP will send
another
> Congestion Indication to recover the original SS7 link congestion level.
> 

Although this might appear to be a solution when looking at a single link,
however, signalling level 3 congestion to MTP3 will have a serious and
negative impact on the status of the signalling link set, the signalling
route set, and any signalling points on routes which include the signalling
link.
Furthermore, this would be quite against MTP standards specifications which
strongly recommend that onset and abatement thresholds with sufficient
hysteresis be provided, particularly when multiple congestion levels with
congestion priorities is used.

--Brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: EXPLOSIVE STOCK ALERT at $0.07 !!
Date: Fri, 08 Jun 2001 10:13:26 -0400
X-SMTP-HELO: dns.nrjp.co.jp
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: dns.nrjp.co.jp [210.162.235.50]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

EXPLOSIVE STOCK ALERT  at $0.07 !!!!

EXPLOSIVE STOCK ALERT

INNOVATIVE HLDGS (OTCBB: IHTL)

HUGE NEWSLETTER COVERAGE THIS WEEK!!!

This coming Tuesday IHTL will be profiled by some major newsletters.
huge volume and a strong increase in price is expected for several days.

The 52 week high for IHTL is $.38  Needless to say there is huge upside
potential for IHTL.

We believe the stock could easily reach over $.25

Good luck and watch IHTL fly this week!

DISCLAIMER: hotstocks cautions that stocks are high-risk investments and
that some or all investment dollars can be lost. We suggest you consult a
professional investment advisor before purchasing any stock. All opinions
expressed in this newsletter are the opinions of hotstocks.  We own shares
in the mentioned company and may sell at any time. We recommend you use the
information found here as an initial starting point for conducting your own
research and conduct your own due diligence on the featured company in order
to determine your own personal opinion of the company before investing. 

for proper removal from this newsletter you must email: [email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 8 Jun 2001 12:22:30 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: SCTP lifetime
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      MAA02556
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-213.dallas.net [209.44.42.213]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

There is no precedent for this text.  MTP Level 3 has its own idea as to
when Transmit Buffers in Level 2 are to be cleared and its own idea of the
"age" of MSUs in transmit buffers.

By recommending that the M2UA abort the association, MTP Level 3 must follow
processor outage procedures which include recovery to avoid discarding the
messages in the Level 2 TB if the processor outage condition should recover
in sufficient time.

This procedure, which is based on lifetime rather than MTP Level 3 processor
outage timers will have a unexpected impact on Level 3 and will reduce
interoperability between conforming MTP Level 3 implementations and M2UA.

It is not a good idea to follow the proscribed procedure.
I propose you change "SHALL" to "SHOULD NOT".

--Brian

On Thu, 07 Jun 2001, Ken Morneault wrote:
> 
> 
> Brian, Jacob,
> 
> Sorry, I've been away from my email not that it mattered to much
> since this text was added by Jacob.
> 
> Would it be sufficient to change the "SHALL" to a "MAY" for those
> that would like to use a "lifetime"?
> 
> Ken
> 
> At 10:25 AM 6/5/01 -0500, Brian F. G. Bidulock wrote:
> >Jacob,
> >
> >As long as they are not delayed more or
> >more often than is required by Q.706.
> >
> >On Tue, 05 Jun 2001, Jacob Heitz wrote:
> >
> > > I did not say MSUs will be discarded by the system.
> > > I said MSUs will be discarded by the receiver and
> > > retransmitted by the sender. They will be delayed
> > > by the system.
> > > 
> > > "Brian F. G. Bidulock" wrote:
> > > > 
> > > > Jacob,
> > > > 
> > > > Congestion discard does not mean that the MSU is
> > > > discarded from the system.  It means that there is
> > > > no room in the receivers RB.  It is like sending
> > > > arwnd of 0 and then no longer acking TSNs.  Messages
> > > > are held in the sender's retransmit buffer and
> > > > are not discarded from the system.  Discarding
> > > > messages from the system is unacceptable to the
> > > > extents outlined in Q.706.
> > > > 
> > > > On Mon, 04 Jun 2001, Jacob Heitz wrote:
> > > > >
> > > > > After SIB ends, the receiver may send negative
> > > > > acknowledgement. This will cause the sender to
> > > > > retransmit. It will cause delay. It is acceptable
> > > > > in Q.703. Q.703 SDLs even have a "Congestion discard"
> > > > > variable to discard received MSUs during the busy
> > > > > condition.
> > > 
> >
> >-- 
> >Brian F. G. Bidulock
> >[email-masked]
> >http://www.openss7.org/
> >
> >
> >---
> >You are currently subscribed to sigtran as: [email-masked]
> >To unsubscribe send a blank email to
[email-masked] 
> 
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Fri, 08 Jun 2001 13:34:50 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA: SCTP lifetime
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

Honestly, I wouldn't mind deleting the text.  Those that want to implement
such a procedure could still do so.

Regards,

Ken

At 12:22 PM 6/8/01 -0500, you wrote:
>Ken,
>
>There is no precedent for this text.  MTP Level 3 has its
>own idea as to when Transmit Buffers in Level 2 are to be
>cleared and its own idea of the "age" of MSUs in transmit
>buffers.
>
>By recommending that the M2UA abort the association, MTP
>Level 3 must follow processor outage procedures which
>include recovery to avoid discarding the messages in the
>Level 2 TB if the processor outage condition should recover
>in sufficient time.
>
>This procedure, which is based on lifetime rather than
>MTP Level 3 processor outage timers will have a unexpected
>impact on Level 3 and will reduce interoperability between
>conforming MTP Level 3 implementations and M2UA.
>
>It is not a good idea to follow the proscribed procedure.
>I propose you change "SHALL" to "SHOULD NOT".
>
>--Brian
>
>On Thu, 07 Jun 2001, Ken Morneault wrote:
> > 
> > 
> > Brian, Jacob,
> > 
> > Sorry, I've been away from my email not that it mattered to much
> > since this text was added by Jacob.
> > 
> > Would it be sufficient to change the "SHALL" to a "MAY" for those
> > that would like to use a "lifetime"?
> > 
> > Ken
> > 
> > At 10:25 AM 6/5/01 -0500, Brian F. G. Bidulock wrote:
> > >Jacob,
> > >
> > >As long as they are not delayed more or
> > >more often than is required by Q.706.
> > >
> > >On Tue, 05 Jun 2001, Jacob Heitz wrote:
> > >
> > > > I did not say MSUs will be discarded by the system.
> > > > I said MSUs will be discarded by the receiver and
> > > > retransmitted by the sender. They will be delayed
> > > > by the system.
> > > > 
> > > > "Brian F. G. Bidulock" wrote:
> > > > > 
> > > > > Jacob,
> > > > > 
> > > > > Congestion discard does not mean that the MSU is
> > > > > discarded from the system.  It means that there is
> > > > > no room in the receivers RB.  It is like sending
> > > > > arwnd of 0 and then no longer acking TSNs.  Messages
> > > > > are held in the sender's retransmit buffer and
> > > > > are not discarded from the system.  Discarding
> > > > > messages from the system is unacceptable to the
> > > > > extents outlined in Q.706.
> > > > > 
> > > > > On Mon, 04 Jun 2001, Jacob Heitz wrote:
> > > > > >
> > > > > > After SIB ends, the receiver may send negative
> > > > > > acknowledgement. This will cause the sender to
> > > > > > retransmit. It will cause delay. It is acceptable
> > > > > > in Q.703. Q.703 SDLs even have a "Congestion discard"
> > > > > > variable to discard received MSUs during the busy
> > > > > > condition.
> > > > 
> > >
> > >-- 
> > >Brian F. G. Bidulock
> > >[email-masked]
> > >http://www.openss7.org/
> > >
> > >
> > >---
> > >You are currently subscribed to sigtran as: [email-masked]
> > >To unsubscribe send a blank email to
[email-masked] 
> > 
> > 
> > 
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to
[email-masked]
>
>-- 
>Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
>[email-masked]    ¦ world; the unreasonable one persists in  ¦
>http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 8 Jun 2001 13:18:20 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: SCTP lifetime
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-213.dallas.net [209.44.42.213]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

That's the position I started with.  Please strike the paragraphs and let
the implementation of the NIF decide what to do concerning lifetimes.

--Brian

On Fri, 08 Jun 2001, Ken Morneault wrote:
> 
> Honestly, I wouldn't mind deleting the text.  Those that want
> to implement such a procedure could still do so.
> 

On Mon, 04 Jun 2001, Brian F. G. Bidulock wrote:
> 
> It might be a good idea to strike this paragraph.  The
> implementation should be able to set any lifetimes that
> they deem fit, even no lifetimes.
> 

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 8 Jun 2001 13:45:13 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: M2UA draft 7 questions (SCTP congestion at ASP)
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], sigtran 
                  <[email-masked]>
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-213.dallas.net [209.44.42.213]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

If you are talking about dropping the association, this will have a more
negative effect on MTP Level 3 than sending it LPO.  The reason being that
LPO can be cancelled with LPR if the congestion clears.  Dropping the
association has no procedure for recovery.  The end-result of LPO versus
dropping the association has no differennce when the link fails as a result
of the outage.  Both sides perform time-controlled changeover (one side
because it isn't given a FSNC, the other because it can't retrieve buffers
because there is no association).
The difference lies in that if the SCTP congestion is of a temporary nature
(i.e, persists for less than 1 second) then LPO can be cancelled allowing
for complete recovery of the link.  Reducing the number of changeovers which
occur as a result of transient conditions is a good objective in design for
M2UA, because it reduces the number of lost or mis-sequenced messages in the
newtork.

The problems in handling RB and TB/RTB, which in M2UA are shared between
M2UA and MTP2, can only be resolved by placing the control of
acknolwedgement of received MSUs in the hands of M2UA.  This can only be
accomplished by implementation dependent interaction with the MTP2 at the
SG.

The MTP Level 2 specification is very weak regarding the handling of the
Receive Buffer (RB).  Some variations of the specification provide for a
Clear_RB primitive, some do not.  Some specify the counting of MSUs in the
RB at Level 2, some do not.  The handling of Congestion_Accept and
Congestion_Discard is not clear.
All of this RB handling, however, can have serious impact on the operation
of M2UA.  It is not possible to export a simple and clearly defined layer
interface across SCTP.

Rather than considering M2UA as exporting this vague idea of an MTP2 to MTP3
interface, it would be more worthwhile to consider the M2UA as "an
implementation" of the MTP3 to MTP2 interface, where some of the
"implementation dependent" stuff from Q.703 are defined for M2UA.  Q.703
tries to leave the door wide open on buffer handling and congestion to
permit any manny of buffer implementation, whether it be in hardware at the
signalling terminal, within the host (L3 processor), or implemented in some
other fashion.  M2UA does not have the luxury of leaving the door wide open
on buffer handling and congestion because it has firmly specificied buffers
and congestion procedures in SCTP which dictate a specific interpretation of
the "implementation dependent" functions in the Q.703 and other L2 specs to
permit conformance of the resulting system to Q.781 and other conformance
specifications at the MTP Level 3 boundary.

Sorry for running on, but the necessity of considering M2UA as "an
implementation" of Q.703 et al as dictated by SCTP seems to escape many.

--Brian

On Fri, 08 Jun 2001, Ken Morneault wrote:

> 
> 
> Hanping,
> 
> Your suggestion is pretty much what Jacob as already proposed (it
> was discussed in this very thread - see previous emails).  I plan to
change
> text to Jacob's proposal.
> 
> Ken
> 

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Fri, 08 Jun 2001 11:54:00 -0700
From: Jacob Heitz <[email-masked]>
Organization: Lucent Technologies, Internetworking Systems, Software 
              Engineering, Alameda
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.5.1 i86pc)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: SCTP lifetime
X-SMTP-HELO: drawbridge.ascend.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: drawbridge.ascend.com [198.4.92.1]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

There most definitely IS a precedent for this text.

When an MTP2 link congests, it withholds acknowledgements.
This in turn causes the MTP2 sender to send congestion indications to MTP3
as its transmission buffer fills.
If MTP2 congestion lasts for too long, longer than L2-T6, MTP2 takes the
link out of service.

This is what the lifetime text does: If congestion lasts too long, the link
is taken out of service.

The thing that SHOULD NOT be done at excessive congestion is to signal
processor outage. First, there is no precedence for signaling processor
outage on congestion. Second, processor outage on congestion will likely
cause MSUs to be received out of order, as I have shown in previous emails.

"Brian F. G. Bidulock" wrote:
> 
> Ken,
> 
> There is no precedent for this text.  MTP Level 3 has its
> own idea as to when Transmit Buffers in Level 2 are to be
> cleared and its own idea of the "age" of MSUs in transmit
> buffers.
> 
> By recommending that the M2UA abort the association, MTP
> Level 3 must follow processor outage procedures which
> include recovery to avoid discarding the messages in the
> Level 2 TB if the processor outage condition should recover
> in sufficient time.
> 
> This procedure, which is based on lifetime rather than
> MTP Level 3 processor outage timers will have a unexpected
> impact on Level 3 and will reduce interoperability between
> conforming MTP Level 3 implementations and M2UA.
> 
> It is not a good idea to follow the proscribed procedure.
> I propose you change "SHALL" to "SHOULD NOT".
> 
> --Brian
> 
> On Thu, 07 Jun 2001, Ken Morneault wrote:
> >
> >
> > Brian, Jacob,
> >
> > Sorry, I've been away from my email not that it mattered to much
> > since this text was added by Jacob.
> >
> > Would it be sufficient to change the "SHALL" to a "MAY" for those
> > that would like to use a "lifetime"?
> >
> > Ken
> >
> > At 10:25 AM 6/5/01 -0500, Brian F. G. Bidulock wrote:
> > >Jacob,
> > >
> > >As long as they are not delayed more or
> > >more often than is required by Q.706.
> > >
> > >On Tue, 05 Jun 2001, Jacob Heitz wrote:
> > >
> > > > I did not say MSUs will be discarded by the system.
> > > > I said MSUs will be discarded by the receiver and
> > > > retransmitted by the sender. They will be delayed
> > > > by the system.
> > > >
> > > > "Brian F. G. Bidulock" wrote:
> > > > >
> > > > > Jacob,
> > > > >
> > > > > Congestion discard does not mean that the MSU is
> > > > > discarded from the system.  It means that there is
> > > > > no room in the receivers RB.  It is like sending
> > > > > arwnd of 0 and then no longer acking TSNs.  Messages
> > > > > are held in the sender's retransmit buffer and
> > > > > are not discarded from the system.  Discarding
> > > > > messages from the system is unacceptable to the
> > > > > extents outlined in Q.706.
> > > > >
> > > > > On Mon, 04 Jun 2001, Jacob Heitz wrote:
> > > > > >
> > > > > > After SIB ends, the receiver may send negative
> > > > > > acknowledgement. This will cause the sender to
> > > > > > retransmit. It will cause delay. It is acceptable
> > > > > > in Q.703. Q.703 SDLs even have a "Congestion discard"
> > > > > > variable to discard received MSUs during the busy
> > > > > > condition.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Fri, 08 Jun 2001 12:09:48 -0700
From: Jacob Heitz <[email-masked]>
Organization: Lucent Technologies, Internetworking Systems, Software 
              Engineering, Alameda
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.5.1 i86pc)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M2UA draft 7 questions (SCTP congestion at ASP)
X-SMTP-HELO: drawbridge.ascend.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: drawbridge.ascend.com [198.4.92.1]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

"Brian F. G. Bidulock" wrote:
> 
> Ken,
> 
> If you are talking about dropping the association, this will
> have a more negative effect on MTP Level 3 than sending it
> LPO. 

WRONG. 

LPO on congestion will likely cause MSUs to be received out of order. This
is because MSUs in the congested link will eventually be delivered.
Meanwhile MTP3 does time-controlled changeover. This means, MTP3 simply
sends MSUs on a different link without informing the peer of a problem.

Taking the link out of service will cause dropped MSUs only.
MTP3 will do emergency changeover. This informs the peer of the broken link
and causes the peer to stop receiving from the broken link.

Out of order MSUs is 1000 times worse than dropped MSUs.

> The reason being that LPO can be cancelled with LPR if
> the congestion clears.  Dropping the association has no procedure
> for recovery. 

The association will be aborted (and link taken out of service) only on
EXCESSIVE congestion. A timer has ALREADY expired. This is the lifetime
timer in SCTP.

> The end-result of LPO versus dropping the
> association has no differennce when the link fails as a result
> of the outage. 

WRONG.

LPO causes time-controlled changeover.
Out-of-service causes emergency changeover.

Emergency changeover informs the peer of the bad link, preventing it from
receiving MSUs out of order.
Time controlled changeover does not.

[snip the junk]

> 
> --Brian
> 
> On Fri, 08 Jun 2001, Ken Morneault wrote:
> 
> >
> >
> > Hanping,
> >
> > Your suggestion is pretty much what Jacob as already proposed (it
> > was discussed in this very thread - see previous emails).  I plan to
change
> > text to Jacob's proposal.
> >
> > Ken
> >

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 8 Jun 2001 14:36:16 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: SCTP lifetime
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      OAA04874
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-213.dallas.net [209.44.42.213]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Jacob,

On Fri, 08 Jun 2001, Jacob Heitz wrote:

> There most definitely IS a precedent for this text.
> 
> When an MTP2 link congests, it withholds acknowledgements.
> This in turn causes the MTP2 sender to send congestion
> indications to MTP3 as its transmission buffer fills.
> If MTP2 congestion lasts for too long, longer than
> L2-T6, MTP2 takes the link out of service.

MTP2 has T6 or T7 running.  There is no precedence for MTP2 to also be
measuring the lifetime of an MSU in the TB using another method.  In fact,
by using another method, Q.781 conformance tests may be made to fail on the
link in the presence of retricted SCTP bandwidth or an error-prone SCTP
connection: particularly the cases which withold acknoledgements.
Conformance of the implementation cannot be allowed to be dependent on
performance factors.

> 
> This is what the lifetime text does: If congestion lasts
> too long, the link is taken out of service.
> 
> The thing that SHOULD NOT be done at excessive congestion
> is to signal processor outage. First, there is no precedence
> for signaling processor outage on congestion. Second,
> processor outage on congestion will likely cause
> MSUs to be received out of order, as I have shown in
> previous emails.
> 

There is no precedence for indicating link failure when taking the interface
between MTP Level 3 and MTP Level 2 down in response to congestion within
the implementation.

The proscribed approach is for management to detect the failure between MTP
Level 3 and MTP Level 2 and signal local processor outage to both MTP3 and
MTP2.  This is well documented in the specs.

Does anyone else have a view on this matter?

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 8 Jun 2001 14:59:00 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA draft 7 questions (SCTP congestion at ASP)
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      OAA05142
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-213.dallas.net [209.44.42.213]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Jacob,

On Fri, 08 Jun 2001, Jacob Heitz wrote:

> "Brian F. G. Bidulock" wrote:
> > 
> > Ken,
> > 
> > If you are talking about dropping the association, this will
> > have a more negative effect on MTP Level 3 than sending it
> > LPO. 
> 
> WRONG. 
  ^^^^^  Hollering doesn't help.
> 
> LPO on congestion will likely cause MSUs to be received out
> of order. This is because MSUs in the congested link will
> eventually be delivered.

Signal LPO to MTP2 as well, and in advance of the backed up MSUs.
That way MTP2 will get the LPO before the messages, when SCTP congestion
clears.  The MSUs will either arrive at an MTP2 which is in service or out
of service.  The will not be resent by MTP3, and normal time-controlled
changeover will avoid missequencing of messages.

> Meanwhile MTP3 does time-controlled 
> changeover. This means, MTP3 simply sends MSUs on a different
> link without informing the peer of a problem.

That is what it is supposed to do.  Management is responsible for informing
both MTP3 as well as MTP2 of the LPO condition.  MTP3 is certainly not
responsible for communicating LPO to MTP2 (when it cannot communicate with
MTP2).  This is nothing more than the normal way that SS7 operates, Jacob.

> 
> Taking the link out of service will cause dropped MSUs only.
> MTP3 will do emergency changeover. This informs the peer of 
> the broken link and causes the peer to stop receiving from
> the broken link.
> 
> Out of order MSUs is 1000 times worse than dropped MSUs.

No mis-sequencing will occur beyond the limits already implemented in SS7
(because these are SS7 procedures) and one can expect performance within the
bounds specified by the queueing model and verified by simulation.

Your suggestion will cause a changeover and the loss of MSUs every time that
SCTP congestion is experienced, no matter how brief, and will lose messages
faster than a normal SS7 implementation which waits until processor outage
or congestion is of a "long term" before taking actions with regard to
changeover.  Your approach will cause immediate and emergency changeover
discarding MSUs along the way.

> 
> > The reason being that LPO can be cancelled with LPR if
> > the congestion clears.  Dropping the association has no procedure
> > for recovery. 
> 
> The association will be aborted (and link taken out of
> service) only on EXCESSIVE congestion. A timer has ALREADY
> expired. This is the lifetime timer in SCTP.
> 
> > The end-result of LPO versus dropping the
> > association has no differennce when the link fails as a result
> > of the outage. 
> 
> WRONG.
  ^^^^^  Hollering doesn't help.
> 
> LPO causes time-controlled changeover.
> Out-of-service causes emergency changeover.
> 
> Emergency changeover informs the peer of the bad link,
> preventing it from receiving MSUs out of order.
> Time controlled changeover does not.

        > Out-of-service causes emergency changeover.

This is not a correct statement, Jacob.  Please refer to Q.704.
Whether time-controlled changeover or regular changeover procedures are used
depends upon the configuration of the newtork.
If the signalling point is changing over to a signalling link which
terminates on an adjacent signalling point which is different from the
adjacent signalling point on the signalling link from which it is changing
over, time-controlled changeover procedures are permitted (and preferred).

Therefore, you cannot say, without considering the network configuration,
that this link failure will invoke emergency changeover.  In the case where
time-controlled changeover is selected, the other end of the link will not
be informed of the failure and will merrily continue transfering messages in
both directions.

Because of this, one cannot get away from synchronizing the view of the
state of the link at both the ASP and SG sides.
If the ASP and SG loose the communication necessary to ensure this
synchronization, the only option provided for in conformance with SS7
specifications is for both sides to view themselves as having received a
Local Processor Outage signal from management.

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Fri, 08 Jun 2001 16:06:33 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA draft 7 questions (SCTP congestion at ASP)
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

All:

Here is the current suggested text for handling SCTP congestion.  Might as
well get it right now, before the next version of the draft is sent out.

1.5.5  Flow Control / Congestion

To minimize the possibility of congestion in the SCTP association, it is
recommended that the IP network be engineered to ensure the combined
bandwidth of all the MTP2 links served by that association.  However, the
possibility of congestion of the SCTP association exists.  The next few
paragraphs describe a suggestion on how an implementation may temporarily
reduce the flow of messages into the congested SCTP association.
  
It is possible for the M2UA layer to be informed of IP network congestion
onset and abatement by means of an implementation-dependent function (i.e.
an indication from the SCTP). 

The M2UA layer on the MGC will remember the last Congestion Indication
message it received from the SG.  If, at the MGC, SCTP indicates congestion
to M2UA, (that means SCTP transmission and retransmission buffer fill
exceeds a given congestion onset threshold) M2UA will send the
Link-Congested primitive to MTP3 for all affected MTP2 links.  The level of
congestion indicated shall be the highest possible.

If, at the MGC, SCTP indicates congestion abatement to M2UA, (that means
SCTP transmission and retransmission buffer fill falls below a given
congestion abatement threshold) M2UA will send the Link-Congested primitive
or the Link-Congestion-ceased primitive to MTP3 for all affected MTP2 links.
The level of congestion indicated shall be as indicated in the last
Congestion Indication message received from the SG.

The SG will remember the last congestion status message it received from the
MGC (i.e. STATUS_CONG_ACCEPT, STATUS_CONG_DISCARD or STATUS_CONG_CLEAR in
the State Request message).  If, at the SG, SCTP indicates congestion to
M2UA and the last congestion status message received from the MGC was
STATUS_CONG_CLEAR M2UA will send the Congestion-Accept primitive to MTP2.

If, at the SG, SCTP indicates congestion abatement to M2UA, M2UA will send a
congestion primitive to MTP2.  The level of congestion indicated shall be as
indicated in the last congestion status message received from the MGC.

At 01:45 PM 6/8/01 -0500, you wrote:
>Ken,
>
>If you are talking about dropping the association, this will
>have a more negative effect on MTP Level 3 than sending it
>LPO.  The reason being that LPO can be cancelled with LPR if
>the congestion clears.  Dropping the association has no procedure
>for recovery.  The end-result of LPO versus dropping the
>association has no differennce when the link fails as a result
>of the outage.  Both sides perform time-controlled changeover
>(one side because it isn't given a FSNC, the other because
>it can't retrieve buffers because there is no association).
>The difference lies in that if the SCTP congestion is of a
>temporary nature (i.e, persists for less than 1 second) then
>LPO can be cancelled allowing for complete recovery of the
>link.  Reducing the number of changeovers which occur as a
>result of transient conditions is a good objective in design
>for M2UA, because it reduces the number of lost or mis-sequenced
>messages in the newtork.
>
>The problems in handling RB and TB/RTB, which in M2UA are
>shared between M2UA and MTP2, can only be resolved by placing
>the control of acknolwedgement of received MSUs in the hands
>of M2UA.  This can only be accomplished by implementation
>dependent interaction with the MTP2 at the SG.
>
>The MTP Level 2 specification is very weak regarding the handling
>of the Receive Buffer (RB).  Some variations of the specification
>provide for a Clear_RB primitive, some do not.  Some specify
>the counting of MSUs in the RB at Level 2, some do not.  The
>handling of Congestion_Accept and Congestion_Discard is not clear.
>All of this RB handling, however, can have serious impact on
>the operation of M2UA.  It is not possible to export a simple
>and clearly defined layer interface across SCTP.
>
>Rather than considering M2UA as exporting this vague idea of
>an MTP2 to MTP3 interface, it would be more worthwhile to
>consider the M2UA as "an implementation" of the MTP3 to MTP2
>interface, where some of the "implementation dependent" stuff
>from Q.703 are defined for M2UA.  Q.703 tries to leave the
>door wide open on buffer handling and congestion to permit
>any manny of buffer implementation, whether it be in hardware
>at the signalling terminal, within the host (L3 processor),
>or implemented in some other fashion.  M2UA does not have
>the luxury of leaving the door wide open on buffer handling
>and congestion because it has firmly specificied buffers and
>congestion procedures in SCTP which dictate a specific
>interpretation of the "implementation dependent" functions
>in the Q.703 and other L2 specs to permit conformance of
>the resulting system to Q.781 and other conformance specifications
>at the MTP Level 3 boundary.
>
>Sorry for running on, but the necessity of considering M2UA
>as "an implementation" of Q.703 et al as dictated by SCTP
>seems to escape many.
>
>--Brian
>
>
>
>On Fri, 08 Jun 2001, Ken Morneault wrote:
>
> > 
> > 
> > Hanping,
> > 
> > Your suggestion is pretty much what Jacob as already proposed (it
> > was discussed in this very thread - see previous emails).  I plan to
change
> > text to Jacob's proposal.
> > 
> > Ken
> > 
>
>-- 
>Brian F. G. Bidulock
>[email-masked]
>http://www.openss7.org/
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 08 Jun 2001 13:09:13 -0700
From: Jacob Heitz <[email-masked]>
Organization: Lucent Technologies, Internetworking Systems, Software 
              Engineering, Alameda
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: SCTP lifetime
X-SMTP-HELO: drawbridge.ascend.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: drawbridge.ascend.com [198.4.92.1]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

This is also well documented in Q.703:

  It should be noted that in the case that processor 
  outage is of "long term", i.e. when timer T1 in MTP
  level 3 (see 16.8/Q.704) has expired, problems exist 
  with old messages, which are those messages
  stored within level 2 buffers after the switch of 
  new traffic on the alternative link(s) has been
  performed. This is because, in general, the level 
  2 buffers on both sides of the link contain some
  MSUs. If normal operation of the link is resumed, 
  (re)transmission of these messages would result in
  message missequencing. Furthermore, it is very 
  likely that these messages are related to calls that
  have already been released or to network management 
  situations that have long since passed.

When the path from MGC to SG congests, the MTP2 on the SG is very much alive
and completely unaware of a problem.
It is very able to send "old messages" that arrive from the congested M2UA.
There is nothing the MGC can do about it. A FLUSH_BUFFERS message would take
too long to get through and will be in line behind all the "old messages"
anyway.

So, you see, it really doesn't matter what the precedent is. What matters is
that these "old messages" will get delivered out of order once MTP3 does
time-controlled changeover.

The draft might say "response to congestion is implementation dependent" and
give some suggestions of what to do. It should also state that processor
outage SHOULD NOT be signalled for the reason outlined above.

"Brian F. G. Bidulock" wrote:
> 
> Jacob,
> 
> On Fri, 08 Jun 2001, Jacob Heitz wrote:
> 
> > There most definitely IS a precedent for this text.
> >
> > When an MTP2 link congests, it withholds acknowledgements.
> > This in turn causes the MTP2 sender to send congestion
> > indications to MTP3 as its transmission buffer fills.
> > If MTP2 congestion lasts for too long, longer than
> > L2-T6, MTP2 takes the link out of service.
> 
> MTP2 has T6 or T7 running.  There is no precedence for MTP2 to
> also be measuring the lifetime of an MSU in the TB using another
> method.  In fact, by using another method, Q.781 conformance
> tests may be made to fail on the link in the presence of
> retricted SCTP bandwidth or an error-prone SCTP connection:
> particularly the cases which withold acknoledgements.
> Conformance of the implementation cannot be allowed to be
> dependent on performance factors.
> 
> >
> > This is what the lifetime text does: If congestion lasts
> > too long, the link is taken out of service.
> >
> > The thing that SHOULD NOT be done at excessive congestion
> > is to signal processor outage. First, there is no precedence
> > for signaling processor outage on congestion. Second,
> > processor outage on congestion will likely cause
> > MSUs to be received out of order, as I have shown in
> > previous emails.
> >
> 
> There is no precedence for indicating link failure when taking
> the interface between MTP Level 3 and MTP Level 2 down in
> response to congestion within the implementation.
> 
> The proscribed approach is for management to detect the failure
> between MTP Level 3 and MTP Level 2 and signal local processor
> outage to both MTP3 and MTP2.  This is well documented in the
> specs.
> 
> Does anyone else have a view on this matter?

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 08 Jun 2001 13:39:57 -0700
From: Jacob Heitz <[email-masked]>
Organization: Lucent Technologies, Internetworking Systems, Software 
              Engineering, Alameda
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M2UA draft 7 questions (SCTP congestion at ASP)
X-SMTP-HELO: drawbridge.ascend.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: drawbridge.ascend.com [198.4.92.1]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

"Brian F. G. Bidulock" wrote:
> 
> Jacob,
> 
> On Fri, 08 Jun 2001, Jacob Heitz wrote:
> 
> > "Brian F. G. Bidulock" wrote:
> > >
> > > Ken,
> > >
> > > If you are talking about dropping the association, this will
> > > have a more negative effect on MTP Level 3 than sending it
> > > LPO.
> >
> > WRONG.
>   ^^^^^  Hollering doesn't help.
> >
> > LPO on congestion will likely cause MSUs to be received out
> > of order. This is because MSUs in the congested link will
> > eventually be delivered.
> 
> Signal LPO to MTP2 as well, and in advance of the backed up MSUs.

You can't do that. We've been through this before. The congestion is likely
ahead of your SCTP transmission buffer, so you can't get past it to overtake
the congested MSUs.

> That way MTP2 will get the LPO before the messages, when SCTP
> congestion clears.  The MSUs will either arrive at an MTP2 which
> is in service or out of service.  The will not be resent by MTP3,
> and normal time-controlled changeover will avoid missequencing of
> messages.
> 
> > Meanwhile MTP3 does time-controlled
> > changeover. This means, MTP3 simply sends MSUs on a different
> > link without informing the peer of a problem.
> 
> That is what it is supposed to do.  Management is responsible for
> informing both MTP3 as well as MTP2 of the LPO condition.  MTP3
> is certainly not responsible for communicating LPO to MTP2 (when
> it cannot communicate with MTP2).  This is nothing more than the
> normal way that SS7 operates, Jacob.

The end that detects congestion cannot signal it to the SG.
It does not help to hide behind "Management is responsible".

> 
> >
> > Taking the link out of service will cause dropped MSUs only.
> > MTP3 will do emergency changeover. This informs the peer of
> > the broken link and causes the peer to stop receiving from
> > the broken link.
> >
> > Out of order MSUs is 1000 times worse than dropped MSUs.
> 
> No mis-sequencing will occur beyond the limits already implemented
> in SS7 (because these are SS7 procedures) and one can expect
> performance within the bounds specified by the queueing model and
> verified by simulation.

Nonsense.

The Q.704-T1 timer assumes that all old messages have been able to clear out
by the time it goes off. An IP network between MTP2 and MTP3 was never
designed for. A congested M2UA link will violate that assumption.

> 
> Your suggestion will cause a changeover and the loss of MSUs
> every time that SCTP congestion is experienced, no matter how
> brief, and will lose messages faster than a normal SS7 implementation
> which waits until processor outage or congestion is of a "long term"

2 seconds is "long term" for M2UA. Cross continent round trip times of less
than 100mS is common.

M2UA expects an IP network to be engineered to provide it with adequate
bandwidth to service a known number of MTP2 links.
M2UA has congestion indication messages to ensure that it does not exceed
that engineered bandwidth.

Given that, it should be extremely rare that it takes longer than 2 seconds
to transmit an M2UA message. If it does, then a changeover is justified.
Out-of-service is the safest way to get a changeover.

> before taking actions with regard to changeover.  Your approach
> will cause immediate and emergency changeover discarding MSUs
> along the way.
> 
> >
> > > The reason being that LPO can be cancelled with LPR if
> > > the congestion clears.  Dropping the association has no procedure
> > > for recovery.
> >
> > The association will be aborted (and link taken out of
> > service) only on EXCESSIVE congestion. A timer has ALREADY
> > expired. This is the lifetime timer in SCTP.
> >
> > > The end-result of LPO versus dropping the
> > > association has no differennce when the link fails as a result
> > > of the outage.
> >
> > WRONG.
>   ^^^^^  Hollering doesn't help.
> >
> > LPO causes time-controlled changeover.
> > Out-of-service causes emergency changeover.
> >
> > Emergency changeover informs the peer of the bad link,
> > preventing it from receiving MSUs out of order.
> > Time controlled changeover does not.
> 
>         > Out-of-service causes emergency changeover.
> 
> This is not a correct statement, Jacob.  Please refer to Q.704.
> Whether time-controlled changeover or regular changeover
> procedures are used depends upon the configuration of the newtork.
> If the signalling point is changing over to a signalling link
> which terminates on an adjacent signalling point which is different
> from the adjacent signalling point on the signalling link from
> which it is changing over, time-controlled changeover procedures
> are permitted (and preferred).

I see nothing in Q.704 to support this. You may be misinterpreting this case
of 5.6.2:

  i) No signalling path exists between the two ends of 
     the unavailable link, so that the exchange
     of changeover messages is impossible.

> 
> Therefore, you cannot say, without considering the network
> configuration, that this link failure will invoke emergency
> changeover.  In the case where time-controlled changeover is
> selected, the other end of the link will not be informed of the
> failure and will merrily continue transfering messages in
> both directions.
> 
> Because of this, one cannot get away from synchronizing the
> view of the state of the link at both the ASP and SG sides.
> If the ASP and SG loose the communication necessary to ensure
> this synchronization, the only option provided for in conformance
> with SS7 specifications is for both sides to view themselves
> as having received a Local Processor Outage signal from
> management.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 8 Jun 2001 15:57:36 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: SCTP lifetime
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      PAA06086
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-213.dallas.net [209.44.42.213]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Jacob,

On Fri, 08 Jun 2001, Jacob Heitz wrote:

> This is also well documented in Q.703:
> 
>   It should be noted that in the case that processor 
>   outage is of "long term", i.e. when timer T1 in MTP
>   level 3 (see 16.8/Q.704) has expired, problems exist 
>   with old messages, which are those messages
>   stored within level 2 buffers after the switch of 
>   new traffic on the alternative link(s) has been
>   performed. This is because, in general, the level 
>   2 buffers on both sides of the link contain some
>   MSUs. If normal operation of the link is resumed, 
>   (re)transmission of these messages would result in
>   message missequencing. Furthermore, it is very 
>   likely that these messages are related to calls that
>   have already been released or to network management 
>   situations that have long since passed.
> 

This is simply the rationale for MTP3 clearing buffers when MTP2 recovered
from processor outage.

> When the path from MGC to SG congests, the MTP2 on the
> SG is very much alive and completely unaware of a problem.
> It is very able to send "old messages" that arrive from
> the congested M2UA. There is nothing the MGC can do
> about it. A FLUSH_BUFFERS message would take too long
> to get through and will be in line behind all the
> "old messages" anyway.

It can easily be made aware of the problem using ECN.
This is a responsibility of the underlying SCTP and network implementation,
not M2UA.

> 
> So, you see, it really doesn't matter what the precedent
> is. What matters is that these "old messages" will
> get delivered out of order once MTP3 does time-controlled
> changeover.

No they won't, not in my implementation.  Did you want to send them in
yours?

> 
> The draft might say "response to congestion is 
> implementation dependent" and give some suggestions of
> what to do. It should also state that processor
> outage SHOULD NOT be signalled for the reason outlined
> above.

Certainly not.  It is a very usable approach which is in full alignment with
the existing MTP procedures.

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 08 Jun 2001 14:17:22 -0700
From: Jacob Heitz <[email-masked]>
Organization: Lucent Technologies, Internetworking Systems, Software 
              Engineering, Alameda
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: SCTP lifetime
X-SMTP-HELO: drawbridge.ascend.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: drawbridge.ascend.com [198.4.92.1]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

"Brian F. G. Bidulock" wrote:
> 
> Jacob,
> 
> On Fri, 08 Jun 2001, Jacob Heitz wrote:
> 
> > This is also well documented in Q.703:
> >
> >   It should be noted that in the case that processor
> >   outage is of "long term", i.e. when timer T1 in MTP
> >   level 3 (see 16.8/Q.704) has expired, problems exist
> >   with old messages, which are those messages
> >   stored within level 2 buffers after the switch of
> >   new traffic on the alternative link(s) has been
> >   performed. This is because, in general, the level
> >   2 buffers on both sides of the link contain some
> >   MSUs. If normal operation of the link is resumed,
> >   (re)transmission of these messages would result in
> >   message missequencing. Furthermore, it is very
> >   likely that these messages are related to calls that
> >   have already been released or to network management
> >   situations that have long since passed.
> >
> 
> This is simply the rationale for MTP3 clearing buffers
> when MTP2 recovered from processor outage.

It also says "problems exist with old messages" regardless of the
"rationale".

> 
> > When the path from MGC to SG congests, the MTP2 on the
> > SG is very much alive and completely unaware of a problem.
> > It is very able to send "old messages" that arrive from
> > the congested M2UA. There is nothing the MGC can do
> > about it. A FLUSH_BUFFERS message would take too long
> > to get through and will be in line behind all the
> > "old messages" anyway.
> 
> It can easily be made aware of the problem using ECN.
> This is a responsibility of the underlying SCTP and
> network implementation, not M2UA.

Then you must mandate that ECN be implemented and can ALWAYS get a message
through. I can do without this impossible restriction.

> 
> >
> > So, you see, it really doesn't matter what the precedent
> > is. What matters is that these "old messages" will
> > get delivered out of order once MTP3 does time-controlled
> > changeover.
> 
> No they won't, not in my implementation.  Did you want
> to send them in yours?

Then your implementation only works on a wire. It needs to work on an IP
network where there is a chance that a message, any message, may be delayed.
We engineer a network to make the chance of long delay low, but we must
design for the rare case when it happens.

> 
> >
> > The draft might say "response to congestion is
> > implementation dependent" and give some suggestions of
> > what to do. It should also state that processor
> > outage SHOULD NOT be signalled for the reason outlined
> > above.
> 
> Certainly not.  It is a very usable approach which is
> in full alignment with the existing MTP procedures.

No, it isn't. Processor outage is not an existing procedure for congestion
between MTP2 and MTP3, because this interface has always been assumed to be
"frictionless" to use your own term.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 8 Jun 2001 16:45:39 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA draft 7 questions (SCTP congestion at ASP)
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      QAA06845
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-213.dallas.net [209.44.42.213]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Jacob,

On Fri, 08 Jun 2001, Jacob Heitz wrote:

> "Brian F. G. Bidulock" wrote:
> > 
> > Jacob,
> > 
> > On Fri, 08 Jun 2001, Jacob Heitz wrote:
> > 
> > > "Brian F. G. Bidulock" wrote:
> > > >
> > > > Ken,
> > > >
> > > > If you are talking about dropping the association, this will
> > > > have a more negative effect on MTP Level 3 than sending it
> > > > LPO.
> > >
> > > WRONG.
> >   ^^^^^  Hollering doesn't help.
> > >
> > > LPO on congestion will likely cause MSUs to be received out
> > > of order. This is because MSUs in the congested link will
> > > eventually be delivered.
> > 
> > Signal LPO to MTP2 as well, and in advance of the backed up MSUs.
> 
> You can't do that. We've been through this before. The
> congestion is likely ahead of your SCTP transmission buffer,
> so you can't get past it to overtake the congested MSUs.

Sure its possible, as long a the SG M2UA knows the status of the SCTP
association.  ECN and any number of other approaches at SCTP and below is
capable of giving the same indication to both sides.  Even interworking to
an ECN chunk is possible.  Just because you can't see how to do it does not
mean that it is not possible.

> 
> > That way MTP2 will get the LPO before the messages, when SCTP
> > congestion clears.  The MSUs will either arrive at an MTP2 which
> > is in service or out of service.  The will not be resent by MTP3,
> > and normal time-controlled changeover will avoid missequencing of
> > messages.
> > 
> > > Meanwhile MTP3 does time-controlled
> > > changeover. This means, MTP3 simply sends MSUs on a different
> > > link without informing the peer of a problem.
> > 
> > That is what it is supposed to do.  Management is responsible for
> > informing both MTP3 as well as MTP2 of the LPO condition.  MTP3
> > is certainly not responsible for communicating LPO to MTP2 (when
> > it cannot communicate with MTP2).  This is nothing more than the
> > normal way that SS7 operates, Jacob.
> 
> The end that detects congestion cannot signal it to the SG.
> It does not help to hide behind "Management is responsible".

See above.  It is possible.

> 
> > 
> > >
> > > Taking the link out of service will cause dropped MSUs only.
> > > MTP3 will do emergency changeover. This informs the peer of
> > > the broken link and causes the peer to stop receiving from
> > > the broken link.
> > >
> > > Out of order MSUs is 1000 times worse than dropped MSUs.
> > 
> > No mis-sequencing will occur beyond the limits already implemented
> > in SS7 (because these are SS7 procedures) and one can expect
> > performance within the bounds specified by the queueing model and
> > verified by simulation.
> 
> Nonsense.
> 
> The Q.704-T1 timer assumes that all old messages have been able
> to clear out by the time it goes off. An IP network between
> MTP2 and MTP3 was never designed for. A congested M2UA link
> will violate that assumption.

No, not nonsense.  See section ANSI T1.111.4-1992, top of page 21.
"If it is used, any message signal units, incoming or outgoing, that remain
in level 2 after T1 has expired and traffic has been diverted to alternative
link(s) are discarded."

MTP uses the clear_buffers primitive for just this purpose.

> 
> > 
> > Your suggestion will cause a changeover and the loss of MSUs
> > every time that SCTP congestion is experienced, no matter how
> > brief, and will lose messages faster than a normal SS7 implementation
> > which waits until processor outage or congestion is of a "long term"
> 
> 2 seconds is "long term" for M2UA. Cross continent round trip
> times of less than 100mS is common.
> 
> M2UA expects an IP network to be engineered to provide it with
> adequate bandwidth to service a known number of MTP2 links.
> M2UA has congestion indication messages to ensure that it
> does not exceed that engineered bandwidth.
> 
> Given that, it should be extremely rare that it takes longer
> than 2 seconds to transmit an M2UA message. If it does, then
> a changeover is justified. Out-of-service is the safest way
> to get a changeover.

Again, you won't get regular changeover between combined linksets, and you
won't get regular changeover between some linksets in a combined linkset.
You will get time-controlled changeover.
See below.

> 
> > before taking actions with regard to changeover.  Your approach
> > will cause immediate and emergency changeover discarding MSUs
> > along the way.
> > 
> > >
> > > > The reason being that LPO can be cancelled with LPR if
> > > > the congestion clears.  Dropping the association has no procedure
> > > > for recovery.
> > >
> > > The association will be aborted (and link taken out of
> > > service) only on EXCESSIVE congestion. A timer has ALREADY
> > > expired. This is the lifetime timer in SCTP.
> > >
> > > > The end-result of LPO versus dropping the
> > > > association has no differennce when the link fails as a result
> > > > of the outage.
> > >
> > > WRONG.
> >   ^^^^^  Hollering doesn't help.
> > >
> > > LPO causes time-controlled changeover.
> > > Out-of-service causes emergency changeover.
> > >
> > > Emergency changeover informs the peer of the bad link,
> > > preventing it from receiving MSUs out of order.
> > > Time controlled changeover does not.
> > 
> >         > Out-of-service causes emergency changeover.
> > 
> > This is not a correct statement, Jacob.  Please refer to Q.704.
> > Whether time-controlled changeover or regular changeover
> > procedures are used depends upon the configuration of the newtork.
> > If the signalling point is changing over to a signalling link
> > which terminates on an adjacent signalling point which is different
> > from the adjacent signalling point on the signalling link from
> > which it is changing over, time-controlled changeover procedures
> > are permitted (and preferred).
> 
> I see nothing in Q.704 to support this. You may be 
> misinterpreting this case of 5.6.2:
> 
>   i) No signalling path exists between the two ends of 
>      the unavailable link, so that the exchange
>      of changeover messages is impossible.

See Figure 11/Q.704, Section 5.2.2 c) and the paragraph at the bottom of
5.2.2 in either Q.704 or T1.111.4.  Where messages traverse an STP, normal
and emergency changeover procedures can cause mis-sequencing of messages
(they possible overtake messages on the other path).  In this case, normal
or emergency changeover procedures are "not desirable" as stated in 5.6.2 to
meet Q.706 objectives as stated in 5.2.2.

If you look at Figure 11/Q.704, you will see that it covers most situations
of changeover between link sets in a combined link set for networks in the
quasi-associated mode.

But 5.6.2 i) is also possible.  Even if in that case alone, your remote
MTP2's will continue merrily exchanging MSUs and the remote signalling point
will not even be made aware of the unavailability of the signalling route
unless you force the link down as well.

Your suggestion is directly in conflict with the situations 5.6.2 ii) and
5.6.2 iii).  Processor outage should never perform link failure.  Certainly
you can see that the failure of the SCTP association or management teardown
of the SCTP association is clearly a blocking and inhibiting condition.
Loss of the SCTP association, by whatever action, should be interpreted as
LPO.  If the SCTP association can be re-established and traffic and state
information audited and restarted under the T1 window, the SS7 link should
not have to be made to fail.  This is the purpose of the 5.6.2 procedures,
and the purpose of the T1 timer is to avoid the message mis-sequencing which
you claim will occur.

I see the only issue being that the state of the link at MTP3 and MTP2 must
be synchronized regardless of the intrusion of M2UA and SCTP in the midst.
This synchronization is quite possible; it is done all the time in protocols
which provide for it.

> 
> > 
> > Therefore, you cannot say, without considering the network
> > configuration, that this link failure will invoke emergency
> > changeover.  In the case where time-controlled changeover is
> > selected, the other end of the link will not be informed of the
> > failure and will merrily continue transfering messages in
> > both directions.
> > 
> > Because of this, one cannot get away from synchronizing the
> > view of the state of the link at both the ASP and SG sides.
> > If the ASP and SG loose the communication necessary to ensure
> > this synchronization, the only option provided for in conformance
> > with SS7 specifications is for both sides to view themselves
> > as having received a Local Processor Outage signal from
> > management.
> 
> 

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 8 Jun 2001 16:53:35 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: SCTP lifetime
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      QAA06959
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-213.dallas.net [209.44.42.213]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Jacob,

On Fri, 08 Jun 2001, Jacob Heitz wrote:

> "Brian F. G. Bidulock" wrote:
> > 
> > Jacob,
> > 
> > On Fri, 08 Jun 2001, Jacob Heitz wrote:
> > 
> > > This is also well documented in Q.703:
> > >
> > >   It should be noted that in the case that processor
> > >   outage is of "long term", i.e. when timer T1 in MTP
> > >   level 3 (see 16.8/Q.704) has expired, problems exist
> > >   with old messages, which are those messages
> > >   stored within level 2 buffers after the switch of
> > >   new traffic on the alternative link(s) has been
> > >   performed. This is because, in general, the level
> > >   2 buffers on both sides of the link contain some
> > >   MSUs. If normal operation of the link is resumed,
> > >   (re)transmission of these messages would result in
> > >   message missequencing. Furthermore, it is very
> > >   likely that these messages are related to calls that
> > >   have already been released or to network management
> > >   situations that have long since passed.
> > >
> > 
> > This is simply the rationale for MTP3 clearing buffers
> > when MTP2 recovered from processor outage.
> 
> It also says "problems exist with old messages" regardless
> of the "rationale".

Since you seem to have problems with this passage, read T1.111.4 where it
has been rewritten to avoid problems with old messages by clearing buffers.

> 
> > 
> > > When the path from MGC to SG congests, the MTP2 on the
> > > SG is very much alive and completely unaware of a problem.
> > > It is very able to send "old messages" that arrive from
> > > the congested M2UA. There is nothing the MGC can do
> > > about it. A FLUSH_BUFFERS message would take too long
> > > to get through and will be in line behind all the
> > > "old messages" anyway.
> > 
> > It can easily be made aware of the problem using ECN.
> > This is a responsibility of the underlying SCTP and
> > network implementation, not M2UA.
> 
> Then you must mandate that ECN be implemented and can
> ALWAYS get a message through. I can do without this
> impossible restriction.

No problem, acknowledge all messages M2UA peer to peer and end to end and
you will know when one got through.
It could be provided in M2UA protocol as well.  I proposed it with the use
of Corellation Id and Acks or the use of gap acking over cumulative acking
in SCTP.  This approach is necessary to resolve other buffer handling
problems.

You go do it the way you want, Jacob, but there is no need to force your
implementation view in the spec.

> 
> > 
> > >
> > > So, you see, it really doesn't matter what the precedent
> > > is. What matters is that these "old messages" will
> > > get delivered out of order once MTP3 does time-controlled
> > > changeover.
> > 
> > No they won't, not in my implementation.  Did you want
> > to send them in yours?
> 
> Then your implementation only works on a wire. It needs
> to work on an IP network where there is a chance that a
> message, any message, may be delayed. We engineer a network
> to make the chance of long delay low, but we must design 
> for the rare case when it happens.

Then your's won't work across the wire (the one from MTP2 to MTP2) which
exists for M2UA.

> 
> > 
> > >
> > > The draft might say "response to congestion is
> > > implementation dependent" and give some suggestions of
> > > what to do. It should also state that processor
> > > outage SHOULD NOT be signalled for the reason outlined
> > > above.
> > 
> > Certainly not.  It is a very usable approach which is
> > in full alignment with the existing MTP procedures.
> 
> No, it isn't. Processor outage is not an existing procedure
> for congestion between MTP2 and MTP3, because this interface
> has always been assumed to be "frictionless" to use your
> own term.

I said that it was "frictionless" in the SDLs, not in implementation.  In
real implementations internal congestion between link processor modules and
level 3 processor modules can commonly occur.  If you have ever been
involved in STP designs, you should know this.  Production STP's that I know
of never fail links just because there are swerring, losing MSUs on the
floor, or suffering interprocessor communication congestion.

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Balani, Sandeep" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2UA Message Inconsistency ....
Date: Fri, 8 Jun 2001 15:53:10 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: rumor.cps.intel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: rumor.cps.intel.com [192.102.198.242]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Ken,
 
In M2UA draft 7, section 5.3.8,which describes the Audit procedure for the
link from ASP to SG, there is an  " Establish Indication" message shown from
SG to ASP. This type of message is not existing in M2UA draft 7 at all. 

Thanks
Sandeep

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 8 Jun 2001 17:59:55 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA draft 7 questions (SCTP congestion at ASP)
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      RAA07692
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-213.dallas.net [209.44.42.213]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

On Fri, 08 Jun 2001, Ken Morneault wrote:
> 
> 
> All:
> 
> Here is the current suggested text for handling SCTP
> congestion.  Might as well get it right now, before the
> next version of the draft is sent out.

Thanks for sharing.  I might have been able to save you some time and
trouble in editing...

> 
> 1.5.5  Flow Control / Congestion
> 
> To minimize the possibility of congestion in the SCTP association, it 
> is recommended that the IP network be engineered to ensure the combined 
> bandwidth of all the MTP2 links served by that association.  However, 
> the possibility of congestion of the SCTP association exists.  The next 
> few paragraphs describe a suggestion on how an implementation may 
> temporarily reduce the flow of messages into the congested SCTP 
> association.

First, it is not always possible to economically engineer the bandwidth of
the SCTP associations to never congest, even if they are not suffering
failures.  This is because SS7 STPs may be (and many are) built to only use
L2 TB/RTB occupancy for congestion control.  The simple case is as follows:

                   +--------+
                   |        |     SCTP
         ----------|  STP   |M2UA ---- M2UA \[SG]
                 / |        |                \
         256    /  +--------+                 \
         B/D-links                             \ 1 A-link
              /                                 \
             /                                   \
            /                                     \

The STP is capable of focusing 256 Erlangs of traffic at the single M2UA
supported A-link.  In some circumstances (e.g, mass calling event) this will
occur in the normal network.
[Operators are prone to using call-gapping approaches in preference to
dedicate choke-groups nowadays because of the performance of the SS7
network.]

So, do I provision each of my SCTP associations to take 256/0.4 = 640
Erlangs of traffic?  Let's see, that would be about 40 Mb/s for each 64 kbps
link?  I think not.  I provision the SCTP association for 64 kbps or even
less.

The reason that I provision the SCTP association for less than 64 kbps is
quite simple: what does using M2UA provide for me that a normal A-link does
not?  The only thing that I can think of is that I want to reduce my SS7
link interconnect costs and TDM facility charges by placing a SPOI close to
the interconnect provider and backhauling over less expensive facilities.
Point to point facilities which guarantee 64kbps are bound to be as
expensive as normal TDM facilities.

A common case for the use of M2UA may be cases where the entire capacity of
an A-link is not necessary and the link will be backhauled over a network
with capacity which is less that that of the entire 56/64kbps link.

Given that there are a number of ways in which M2UA may be deployed, I don't
believe that the recommendation on SCTP association bandwidth provisioning
can stand.  SCTP association and the bandwidth provisioning is tied to the
provisioning of the underlying IP network and is as much outside the scope
of M2UA as it is outside the scope of SCTP.

>   
> It is possible for the M2UA layer to be informed of IP network 
> congestion onset and abatement by means of an implementation-dependent 
> function (i.e. an indication from the SCTP). 
> 
> The M2UA layer on the MGC will remember the last Congestion Indication 
> message it received from the SG.  If, at the MGC, SCTP indicates 
> congestion to M2UA, (that means SCTP transmission and retransmission 
> buffer fill exceeds a given congestion onset threshold) M2UA will send 
> the Link-Congested primitive to MTP3 for all affected MTP2 links.  The 
> level of congestion indicated shall be the highest possible.
> 

This is bad for a number of reasons, but particularly in network which
support multiple congestion levels with priority (such as, oh, ANSI).

Consider in the diagram above during an mass calling event where the local
radio station has inadvertently advertized $600 to the first 10,000 callers.
The A-link on the right of the diagram above goes to the switch which serves
the radio station.  The 256 B/D links on the left go to everyone in the
radio station's listening area.

100,000 people pick up the phone at 400 originating switches on the left and
dial the radio station on the right.  The 400 switches launch 100,000 IAMs
to the switch on the right.  The SCTP association drawn congests rapidly (in
well under a second).

According to this suggested procedure, M2UA at the STP will indicate
congestion level 3 to the STP.  The STP will then at some point launch 400
TFC's with congestion level 3 to the left.

Because the congestion level is level 3, the 400 switches on the left will
stop sending any messages to the radio station switch and will start
signalling route set congestion test procedures.
This includes all ISUP messages related to any other calls between the radio
station switch and the network, including REL and RST.  This will result in
the failure of all telephone calls to or from the radio station switch.
That is not a good idea.

Furthermore, if two SLTMs are sent during these congestion periods, the link
will be forced out of service, potentially isolating the radio station's
switch from the network.

In the normal SS7 case where there is no M2UA between MTP3 and MTP2, MTP2
would start walking up through the congestion levels.
Once the link had hit congestion level 1, all subsequent IAMs (which are
priority 0) would be discarded and TFC at congestion level 1 would be
signalled to the 400 switches on the left.  All subsequent new calls from
these switches would fail, however, existing calls between the two switches
would be ok.

Therefore, for use with ANSI and some other variants, you will need to place
appropriate onset, abatement, and discard thresholds in the SCTP and perform
proper Q.704 transmit congestion procedures.

> If, at the MGC, SCTP indicates congestion abatement to M2UA, (that means
> SCTP transmission and retransmission buffer fill falls below a given
> congestion abatement threshold) M2UA will send the Link-Congested 
> primitive or the Link-Congestion-ceased primitive to MTP3 for all 
> affected MTP2 links.  The level of congestion indicated shall be as 
> indicated in the last Congestion Indication message received from the 
> SG.

For abatement, it will be necessary to consider both the occupancy of the
SCTP `TB/RTB' and the MTP2 TB/RTB when considering what constitutes
abatement.

> 
> The SG will remember the last congestion status message it received 
> from the MGC (i.e. STATUS_CONG_ACCEPT, STATUS_CONG_DISCARD or 
> STATUS_CONG_CLEAR in the State Request message).  If, at the SG, SCTP 
> indicates congestion to M2UA and the last congestion status message 
> received from the MGC was STATUS_CONG_CLEAR M2UA will send the 
> Congestion-Accept primitive to MTP2.
> 
> If, at the SG, SCTP indicates congestion abatement to M2UA, M2UA will 
> send a congestion primitive to MTP2.  The level of congestion indicated 
> shall be as indicated in the last congestion status message received 
> from the MGC.
> 

In this direction you have it backwards.  The M2UA should signal
Congestion-Discard (the max) when it detects SCTP congestion.
This is because it has no assurances that the messages in the SCTP buffer
will ever reach MTP3.  This also means that MTP2 should stop delivering
received MSUs to M2UA according to Congestion-Discard procedures and it will
not further contribute to the SCTP congestion.

Also and in addition, it is very important that M2UA at the SG not deliver a
whole bunch of messages to SCTP which may never get delivered to MTP3.  M2UA
should interwork tightly with the MTP2 implementation to suppress the
acknowledgement of MSUs which have to yet been acknowledged by the M2UA
peer.
Otherwise, the MTP3 may be congested and MTP2 would never know about it.

--Brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Sat, 09 Jun 2001 14:09:42 -0700
From: Jacob Heitz <[email-masked]>
Organization: Lucent Technologies, Internetworking Systems, Software 
              Engineering, Alameda
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 i86pc)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: SCTP lifetime
X-SMTP-HELO: drawbridge.ascend.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: drawbridge.ascend.com [198.4.92.1]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

"Brian F. G. Bidulock" wrote:
> 
> Jacob,
> 
> On Fri, 08 Jun 2001, Jacob Heitz wrote:
> 
> > "Brian F. G. Bidulock" wrote:
> > >
> > > Jacob,
> > >
> > > On Fri, 08 Jun 2001, Jacob Heitz wrote:
> > >
> > > > This is also well documented in Q.703:
> > > >
> > > >   It should be noted that in the case that processor
> > > >   outage is of "long term", i.e. when timer T1 in MTP
> > > >   level 3 (see 16.8/Q.704) has expired, problems exist
> > > >   with old messages, which are those messages
> > > >   stored within level 2 buffers after the switch of
> > > >   new traffic on the alternative link(s) has been
> > > >   performed. This is because, in general, the level
> > > >   2 buffers on both sides of the link contain some
> > > >   MSUs. If normal operation of the link is resumed,
> > > >   (re)transmission of these messages would result in
> > > >   message missequencing. Furthermore, it is very
> > > >   likely that these messages are related to calls that
> > > >   have already been released or to network management
> > > >   situations that have long since passed.
> > > >
> > >
> > > This is simply the rationale for MTP3 clearing buffers
> > > when MTP2 recovered from processor outage.
> >
> > It also says "problems exist with old messages" regardless
> > of the "rationale".
> 
> Since you seem to have problems with this passage,
> read T1.111.4 where it has been rewritten to avoid
> problems with old messages by clearing buffers.

The SG does not know the messages are old. The MGC knows.
The link is congested. The MGC cannot get a message to the SG to tell it.

> 
> >
> > >
> > > > When the path from MGC to SG congests, the MTP2 on the
> > > > SG is very much alive and completely unaware of a problem.
> > > > It is very able to send "old messages" that arrive from
> > > > the congested M2UA. There is nothing the MGC can do
> > > > about it. A FLUSH_BUFFERS message would take too long
> > > > to get through and will be in line behind all the
> > > > "old messages" anyway.
> > >
> > > It can easily be made aware of the problem using ECN.
> > > This is a responsibility of the underlying SCTP and
> > > network implementation, not M2UA.
> >
> > Then you must mandate that ECN be implemented and can
> > ALWAYS get a message through. I can do without this
> > impossible restriction.
> 
> No problem, acknowledge all messages M2UA peer to peer
> and end to end and you will know when one got through.
> It could be provided in M2UA protocol as well.  I proposed
> it with the use of Corellation Id and Acks or the
> use of gap acking over cumulative acking in SCTP.  This
> approach is necessary to resolve other buffer handling
> problems.

This is irrelevant to congestion handling.

> 
> You go do it the way you want, Jacob, but there is no
> need to force your implementation view in the spec.
> 
> >
> > >
> > > >
> > > > So, you see, it really doesn't matter what the precedent
> > > > is. What matters is that these "old messages" will
> > > > get delivered out of order once MTP3 does time-controlled
> > > > changeover.
> > >
> > > No they won't, not in my implementation.  Did you want
> > > to send them in yours?
> >
> > Then your implementation only works on a wire. It needs
> > to work on an IP network where there is a chance that a
> > message, any message, may be delayed. We engineer a network
> > to make the chance of long delay low, but we must design
> > for the rare case when it happens.
> 
> Then your's won't work across the wire (the one from
> MTP2 to MTP2) which exists for M2UA.
> 
> >
> > >
> > > >
> > > > The draft might say "response to congestion is
> > > > implementation dependent" and give some suggestions of
> > > > what to do. It should also state that processor
> > > > outage SHOULD NOT be signalled for the reason outlined
> > > > above.
> > >
> > > Certainly not.  It is a very usable approach which is
> > > in full alignment with the existing MTP procedures.
> >
> > No, it isn't. Processor outage is not an existing procedure
> > for congestion between MTP2 and MTP3, because this interface
> > has always been assumed to be "frictionless" to use your
> > own term.
> 
> I said that it was "frictionless" in the SDLs, not in
> implementation.  In real implementations internal congestion
> between link processor modules and level 3 processor modules
> can commonly occur.  If you have ever been involved in STP
> designs, you should know this.  Production STP's that I know
> of never fail links just because there are swerring, losing
> MSUs on the floor, or suffering interprocessor communication
> congestion.

The MTP3-T1 timer assumes that by the time it expires, no old messages
capable of being delivered will exist in the system.
That is a reasonable assumption in most implementations of MTP. When MTP3
and MTP2 are separated by an IP network, this is no longer a reasonable
assumption. That is what makes processor-outage a dangerous response to
congestion on that IP network.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Sat, 09 Jun 2001 16:56:33 -0700
From: Jacob Heitz <[email-masked]>
Organization: Lucent Technologies, Internetworking Systems, Software 
              Engineering, Alameda
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 i86pc)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M2UA draft 7 questions (SCTP congestion at ASP)
X-SMTP-HELO: drawbridge.ascend.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: drawbridge.ascend.com [198.4.92.1]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Ken,

I think we are not going to agree on how to respond to congestion.
I suggest you make response to congestion indications implementation
dependent, but you keep the congestion indication messages from SG to MGC
and add congestion indication messages from MGC to SG.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Sat, 9 Jun 2001 19:05:50 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: SCTP lifetime
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      TAA24607
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-213.dallas.net [209.44.42.213]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Jacob,

On Sat, 09 Jun 2001, Jacob Heitz wrote:

> "Brian F. G. Bidulock" wrote:
> > 
> > Jacob,
> > 
> > On Fri, 08 Jun 2001, Jacob Heitz wrote:
> > 
> > > "Brian F. G. Bidulock" wrote:
> > > >
> > > > Jacob,
> > > >
> > > > On Fri, 08 Jun 2001, Jacob Heitz wrote:
> > > >
> > > > > This is also well documented in Q.703:
> > > > >
> > > > >   It should be noted that in the case that processor
> > > > >   outage is of "long term", i.e. when timer T1 in MTP
> > > > >   level 3 (see 16.8/Q.704) has expired, problems exist
> > > > >   with old messages, which are those messages
> > > > >   stored within level 2 buffers after the switch of
> > > > >   new traffic on the alternative link(s) has been
> > > > >   performed. This is because, in general, the level
> > > > >   2 buffers on both sides of the link contain some
> > > > >   MSUs. If normal operation of the link is resumed,
> > > > >   (re)transmission of these messages would result in
> > > > >   message missequencing. Furthermore, it is very
> > > > >   likely that these messages are related to calls that
> > > > >   have already been released or to network management
> > > > >   situations that have long since passed.
> > > > >
> > > >
> > > > This is simply the rationale for MTP3 clearing buffers
> > > > when MTP2 recovered from processor outage.
> > >
> > > It also says "problems exist with old messages" regardless
> > > of the "rationale".
> > 
> > Since you seem to have problems with this passage,
> > read T1.111.4 where it has been rewritten to avoid
> > problems with old messages by clearing buffers.
> 
> The SG does not know the messages are old. The MGC knows.
> The link is congested. The MGC cannot get a message to
> the SG to tell it.

It is the sending MTP Level 3 which needs to know that the messages are old,
because that's where the procedures are.

> 
> > 
> > >
> > > >
> > > > > When the path from MGC to SG congests, the MTP2 on the
> > > > > SG is very much alive and completely unaware of a problem.
> > > > > It is very able to send "old messages" that arrive from
> > > > > the congested M2UA. There is nothing the MGC can do
> > > > > about it. A FLUSH_BUFFERS message would take too long
> > > > > to get through and will be in line behind all the
> > > > > "old messages" anyway.
> > > >
> > > > It can easily be made aware of the problem using ECN.
> > > > This is a responsibility of the underlying SCTP and
> > > > network implementation, not M2UA.
> > >
> > > Then you must mandate that ECN be implemented and can
> > > ALWAYS get a message through. I can do without this
> > > impossible restriction.
> > 
> > No problem, acknowledge all messages M2UA peer to peer
> > and end to end and you will know when one got through.
> > It could be provided in M2UA protocol as well.  I proposed
> > it with the use of Corellation Id and Acks or the
> > use of gap acking over cumulative acking in SCTP.  This
> > approach is necessary to resolve other buffer handling
> > problems.
> 
> This is irrelevant to congestion handling.

Quite relevant, at that is what permits MTP Level 2 to know the age of
messages.  This would permit the MGC M2UA to know the age of the message as
you claim is necessary above.

> 
> > 
> > You go do it the way you want, Jacob, but there is no
> > need to force your implementation view in the spec.
> > 
> > >
> > > >
> > > > >
> > > > > So, you see, it really doesn't matter what the precedent
> > > > > is. What matters is that these "old messages" will
> > > > > get delivered out of order once MTP3 does time-controlled
> > > > > changeover.
> > > >
> > > > No they won't, not in my implementation.  Did you want
> > > > to send them in yours?
> > >
> > > Then your implementation only works on a wire. It needs
> > > to work on an IP network where there is a chance that a
> > > message, any message, may be delayed. We engineer a network
> > > to make the chance of long delay low, but we must design
> > > for the rare case when it happens.
> > 
> > Then your's won't work across the wire (the one from
> > MTP2 to MTP2) which exists for M2UA.
> > 
> > >
> > > >
> > > > >
> > > > > The draft might say "response to congestion is
> > > > > implementation dependent" and give some suggestions of
> > > > > what to do. It should also state that processor
> > > > > outage SHOULD NOT be signalled for the reason outlined
> > > > > above.
> > > >
> > > > Certainly not.  It is a very usable approach which is
> > > > in full alignment with the existing MTP procedures.
> > >
> > > No, it isn't. Processor outage is not an existing procedure
> > > for congestion between MTP2 and MTP3, because this interface
> > > has always been assumed to be "frictionless" to use your
> > > own term.
> > 
> > I said that it was "frictionless" in the SDLs, not in
> > implementation.  In real implementations internal congestion
> > between link processor modules and level 3 processor modules
> > can commonly occur.  If you have ever been involved in STP
> > designs, you should know this.  Production STP's that I know
> > of never fail links just because there are swerring, losing
> > MSUs on the floor, or suffering interprocessor communication
> > congestion.
> 
> The MTP3-T1 timer assumes that by the time it expires, no old
> messages capable of being delivered will exist in the system.
> That is a reasonable assumption in most implementations of
> MTP. When MTP3 and MTP2 are separated by an IP network, this
> is no longer a reasonable assumption. That is what makes
> processor-outage a dangerous response to congestion on that
> IP network.
> 

No, the MTP Level 3 know that old message have not been delivered, because
it knows that it can issue a clear buffers before transfer will resume from
MTP L2 peer to L2 peer.  It is not an assumption, it is how it is designed.
Separating MTP3 and MTP2 by an IP network does not necessitate procedural
changes in MTP as you propose.  Processor outage reduces mis-sequencing by
reducing the number of spurious changeovers, particularly in quasi-
associated mode.

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Sat, 09 Jun 2001 17:39:35 -0700
From: Jacob Heitz <[email-masked]>
Organization: Lucent Technologies, Internetworking Systems, Software 
              Engineering, Alameda
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 i86pc)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: SCTP lifetime
X-SMTP-HELO: drawbridge.ascend.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: drawbridge.ascend.com [198.4.92.1]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

"Brian F. G. Bidulock" wrote:
> 
> Jacob,
> 
> On Sat, 09 Jun 2001, Jacob Heitz wrote:
> 
> > "Brian F. G. Bidulock" wrote:
> > >
> > > Jacob,
> > >
> > > On Fri, 08 Jun 2001, Jacob Heitz wrote:
> > >
> > > > "Brian F. G. Bidulock" wrote:
> > > > >
> > > > > Jacob,
> > > > >
> > > > > On Fri, 08 Jun 2001, Jacob Heitz wrote:
> > > > >
> > > > > > This is also well documented in Q.703:
> > > > > >
> > > > > >   It should be noted that in the case that processor
> > > > > >   outage is of "long term", i.e. when timer T1 in MTP
> > > > > >   level 3 (see 16.8/Q.704) has expired, problems exist
> > > > > >   with old messages, which are those messages
> > > > > >   stored within level 2 buffers after the switch of
> > > > > >   new traffic on the alternative link(s) has been
> > > > > >   performed. This is because, in general, the level
> > > > > >   2 buffers on both sides of the link contain some
> > > > > >   MSUs. If normal operation of the link is resumed,
> > > > > >   (re)transmission of these messages would result in
> > > > > >   message missequencing. Furthermore, it is very
> > > > > >   likely that these messages are related to calls that
> > > > > >   have already been released or to network management
> > > > > >   situations that have long since passed.
> > > > > >
> > > > >
> > > > > This is simply the rationale for MTP3 clearing buffers
> > > > > when MTP2 recovered from processor outage.
> > > >
> > > > It also says "problems exist with old messages" regardless
> > > > of the "rationale".
> > >
> > > Since you seem to have problems with this passage,
> > > read T1.111.4 where it has been rewritten to avoid
> > > problems with old messages by clearing buffers.
> >
> > The SG does not know the messages are old. The MGC knows.
> > The link is congested. The MGC cannot get a message to
> > the SG to tell it.
> 
> It is the sending MTP Level 3 which needs to know that
> the messages are old, because that's where the procedures
> are.

It is the sending MTP2 that needs to know the messages are old, because that
is who will send them if he doesn't know.
Best of all, the receiving MTP should know that the messages are old.
Time-controlled changeover does not tell the receiving end. Emergency (and
normal) changeover does.

> 
> >
> > >
> > > >
> > > > >
> > > > > > When the path from MGC to SG congests, the MTP2 on the
> > > > > > SG is very much alive and completely unaware of a problem.
> > > > > > It is very able to send "old messages" that arrive from
> > > > > > the congested M2UA. There is nothing the MGC can do
> > > > > > about it. A FLUSH_BUFFERS message would take too long
> > > > > > to get through and will be in line behind all the
> > > > > > "old messages" anyway.
> > > > >
> > > > > It can easily be made aware of the problem using ECN.
> > > > > This is a responsibility of the underlying SCTP and
> > > > > network implementation, not M2UA.
> > > >
> > > > Then you must mandate that ECN be implemented and can
> > > > ALWAYS get a message through. I can do without this
> > > > impossible restriction.
> > >
> > > No problem, acknowledge all messages M2UA peer to peer
> > > and end to end and you will know when one got through.
> > > It could be provided in M2UA protocol as well.  I proposed
> > > it with the use of Corellation Id and Acks or the
> > > use of gap acking over cumulative acking in SCTP.  This
> > > approach is necessary to resolve other buffer handling
> > > problems.
> >
> > This is irrelevant to congestion handling.
> 
> Quite relevant, at that is what permits MTP Level 2 to
> know the age of messages.  This would permit the MGC M2UA
> to know the age of the message as you claim is necessary
> above.

The age of a message does not determine whether it is too old or not. "Too
old" means than MTP3 is about to transmit newer messages on an alternate
link and those will arrive at the receiving end before the "too old"
messages. The only one that can know that for sure is the receiving end.
Time-controlled changeover, initiated by processor outage, does not inform
the receiving end.

> 
> >
> > >
> > > You go do it the way you want, Jacob, but there is no
> > > need to force your implementation view in the spec.
> > >
> > > >
> > > > >
> > > > > >
> > > > > > So, you see, it really doesn't matter what the precedent
> > > > > > is. What matters is that these "old messages" will
> > > > > > get delivered out of order once MTP3 does time-controlled
> > > > > > changeover.
> > > > >
> > > > > No they won't, not in my implementation.  Did you want
> > > > > to send them in yours?
> > > >
> > > > Then your implementation only works on a wire. It needs
> > > > to work on an IP network where there is a chance that a
> > > > message, any message, may be delayed. We engineer a network
> > > > to make the chance of long delay low, but we must design
> > > > for the rare case when it happens.
> > >
> > > Then your's won't work across the wire (the one from
> > > MTP2 to MTP2) which exists for M2UA.
> > >
> > > >
> > > > >
> > > > > >
> > > > > > The draft might say "response to congestion is
> > > > > > implementation dependent" and give some suggestions of
> > > > > > what to do. It should also state that processor
> > > > > > outage SHOULD NOT be signalled for the reason outlined
> > > > > > above.
> > > > >
> > > > > Certainly not.  It is a very usable approach which is
> > > > > in full alignment with the existing MTP procedures.
> > > >
> > > > No, it isn't. Processor outage is not an existing procedure
> > > > for congestion between MTP2 and MTP3, because this interface
> > > > has always been assumed to be "frictionless" to use your
> > > > own term.
> > >
> > > I said that it was "frictionless" in the SDLs, not in
> > > implementation.  In real implementations internal congestion
> > > between link processor modules and level 3 processor modules
> > > can commonly occur.  If you have ever been involved in STP
> > > designs, you should know this.  Production STP's that I know
> > > of never fail links just because there are swerring, losing
> > > MSUs on the floor, or suffering interprocessor communication
> > > congestion.
> >
> > The MTP3-T1 timer assumes that by the time it expires, no old
> > messages capable of being delivered will exist in the system.
> > That is a reasonable assumption in most implementations of
> > MTP. When MTP3 and MTP2 are separated by an IP network, this
> > is no longer a reasonable assumption. That is what makes
> > processor-outage a dangerous response to congestion on that
> > IP network.
> >
> 
> No, the MTP Level 3 know that old message have not been delivered,
> because it knows that it can issue a clear buffers before transfer
> will resume from MTP L2 peer to L2 peer. 

The "clear buffers" needs to reach the MTP2 on the other side of a congested
SCTP association before the MTP2 of the new link starts sending. You cannot
be sure that will happen.

> It is not an assumption,
> it is how it is designed.  Separating MTP3 and MTP2 by an IP
> network does not necessitate procedural changes in MTP as you
> propose.  Processor outage reduces mis-sequencing by reducing
> the number of spurious changeovers, particularly in quasi-
> associated mode.

Time-controlled changeovers, initiated by processor outage, cause
mis-sequencing.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Sat, 9 Jun 2001 22:09:15 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: SCTP lifetime
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      WAA26484
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-213.dallas.net [209.44.42.213]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Jacob,

On Sat, 09 Jun 2001, Jacob Heitz wrote:

> "Brian F. G. Bidulock" wrote:
> > 
> > Jacob,
> > 
> > On Sat, 09 Jun 2001, Jacob Heitz wrote:
> > 
> > > "Brian F. G. Bidulock" wrote:
> > > >
> > > > Jacob,
> > > >
> > > > On Fri, 08 Jun 2001, Jacob Heitz wrote:
> > > >
> > > > > "Brian F. G. Bidulock" wrote:
> > > > > >
> > > > > > Jacob,
> > > > > >
> > > > > > On Fri, 08 Jun 2001, Jacob Heitz wrote:
> > > > > >
> > > > > > > This is also well documented in Q.703:
> > > > > > >
> > > > > > >   It should be noted that in the case that processor
> > > > > > >   outage is of "long term", i.e. when timer T1 in MTP
> > > > > > >   level 3 (see 16.8/Q.704) has expired, problems exist
> > > > > > >   with old messages, which are those messages
> > > > > > >   stored within level 2 buffers after the switch of
> > > > > > >   new traffic on the alternative link(s) has been
> > > > > > >   performed. This is because, in general, the level
> > > > > > >   2 buffers on both sides of the link contain some
> > > > > > >   MSUs. If normal operation of the link is resumed,
> > > > > > >   (re)transmission of these messages would result in
> > > > > > >   message missequencing. Furthermore, it is very
> > > > > > >   likely that these messages are related to calls that
> > > > > > >   have already been released or to network management
> > > > > > >   situations that have long since passed.
> > > > > > >
> > > > > >
> > > > > > This is simply the rationale for MTP3 clearing buffers
> > > > > > when MTP2 recovered from processor outage.
> > > > >
> > > > > It also says "problems exist with old messages" regardless
> > > > > of the "rationale".
> > > >
> > > > Since you seem to have problems with this passage,
> > > > read T1.111.4 where it has been rewritten to avoid
> > > > problems with old messages by clearing buffers.
> > >
> > > The SG does not know the messages are old. The MGC knows.
> > > The link is congested. The MGC cannot get a message to
> > > the SG to tell it.
> > 
> > It is the sending MTP Level 3 which needs to know that
> > the messages are old, because that's where the procedures
> > are.
> 
> It is the sending MTP2 that needs to know the messages are
> old, because that is who will send them if he doesn't know.
> Best of all, the receiving MTP should know that the messages
> are old. Time-controlled changeover does not tell the
> receiving end. Emergency (and normal) changeover does.

It is the sending MTP2 knows not to send them because it is in Processor
Outage.  The sending MTP3 knows to clear them before telling the sending
MTP2 to recover from LPO.

Neither emergency (nor normal) changeover inform the other end in all cases.

> 
> > 
> > >
> > > >
> > > > >
> > > > > >
> > > > > > > When the path from MGC to SG congests, the MTP2 on the
> > > > > > > SG is very much alive and completely unaware of a problem.
> > > > > > > It is very able to send "old messages" that arrive from
> > > > > > > the congested M2UA. There is nothing the MGC can do
> > > > > > > about it. A FLUSH_BUFFERS message would take too long
> > > > > > > to get through and will be in line behind all the
> > > > > > > "old messages" anyway.
> > > > > >
> > > > > > It can easily be made aware of the problem using ECN.
> > > > > > This is a responsibility of the underlying SCTP and
> > > > > > network implementation, not M2UA.
> > > > >
> > > > > Then you must mandate that ECN be implemented and can
> > > > > ALWAYS get a message through. I can do without this
> > > > > impossible restriction.
> > > >
> > > > No problem, acknowledge all messages M2UA peer to peer
> > > > and end to end and you will know when one got through.
> > > > It could be provided in M2UA protocol as well.  I proposed
> > > > it with the use of Corellation Id and Acks or the
> > > > use of gap acking over cumulative acking in SCTP.  This
> > > > approach is necessary to resolve other buffer handling
> > > > problems.
> > >
> > > This is irrelevant to congestion handling.
> > 
> > Quite relevant, at that is what permits MTP Level 2 to
> > know the age of messages.  This would permit the MGC M2UA
> > to know the age of the message as you claim is necessary
> > above.
> 
> The age of a message does not determine whether it is too
> old or not. "Too old" means than MTP3 is about to transmit
> newer messages on an alternate link and those will arrive
> at the receiving end before the "too old" messages. The only
> one that can know that for sure is the receiving end.
> Time-controlled changeover, initiated by processor outage,
> does not inform the receiving end.

That is why MTP3 clears them before sending on an alternate link set using
the time-controlled procedure.  It is not necessary to inform the receiving
end because the link will have already failed due to the same timer values
being used at the peer MTP3.

> 
> > 
> > >
> > > >
> > > > You go do it the way you want, Jacob, but there is no
> > > > need to force your implementation view in the spec.
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > So, you see, it really doesn't matter what the precedent
> > > > > > > is. What matters is that these "old messages" will
> > > > > > > get delivered out of order once MTP3 does time-controlled
> > > > > > > changeover.
> > > > > >
> > > > > > No they won't, not in my implementation.  Did you want
> > > > > > to send them in yours?
> > > > >
> > > > > Then your implementation only works on a wire. It needs
> > > > > to work on an IP network where there is a chance that a
> > > > > message, any message, may be delayed. We engineer a network
> > > > > to make the chance of long delay low, but we must design
> > > > > for the rare case when it happens.
> > > >
> > > > Then your's won't work across the wire (the one from
> > > > MTP2 to MTP2) which exists for M2UA.
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > The draft might say "response to congestion is
> > > > > > > implementation dependent" and give some suggestions of
> > > > > > > what to do. It should also state that processor
> > > > > > > outage SHOULD NOT be signalled for the reason outlined
> > > > > > > above.
> > > > > >
> > > > > > Certainly not.  It is a very usable approach which is
> > > > > > in full alignment with the existing MTP procedures.
> > > > >
> > > > > No, it isn't. Processor outage is not an existing procedure
> > > > > for congestion between MTP2 and MTP3, because this interface
> > > > > has always been assumed to be "frictionless" to use your
> > > > > own term.
> > > >
> > > > I said that it was "frictionless" in the SDLs, not in
> > > > implementation.  In real implementations internal congestion
> > > > between link processor modules and level 3 processor modules
> > > > can commonly occur.  If you have ever been involved in STP
> > > > designs, you should know this.  Production STP's that I know
> > > > of never fail links just because there are swerring, losing
> > > > MSUs on the floor, or suffering interprocessor communication
> > > > congestion.
> > >
> > > The MTP3-T1 timer assumes that by the time it expires, no old
> > > messages capable of being delivered will exist in the system.
> > > That is a reasonable assumption in most implementations of
> > > MTP. When MTP3 and MTP2 are separated by an IP network, this
> > > is no longer a reasonable assumption. That is what makes
> > > processor-outage a dangerous response to congestion on that
> > > IP network.
> > >
> > 
> > No, the MTP Level 3 know that old message have not been delivered,
> > because it knows that it can issue a clear buffers before transfer
> > will resume from MTP L2 peer to L2 peer. 
> 
> The "clear buffers" needs to reach the MTP2 on the other side
> of a congested SCTP association before the MTP2 of the new
> link starts sending. You cannot be sure that will happen.

Sure you can.  The MTP2 being in LPO does not send messages until the SCTP
association congestion ceases and it receives a resume (after, possiblu,  a
clear buffers) from the MTP3.

> 
> > It is not an assumption,
> > it is how it is designed.  Separating MTP3 and MTP2 by an IP
> > network does not necessitate procedural changes in MTP as you
> > propose.  Processor outage reduces mis-sequencing by reducing
> > the number of spurious changeovers, particularly in quasi-
> > associated mode.
> 
> Time-controlled changeovers, initiated by processor outage, 
> cause mis-sequencing.

No, time-controlled changeover is, as stated in the standard, a procedure to
prevent mis-sequencing.  The only situation cited in which mis-sequencing
can occur is during normal or emergency changeover in the quasi-associated
mode.

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Sat, 09 Jun 2001 20:43:42 -0700
From: Jacob Heitz <[email-masked]>
Organization: Lucent Technologies, Internetworking Systems, Software 
              Engineering, Alameda
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: SCTP lifetime
X-SMTP-HELO: drawbridge.ascend.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: drawbridge.ascend.com [198.4.92.1]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

"Brian F. G. Bidulock" wrote:
> 
> Jacob,
> 
> On Sat, 09 Jun 2001, Jacob Heitz wrote:
> 
> > "Brian F. G. Bidulock" wrote:
> > >
> > > Jacob,
> > >
> > > On Sat, 09 Jun 2001, Jacob Heitz wrote:
> > >
> > > > "Brian F. G. Bidulock" wrote:
> > > > >
> > > > > Jacob,
> > > > >
> > > > > On Fri, 08 Jun 2001, Jacob Heitz wrote:
> > > > >
> > > > > > "Brian F. G. Bidulock" wrote:
> > > > > > >
> > > > > > > Jacob,
> > > > > > >
> > > > > > > On Fri, 08 Jun 2001, Jacob Heitz wrote:
> > > > > > >
> > > > > > > > This is also well documented in Q.703:
> > > > > > > >
> > > > > > > >   It should be noted that in the case that processor
> > > > > > > >   outage is of "long term", i.e. when timer T1 in MTP
> > > > > > > >   level 3 (see 16.8/Q.704) has expired, problems exist
> > > > > > > >   with old messages, which are those messages
> > > > > > > >   stored within level 2 buffers after the switch of
> > > > > > > >   new traffic on the alternative link(s) has been
> > > > > > > >   performed. This is because, in general, the level
> > > > > > > >   2 buffers on both sides of the link contain some
> > > > > > > >   MSUs. If normal operation of the link is resumed,
> > > > > > > >   (re)transmission of these messages would result in
> > > > > > > >   message missequencing. Furthermore, it is very
> > > > > > > >   likely that these messages are related to calls that
> > > > > > > >   have already been released or to network management
> > > > > > > >   situations that have long since passed.
> > > > > > > >
> > > > > > >
> > > > > > > This is simply the rationale for MTP3 clearing buffers
> > > > > > > when MTP2 recovered from processor outage.
> > > > > >
> > > > > > It also says "problems exist with old messages" regardless
> > > > > > of the "rationale".
> > > > >
> > > > > Since you seem to have problems with this passage,
> > > > > read T1.111.4 where it has been rewritten to avoid
> > > > > problems with old messages by clearing buffers.
> > > >
> > > > The SG does not know the messages are old. The MGC knows.
> > > > The link is congested. The MGC cannot get a message to
> > > > the SG to tell it.
> > >
> > > It is the sending MTP Level 3 which needs to know that
> > > the messages are old, because that's where the procedures
> > > are.
> >
> > It is the sending MTP2 that needs to know the messages are
> > old, because that is who will send them if he doesn't know.
> > Best of all, the receiving MTP should know that the messages
> > are old. Time-controlled changeover does not tell the
> > receiving end. Emergency (and normal) changeover does.
> 
> It is the sending MTP2 knows not to send them because it
> is in Processor Outage.  The sending MTP3 knows to clear
> them before telling the sending MTP2 to recover from LPO.

It is not in processor outage. We've been over this before.
Congestion does not occur in both directions at the same time in general. In
the previous threads, the consensus agrees with this.

> 
> Neither emergency (nor normal) changeover inform the
> other end in all cases.

Time-controlled changeover never informs. Emergency changeover sends ECO.
Normal changeover sends COO.
I call that informing.

> 
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > > When the path from MGC to SG congests, the MTP2 on the
> > > > > > > > SG is very much alive and completely unaware of a problem.
> > > > > > > > It is very able to send "old messages" that arrive from
> > > > > > > > the congested M2UA. There is nothing the MGC can do
> > > > > > > > about it. A FLUSH_BUFFERS message would take too long
> > > > > > > > to get through and will be in line behind all the
> > > > > > > > "old messages" anyway.
> > > > > > >
> > > > > > > It can easily be made aware of the problem using ECN.
> > > > > > > This is a responsibility of the underlying SCTP and
> > > > > > > network implementation, not M2UA.
> > > > > >
> > > > > > Then you must mandate that ECN be implemented and can
> > > > > > ALWAYS get a message through. I can do without this
> > > > > > impossible restriction.
> > > > >
> > > > > No problem, acknowledge all messages M2UA peer to peer
> > > > > and end to end and you will know when one got through.
> > > > > It could be provided in M2UA protocol as well.  I proposed
> > > > > it with the use of Corellation Id and Acks or the
> > > > > use of gap acking over cumulative acking in SCTP.  This
> > > > > approach is necessary to resolve other buffer handling
> > > > > problems.
> > > >
> > > > This is irrelevant to congestion handling.
> > >
> > > Quite relevant, at that is what permits MTP Level 2 to
> > > know the age of messages.  This would permit the MGC M2UA
> > > to know the age of the message as you claim is necessary
> > > above.
> >
> > The age of a message does not determine whether it is too
> > old or not. "Too old" means than MTP3 is about to transmit
> > newer messages on an alternate link and those will arrive
> > at the receiving end before the "too old" messages. The only
> > one that can know that for sure is the receiving end.
> > Time-controlled changeover, initiated by processor outage,
> > does not inform the receiving end.
> 
> That is why MTP3 clears them before sending on an alternate
> link set using the time-controlled procedure.  It is not
> necessary to inform the receiving end because the link will
> have already failed due to the same timer values being used
> at the peer MTP3.

The link will not fail at the other end at the same time in general. Again,
we'we been over this.

> 
> >
> > >
> > > >
> > > > >
> > > > > You go do it the way you want, Jacob, but there is no
> > > > > need to force your implementation view in the spec.
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > So, you see, it really doesn't matter what the precedent
> > > > > > > > is. What matters is that these "old messages" will
> > > > > > > > get delivered out of order once MTP3 does time-controlled
> > > > > > > > changeover.
> > > > > > >
> > > > > > > No they won't, not in my implementation.  Did you want
> > > > > > > to send them in yours?
> > > > > >
> > > > > > Then your implementation only works on a wire. It needs
> > > > > > to work on an IP network where there is a chance that a
> > > > > > message, any message, may be delayed. We engineer a network
> > > > > > to make the chance of long delay low, but we must design
> > > > > > for the rare case when it happens.
> > > > >
> > > > > Then your's won't work across the wire (the one from
> > > > > MTP2 to MTP2) which exists for M2UA.
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > The draft might say "response to congestion is
> > > > > > > > implementation dependent" and give some suggestions of
> > > > > > > > what to do. It should also state that processor
> > > > > > > > outage SHOULD NOT be signalled for the reason outlined
> > > > > > > > above.
> > > > > > >
> > > > > > > Certainly not.  It is a very usable approach which is
> > > > > > > in full alignment with the existing MTP procedures.
> > > > > >
> > > > > > No, it isn't. Processor outage is not an existing procedure
> > > > > > for congestion between MTP2 and MTP3, because this interface
> > > > > > has always been assumed to be "frictionless" to use your
> > > > > > own term.
> > > > >
> > > > > I said that it was "frictionless" in the SDLs, not in
> > > > > implementation.  In real implementations internal congestion
> > > > > between link processor modules and level 3 processor modules
> > > > > can commonly occur.  If you have ever been involved in STP
> > > > > designs, you should know this.  Production STP's that I know
> > > > > of never fail links just because there are swerring, losing
> > > > > MSUs on the floor, or suffering interprocessor communication
> > > > > congestion.
> > > >
> > > > The MTP3-T1 timer assumes that by the time it expires, no old
> > > > messages capable of being delivered will exist in the system.
> > > > That is a reasonable assumption in most implementations of
> > > > MTP. When MTP3 and MTP2 are separated by an IP network, this
> > > > is no longer a reasonable assumption. That is what makes
> > > > processor-outage a dangerous response to congestion on that
> > > > IP network.
> > > >
> > >
> > > No, the MTP Level 3 know that old message have not been delivered,
> > > because it knows that it can issue a clear buffers before transfer
> > > will resume from MTP L2 peer to L2 peer.
> >
> > The "clear buffers" needs to reach the MTP2 on the other side
> > of a congested SCTP association before the MTP2 of the new
> > link starts sending. You cannot be sure that will happen.
> 
> Sure you can.  The MTP2 being in LPO does not send messages until
> the SCTP association congestion ceases and it receives a resume
> (after, possiblu,  a clear buffers) from the MTP3.

The MTP2 is not in LPO. See previous comments.

> 
> >
> > > It is not an assumption,
> > > it is how it is designed.  Separating MTP3 and MTP2 by an IP
> > > network does not necessitate procedural changes in MTP as you
> > > propose.  Processor outage reduces mis-sequencing by reducing
> > > the number of spurious changeovers, particularly in quasi-
> > > associated mode.
> >
> > Time-controlled changeovers, initiated by processor outage,
> > cause mis-sequencing.
> 
> No, time-controlled changeover is, as stated in the standard,
> a procedure to prevent mis-sequencing. 

Please copy us the statement in the standard.

Section 5.6.2 of Q.704 even says this:

  If time-controlled changeover has been initiated 
  according to case ii) above and if a changeover order
  is received from the remote and during the Time 
  T1, it is advantageous to switch to the normal
  changeover procedure including retrieval because 
  unnecessary message loss or sending of old
  messages is avoided in a simple way.

"case ii) above" is the initiation of time-controlled changeover due to
processor outage.

This implies that normal changeover is preferrable, because it avoids
sending of old messages that time-controlled changeover may cause.

> The only situation cited
> in which mis-sequencing can occur is during normal or emergency
> changeover in the quasi-associated mode.

Please quote the citation.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Sat, 9 Jun 2001 23:36:16 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: SCTP lifetime
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      XAA27323
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-213.dallas.net [209.44.42.213]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Jacob,

On Sat, 09 Jun 2001, Jacob Heitz wrote:

> "Brian F. G. Bidulock" wrote:
> > 
> > Jacob,
> > 
> > On Sat, 09 Jun 2001, Jacob Heitz wrote:
> > 
> > > "Brian F. G. Bidulock" wrote:
> > > >
> > > > Jacob,
> > > >
> > > > On Sat, 09 Jun 2001, Jacob Heitz wrote:
> > > >
> > > > > "Brian F. G. Bidulock" wrote:
> > > > > >
> > > > > > Jacob,
> > > > > >
> > > > > > On Fri, 08 Jun 2001, Jacob Heitz wrote:
> > > > > >
> > > > > > > "Brian F. G. Bidulock" wrote:
> > > > > > > >
> > > > > > > > Jacob,
> > > > > > > >
> > > > > > > > On Fri, 08 Jun 2001, Jacob Heitz wrote:
> > > > > > > >
> > > > > > > > > This is also well documented in Q.703:
> > > > > > > > >
> > > > > > > > >   It should be noted that in the case that processor
> > > > > > > > >   outage is of "long term", i.e. when timer T1 in MTP
> > > > > > > > >   level 3 (see 16.8/Q.704) has expired, problems exist
> > > > > > > > >   with old messages, which are those messages
> > > > > > > > >   stored within level 2 buffers after the switch of
> > > > > > > > >   new traffic on the alternative link(s) has been
> > > > > > > > >   performed. This is because, in general, the level
> > > > > > > > >   2 buffers on both sides of the link contain some
> > > > > > > > >   MSUs. If normal operation of the link is resumed,
> > > > > > > > >   (re)transmission of these messages would result in
> > > > > > > > >   message missequencing. Furthermore, it is very
> > > > > > > > >   likely that these messages are related to calls that
> > > > > > > > >   have already been released or to network management
> > > > > > > > >   situations that have long since passed.
> > > > > > > > >
> > > > > > > >
> > > > > > > > This is simply the rationale for MTP3 clearing buffers
> > > > > > > > when MTP2 recovered from processor outage.
> > > > > > >
> > > > > > > It also says "problems exist with old messages" regardless
> > > > > > > of the "rationale".
> > > > > >
> > > > > > Since you seem to have problems with this passage,
> > > > > > read T1.111.4 where it has been rewritten to avoid
> > > > > > problems with old messages by clearing buffers.
> > > > >
> > > > > The SG does not know the messages are old. The MGC knows.
> > > > > The link is congested. The MGC cannot get a message to
> > > > > the SG to tell it.
> > > >
> > > > It is the sending MTP Level 3 which needs to know that
> > > > the messages are old, because that's where the procedures
> > > > are.
> > >
> > > It is the sending MTP2 that needs to know the messages are
> > > old, because that is who will send them if he doesn't know.
> > > Best of all, the receiving MTP should know that the messages
> > > are old. Time-controlled changeover does not tell the
> > > receiving end. Emergency (and normal) changeover does.
> > 
> > It is the sending MTP2 knows not to send them because it
> > is in Processor Outage.  The sending MTP3 knows to clear
> > them before telling the sending MTP2 to recover from LPO.
> 
> It is not in processor outage. We've been over this before.
> Congestion does not occur in both directions at the same
> time in general. In the previous threads, the consensus
> agrees with this.

It can be made to detect in both directions at the same time with an M2UA to
M2UA peer ack.  There are several algorithms which can accomplish this.

> 
> > 
> > Neither emergency (nor normal) changeover inform the
> > other end in all cases.
> 
> Time-controlled changeover never informs. Emergency
> changeover sends ECO. Normal changeover sends COO.
> I call that informing.

Not if it cannot reach the other side.

> 
> > 
> > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > > When the path from MGC to SG congests, the MTP2 on the
> > > > > > > > > SG is very much alive and completely unaware of a problem.
> > > > > > > > > It is very able to send "old messages" that arrive from
> > > > > > > > > the congested M2UA. There is nothing the MGC can do
> > > > > > > > > about it. A FLUSH_BUFFERS message would take too long
> > > > > > > > > to get through and will be in line behind all the
> > > > > > > > > "old messages" anyway.
> > > > > > > >
> > > > > > > > It can easily be made aware of the problem using ECN.
> > > > > > > > This is a responsibility of the underlying SCTP and
> > > > > > > > network implementation, not M2UA.
> > > > > > >
> > > > > > > Then you must mandate that ECN be implemented and can
> > > > > > > ALWAYS get a message through. I can do without this
> > > > > > > impossible restriction.
> > > > > >
> > > > > > No problem, acknowledge all messages M2UA peer to peer
> > > > > > and end to end and you will know when one got through.
> > > > > > It could be provided in M2UA protocol as well.  I proposed
> > > > > > it with the use of Corellation Id and Acks or the
> > > > > > use of gap acking over cumulative acking in SCTP.  This
> > > > > > approach is necessary to resolve other buffer handling
> > > > > > problems.
> > > > >
> > > > > This is irrelevant to congestion handling.
> > > >
> > > > Quite relevant, at that is what permits MTP Level 2 to
> > > > know the age of messages.  This would permit the MGC M2UA
> > > > to know the age of the message as you claim is necessary
> > > > above.
> > >
> > > The age of a message does not determine whether it is too
> > > old or not. "Too old" means than MTP3 is about to transmit
> > > newer messages on an alternate link and those will arrive
> > > at the receiving end before the "too old" messages. The only
> > > one that can know that for sure is the receiving end.
> > > Time-controlled changeover, initiated by processor outage,
> > > does not inform the receiving end.
> > 
> > That is why MTP3 clears them before sending on an alternate
> > link set using the time-controlled procedure.  It is not
> > necessary to inform the receiving end because the link will
> > have already failed due to the same timer values being used
> > at the peer MTP3.
> 
> The link will not fail at the other end at the same time
> in general. Again, we'we been over this.

Yes, because it will be informed of processor outage via SIPO and run the
same timer.

> 
> > 
> > >
> > > >
> > > > >
> > > > > >
> > > > > > You go do it the way you want, Jacob, but there is no
> > > > > > need to force your implementation view in the spec.
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > So, you see, it really doesn't matter what the precedent
> > > > > > > > > is. What matters is that these "old messages" will
> > > > > > > > > get delivered out of order once MTP3 does time-controlled
> > > > > > > > > changeover.
> > > > > > > >
> > > > > > > > No they won't, not in my implementation.  Did you want
> > > > > > > > to send them in yours?
> > > > > > >
> > > > > > > Then your implementation only works on a wire. It needs
> > > > > > > to work on an IP network where there is a chance that a
> > > > > > > message, any message, may be delayed. We engineer a network
> > > > > > > to make the chance of long delay low, but we must design
> > > > > > > for the rare case when it happens.
> > > > > >
> > > > > > Then your's won't work across the wire (the one from
> > > > > > MTP2 to MTP2) which exists for M2UA.
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > The draft might say "response to congestion is
> > > > > > > > > implementation dependent" and give some suggestions of
> > > > > > > > > what to do. It should also state that processor
> > > > > > > > > outage SHOULD NOT be signalled for the reason outlined
> > > > > > > > > above.
> > > > > > > >
> > > > > > > > Certainly not.  It is a very usable approach which is
> > > > > > > > in full alignment with the existing MTP procedures.
> > > > > > >
> > > > > > > No, it isn't. Processor outage is not an existing procedure
> > > > > > > for congestion between MTP2 and MTP3, because this interface
> > > > > > > has always been assumed to be "frictionless" to use your
> > > > > > > own term.
> > > > > >
> > > > > > I said that it was "frictionless" in the SDLs, not in
> > > > > > implementation.  In real implementations internal congestion
> > > > > > between link processor modules and level 3 processor modules
> > > > > > can commonly occur.  If you have ever been involved in STP
> > > > > > designs, you should know this.  Production STP's that I know
> > > > > > of never fail links just because there are swerring, losing
> > > > > > MSUs on the floor, or suffering interprocessor communication
> > > > > > congestion.
> > > > >
> > > > > The MTP3-T1 timer assumes that by the time it expires, no old
> > > > > messages capable of being delivered will exist in the system.
> > > > > That is a reasonable assumption in most implementations of
> > > > > MTP. When MTP3 and MTP2 are separated by an IP network, this
> > > > > is no longer a reasonable assumption. That is what makes
> > > > > processor-outage a dangerous response to congestion on that
> > > > > IP network.
> > > > >
> > > >
> > > > No, the MTP Level 3 know that old message have not been delivered,
> > > > because it knows that it can issue a clear buffers before transfer
> > > > will resume from MTP L2 peer to L2 peer.
> > >
> > > The "clear buffers" needs to reach the MTP2 on the other side
> > > of a congested SCTP association before the MTP2 of the new
> > > link starts sending. You cannot be sure that will happen.
> > 
> > Sure you can.  The MTP2 being in LPO does not send messages until
> > the SCTP association congestion ceases and it receives a resume
> > (after, possiblu,  a clear buffers) from the MTP3.
> 
> The MTP2 is not in LPO. See previous comments.

It should be, and can be made to do so easily with end-to-end acks.

> 
> > 
> > >
> > > > It is not an assumption,
> > > > it is how it is designed.  Separating MTP3 and MTP2 by an IP
> > > > network does not necessitate procedural changes in MTP as you
> > > > propose.  Processor outage reduces mis-sequencing by reducing
> > > > the number of spurious changeovers, particularly in quasi-
> > > > associated mode.
> > >
> > > Time-controlled changeovers, initiated by processor outage,
> > > cause mis-sequencing.
> > 
> > No, time-controlled changeover is, as stated in the standard,
> > a procedure to prevent mis-sequencing. 
> 
> Please copy us the statement in the standard.

Section 5.6.2: "the purpose of witholding traffic for time  T1 (see 16.8) is
to reduce the probability of message  mis-sequencing."

> 
> Section 5.6.2 of Q.704 even says this:
> 
>   If time-controlled changeover has been initiated 
>   according to case ii) above and if a changeover order
>   is received from the remote and during the Time 
>   T1, it is advantageous to switch to the normal
>   changeover procedure including retrieval because 
>   unnecessary message loss or sending of old
>   messages is avoided in a simple way.

And MTP3 will do this.  If it is in LPO and it receives COO or ECO from the
MTP3 peer (because the peer has detected the failure of the link while the
local MTP3 has not due to the processor outage condition) it will change to
normal or emergency changeover procedures.
This is a given.  It has nothing to do with M2UA.

> 
> "case ii) above" is the initiation of time-controlled
> changeover due to processor outage.
> 
> This implies that normal changeover is preferrable,
> because it avoids sending of old messages that
> time-controlled changeover may cause.

No.  Normal changeover is not preferrable outside of this case.  It is
preferrable to wait T1 to see if the link recovers before performing a
changeover at all.  This is because case c) of 5.2.2 (as diagrammed in
Figure 11/Q.704 as the quasi-associated mode) is the only case where "a
possibility of message mis-sequencing exist[s]".  And "therefore its use
should take into account the overal service dependability described in
Recommendation Q.706."

The idea of time-controlled changeover as described in 5.6.2 is to not fail
a link, because normal and emergency changeover procedures resulting from a
failed link can mis-sequence messages.  Time-controlled changeover
procedures an intended to reduce the number of changeovers which are
required by waiting until it is necessary and suit their intended purpose.
By removing them, the number of changeover would increase and the
probability of message mis-sequencing would increase, possible above Q.706
limits.

This has been verified by the queuing model and simulation.
Your approach has not.

> 
> > The only situation cited
> > in which mis-sequencing can occur is during normal or emergency
> > changeover in the quasi-associated mode.
> 
> Please quote the citation.
> 
Citations above.

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Sat, 09 Jun 2001 23:22:18 -0700
From: Jacob Heitz <[email-masked]>
Organization: Lucent Technologies, Internetworking Systems, Software 
              Engineering, Alameda
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: SCTP lifetime
X-SMTP-HELO: drawbridge.ascend.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [198.4.92.1]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

I think the sum of this is that I and others remain unconvinced that
time-controlled changeover is a safe response to a congested SCTP link
between MTP3 and MTP2.

Your job is to convince us that it is safe.

In the absence of that, I am left with no choice, but to cause a real
changeover after the delay of the SCTP lifetime.
You can tune this timer to whatever you think is appropriate.

My basic premise is that the IP network should be engineered to provide a
stated bandwidth with a stated delay. The M2UA connection will not attempt
to use more than the stated bandwidth, by using its congestion
notifications. Therefore, SCTP congestion should be rare. Some M2UA messages
need to be delivered quickly and also need to be inline with the data, even
in the face of heavy load. This requires that the SCTP association be kept
free of congestion. To ensure this, the congestion notifications are used.

I have now asked Ken to make the response to congestion implementation
dependent. Therefore you may sell your implementation to anyone you can
convince of the safety of your approach.

You may now continue your ranting and I will let you know when you convince
me.

"Brian F. G. Bidulock" wrote:
> 
> Jacob,
> 
> On Sat, 09 Jun 2001, Jacob Heitz wrote:
> 
> > "Brian F. G. Bidulock" wrote:
> > >
> > > Jacob,
> > >
> > > On Sat, 09 Jun 2001, Jacob Heitz wrote:
> > >
> > > > "Brian F. G. Bidulock" wrote:
> > > > >
> > > > > Jacob,
> > > > >
> > > > > On Sat, 09 Jun 2001, Jacob Heitz wrote:
> > > > >
> > > > > > "Brian F. G. Bidulock" wrote:
> > > > > > >
> > > > > > > Jacob,
> > > > > > >
> > > > > > > On Fri, 08 Jun 2001, Jacob Heitz wrote:
> > > > > > >
> > > > > > > > "Brian F. G. Bidulock" wrote:
> > > > > > > > >
> > > > > > > > > Jacob,
> > > > > > > > >
> > > > > > > > > On Fri, 08 Jun 2001, Jacob Heitz wrote:
> > > > > > > > >
> > > > > > > > > > This is also well documented in Q.703:
> > > > > > > > > >
> > > > > > > > > >   It should be noted that in the case that processor
> > > > > > > > > >   outage is of "long term", i.e. when timer T1 in MTP
> > > > > > > > > >   level 3 (see 16.8/Q.704) has expired, problems exist
> > > > > > > > > >   with old messages, which are those messages
> > > > > > > > > >   stored within level 2 buffers after the switch of
> > > > > > > > > >   new traffic on the alternative link(s) has been
> > > > > > > > > >   performed. This is because, in general, the level
> > > > > > > > > >   2 buffers on both sides of the link contain some
> > > > > > > > > >   MSUs. If normal operation of the link is resumed,
> > > > > > > > > >   (re)transmission of these messages would result in
> > > > > > > > > >   message missequencing. Furthermore, it is very
> > > > > > > > > >   likely that these messages are related to calls that
> > > > > > > > > >   have already been released or to network management
> > > > > > > > > >   situations that have long since passed.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > This is simply the rationale for MTP3 clearing buffers
> > > > > > > > > when MTP2 recovered from processor outage.
> > > > > > > >
> > > > > > > > It also says "problems exist with old messages" regardless
> > > > > > > > of the "rationale".
> > > > > > >
> > > > > > > Since you seem to have problems with this passage,
> > > > > > > read T1.111.4 where it has been rewritten to avoid
> > > > > > > problems with old messages by clearing buffers.
> > > > > >
> > > > > > The SG does not know the messages are old. The MGC knows.
> > > > > > The link is congested. The MGC cannot get a message to
> > > > > > the SG to tell it.
> > > > >
> > > > > It is the sending MTP Level 3 which needs to know that
> > > > > the messages are old, because that's where the procedures
> > > > > are.
> > > >
> > > > It is the sending MTP2 that needs to know the messages are
> > > > old, because that is who will send them if he doesn't know.
> > > > Best of all, the receiving MTP should know that the messages
> > > > are old. Time-controlled changeover does not tell the
> > > > receiving end. Emergency (and normal) changeover does.
> > >
> > > It is the sending MTP2 knows not to send them because it
> > > is in Processor Outage.  The sending MTP3 knows to clear
> > > them before telling the sending MTP2 to recover from LPO.
> >
> > It is not in processor outage. We've been over this before.
> > Congestion does not occur in both directions at the same
> > time in general. In the previous threads, the consensus
> > agrees with this.
> 
> It can be made to detect in both directions at the
> same time with an M2UA to M2UA peer ack.  There are
> several algorithms which can accomplish this.
> 
> >
> > >
> > > Neither emergency (nor normal) changeover inform the
> > > other end in all cases.
> >
> > Time-controlled changeover never informs. Emergency
> > changeover sends ECO. Normal changeover sends COO.
> > I call that informing.
> 
> Not if it cannot reach the other side.

If it cannot reach the other side, then neither will any changed over
messages. The ECO or COO are sent reliably, so if they don't reach the other
side, the alternate link will fail too.

Again, time-controlled changeover never informs.

> 
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > When the path from MGC to SG congests, the MTP2 on the
> > > > > > > > > > SG is very much alive and completely unaware of a
problem.
> > > > > > > > > > It is very able to send "old messages" that arrive from
> > > > > > > > > > the congested M2UA. There is nothing the MGC can do
> > > > > > > > > > about it. A FLUSH_BUFFERS message would take too long
> > > > > > > > > > to get through and will be in line behind all the
> > > > > > > > > > "old messages" anyway.
> > > > > > > > >
> > > > > > > > > It can easily be made aware of the problem using ECN.
> > > > > > > > > This is a responsibility of the underlying SCTP and
> > > > > > > > > network implementation, not M2UA.
> > > > > > > >
> > > > > > > > Then you must mandate that ECN be implemented and can
> > > > > > > > ALWAYS get a message through. I can do without this
> > > > > > > > impossible restriction.
> > > > > > >
> > > > > > > No problem, acknowledge all messages M2UA peer to peer
> > > > > > > and end to end and you will know when one got through.
> > > > > > > It could be provided in M2UA protocol as well.  I proposed
> > > > > > > it with the use of Corellation Id and Acks or the
> > > > > > > use of gap acking over cumulative acking in SCTP.  This
> > > > > > > approach is necessary to resolve other buffer handling
> > > > > > > problems.
> > > > > >
> > > > > > This is irrelevant to congestion handling.
> > > > >
> > > > > Quite relevant, at that is what permits MTP Level 2 to
> > > > > know the age of messages.  This would permit the MGC M2UA
> > > > > to know the age of the message as you claim is necessary
> > > > > above.
> > > >
> > > > The age of a message does not determine whether it is too
> > > > old or not. "Too old" means than MTP3 is about to transmit
> > > > newer messages on an alternate link and those will arrive
> > > > at the receiving end before the "too old" messages. The only
> > > > one that can know that for sure is the receiving end.
> > > > Time-controlled changeover, initiated by processor outage,
> > > > does not inform the receiving end.
> > >
> > > That is why MTP3 clears them before sending on an alternate
> > > link set using the time-controlled procedure.  It is not
> > > necessary to inform the receiving end because the link will
> > > have already failed due to the same timer values being used
> > > at the peer MTP3.
> >
> > The link will not fail at the other end at the same time
> > in general. Again, we'we been over this.
> 
> Yes, because it will be informed of processor outage
> via SIPO and run the same timer.

The peer MTP2-MTP3 has nothing to do with congestion between the local
MTP2-MTP3 and has no knowledge of that congestion and no reason to send
SIPO.

> 
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > You go do it the way you want, Jacob, but there is no
> > > > > > > need to force your implementation view in the spec.
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > So, you see, it really doesn't matter what the precedent
> > > > > > > > > > is. What matters is that these "old messages" will
> > > > > > > > > > get delivered out of order once MTP3 does
time-controlled
> > > > > > > > > > changeover.
> > > > > > > > >
> > > > > > > > > No they won't, not in my implementation.  Did you want
> > > > > > > > > to send them in yours?
> > > > > > > >
> > > > > > > > Then your implementation only works on a wire. It needs
> > > > > > > > to work on an IP network where there is a chance that a
> > > > > > > > message, any message, may be delayed. We engineer a network
> > > > > > > > to make the chance of long delay low, but we must design
> > > > > > > > for the rare case when it happens.
> > > > > > >
> > > > > > > Then your's won't work across the wire (the one from
> > > > > > > MTP2 to MTP2) which exists for M2UA.
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > The draft might say "response to congestion is
> > > > > > > > > > implementation dependent" and give some suggestions of
> > > > > > > > > > what to do. It should also state that processor
> > > > > > > > > > outage SHOULD NOT be signalled for the reason outlined
> > > > > > > > > > above.
> > > > > > > > >
> > > > > > > > > Certainly not.  It is a very usable approach which is
> > > > > > > > > in full alignment with the existing MTP procedures.
> > > > > > > >
> > > > > > > > No, it isn't. Processor outage is not an existing procedure
> > > > > > > > for congestion between MTP2 and MTP3, because this interface
> > > > > > > > has always been assumed to be "frictionless" to use your
> > > > > > > > own term.
> > > > > > >
> > > > > > > I said that it was "frictionless" in the SDLs, not in
> > > > > > > implementation.  In real implementations internal congestion
> > > > > > > between link processor modules and level 3 processor modules
> > > > > > > can commonly occur.  If you have ever been involved in STP
> > > > > > > designs, you should know this.  Production STP's that I know
> > > > > > > of never fail links just because there are swerring, losing
> > > > > > > MSUs on the floor, or suffering interprocessor communication
> > > > > > > congestion.
> > > > > >
> > > > > > The MTP3-T1 timer assumes that by the time it expires, no old
> > > > > > messages capable of being delivered will exist in the system.
> > > > > > That is a reasonable assumption in most implementations of
> > > > > > MTP. When MTP3 and MTP2 are separated by an IP network, this
> > > > > > is no longer a reasonable assumption. That is what makes
> > > > > > processor-outage a dangerous response to congestion on that
> > > > > > IP network.
> > > > > >
> > > > >
> > > > > No, the MTP Level 3 know that old message have not been delivered,
> > > > > because it knows that it can issue a clear buffers before transfer
> > > > > will resume from MTP L2 peer to L2 peer.
> > > >
> > > > The "clear buffers" needs to reach the MTP2 on the other side
> > > > of a congested SCTP association before the MTP2 of the new
> > > > link starts sending. You cannot be sure that will happen.
> > >
> > > Sure you can.  The MTP2 being in LPO does not send messages until
> > > the SCTP association congestion ceases and it receives a resume
> > > (after, possiblu,  a clear buffers) from the MTP3.
> >
> > The MTP2 is not in LPO. See previous comments.
> 
> It should be, and can be made to do so easily with
> end-to-end acks.
> 
> >
> > >
> > > >
> > > > > It is not an assumption,
> > > > > it is how it is designed.  Separating MTP3 and MTP2 by an IP
> > > > > network does not necessitate procedural changes in MTP as you
> > > > > propose.  Processor outage reduces mis-sequencing by reducing
> > > > > the number of spurious changeovers, particularly in quasi-
> > > > > associated mode.
> > > >
> > > > Time-controlled changeovers, initiated by processor outage,
> > > > cause mis-sequencing.
> > >
> > > No, time-controlled changeover is, as stated in the standard,
> > > a procedure to prevent mis-sequencing.
> >
> > Please copy us the statement in the standard.
> 
> Section 5.6.2: "the purpose of witholding traffic for time
>  T1 (see 16.8) is to reduce the probability of message
>  mis-sequencing."

That assumes that all old messages have been flushed from the system by the
time T1 expires. That is normally a valid assumption, until you have a
congested IP network between MTP3 and MTP2. Then the assumption is no longer
valid and mis-sequencing is highly likely.

> 
> >
> > Section 5.6.2 of Q.704 even says this:
> >
> >   If time-controlled changeover has been initiated
> >   according to case ii) above and if a changeover order
> >   is received from the remote and during the Time
> >   T1, it is advantageous to switch to the normal
> >   changeover procedure including retrieval because
> >   unnecessary message loss or sending of old
> >   messages is avoided in a simple way.
> 
> And MTP3 will do this.  If it is in LPO and it receives
> COO or ECO from the MTP3 peer (because the peer has
> detected the failure of the link while the local MTP3
> has not due to the processor outage condition) it will
> change to normal or emergency changeover procedures.
> This is a given.  It has nothing to do with M2UA.
> 
> >
> > "case ii) above" is the initiation of time-controlled
> > changeover due to processor outage.
> >
> > This implies that normal changeover is preferrable,
> > because it avoids sending of old messages that
> > time-controlled changeover may cause.
> 
> No.  Normal changeover is not preferrable outside of this
> case.  It is preferrable to wait T1 to see if the link
> recovers before performing a changeover at all.  This is
> because case c) of 5.2.2 (as diagrammed in Figure 11/Q.704
> as the quasi-associated mode) is the only case where "a
> possibility of message mis-sequencing exist[s]".  And
> "therefore its use should take into account the overal
> service dependability described in Recommendation Q.706."
> 
> The idea of time-controlled changeover as described in
> 5.6.2 is to not fail a link, because normal and emergency
> changeover procedures resulting from a failed link can
> mis-sequence messages.  Time-controlled changeover
> procedures an intended to reduce the number of changeovers
> which are required by waiting until it is necessary and
> suit their intended purpose.  By removing them, the number
> of changeover would increase and the probability of message
> mis-sequencing would increase, possible above Q.706 limits.
> 
> This has been verified by the queuing model and simulation.
> Your approach has not.

Neither has your approach. There has never been a congested IP network
between MTP2 and MTP3 to verify your approach.

Time-controlled changeover runs a timer to prevent mis-sequencing of old
messages. Normal and emergency changeover informs the remote end to prevent
the mis-sequencing.

My proposal is to run a timer, as well as inform the remote end. The timer
is the SCTP lifetime timer.
The remote end is informed through the changeover notification, initiated
because of the out-of-service notification to MTP3 when the lifetime
expires.

> 
> >
> > > The only situation cited
> > > in which mis-sequencing can occur is during normal or emergency
> > > changeover in the quasi-associated mode.
> >
> > Please quote the citation.
> >
> Citations above.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Sun, 10 Jun 2001 10:19:54 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA draft 7 questions (SCTP congestion at ASP)
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Jacob, Brian

I just caught up on the past two days of email between the two of you.  I
agree with Jacob that there is not be an agreement at this time on how to
respond to SCTP congestion.

I will change the text to "implementation dependent".  Hopefully, at
bake-offs and through other testing, we will get an opportunity to evaluate.

Regards,

Ken

At 04:56 PM 6/9/01 -0700, Jacob Heitz wrote:
>Ken,
>
>I think we are not going to agree on how to respond to congestion.
>I suggest you make response to congestion indications
>implementation dependent, but you keep the congestion indication
>messages from SG to MGC and add congestion indication
>messages from MGC to SG.
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Sun, 10 Jun 2001 10:22:33 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA Message Inconsistency ....
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Sandeep,

Thank you for catching this error.  It should be an "Establish Cfm" message.

Ken

At 03:53 PM 6/8/01 -0700, you wrote:
>Hi Ken,
>  
>In M2UA draft 7, section 5.3.8,which describes the Audit procedure for the
>link from ASP to SG, there is an  " Establish Indication" message shown
from
>SG to ASP. This type of message is not existing in M2UA draft 7 at all. 
>
>
>Thanks
>Sandeep
>
>
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Sun, 10 Jun 2001 10:32:07 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: M2UA: SCTP lifetime
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], sigtran 
                  <[email-masked]>
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      KAA08086
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-213.dallas.net [209.44.42.213]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Jacob,

On Sat, 09 Jun 2001, Jacob Heitz wrote:

> I think the sum of this is that I and others remain unconvinced
> that time-controlled changeover is a safe response to a congested
> SCTP link between MTP3 and MTP2.

Which others?  I only hear you complain about a procedure which is part of
the MTP3 spec.  If anyone has a problem with time-controlled changeover,
please speak up!

> 
> Your job is to convince us that it is safe.
> 

Who is it that I need to convince?  All those that need to be convinced,
please speak up!

> In the absence of that, I am left with no choice, but to
> cause a real changeover after the delay of the SCTP lifetime.
> You can tune this timer to whatever you think is appropriate.

Please, make it implementation dependent and remove the text.

> 
> My basic premise is that the IP network should be engineered
> to provide a stated bandwidth with a stated delay. The M2UA
> connection will not attempt to use more than the stated 
> bandwidth, by using its congestion notifications. Therefore,
> SCTP congestion should be rare. Some M2UA messages need to
> be delivered quickly and also need to be inline with the
> data, even in the face of heavy load. This requires that
> the SCTP association be kept free of congestion. To ensure
> this, the congestion notifications are used.

There are two types of SCTP congestion: that due to overload (too much
traffic) and that due to failures which cause queueing delays (noise, error,
packet loss).  Neither of your suggested techniques distinguish between the
two, whereas SS7 has them neatly separated into blocking, failure and
congestion.

You have M2UA failing when it should block, congesting when it should fail,
and blocking when it should congest.

> 
> I have now asked Ken to make the response to congestion
> implementation dependent. Therefore you may sell your
> implementation to anyone you can convince of the safety
> of your approach.

Who said I was selling anything?

> 
> You may now continue your ranting and I will let you know
> when you convince me.

I have no hope of convincing you, Jacob, you do not appear to listen to
reason.

> 
> "Brian F. G. Bidulock" wrote:
> > 
> > Jacob,
> > 
> > On Sat, 09 Jun 2001, Jacob Heitz wrote:
> > 
> > > "Brian F. G. Bidulock" wrote:
> > > >
> > > > Jacob,
> > > >
> > > > On Sat, 09 Jun 2001, Jacob Heitz wrote:
> > > >
> > > > > "Brian F. G. Bidulock" wrote:
> > > > > >
> > > > > > Jacob,
> > > > > >
> > > > > > On Sat, 09 Jun 2001, Jacob Heitz wrote:
> > > > > >
> > > > > > > "Brian F. G. Bidulock" wrote:
> > > > > > > >
> > > > > > > > Jacob,
> > > > > > > >
> > > > > > > > On Fri, 08 Jun 2001, Jacob Heitz wrote:
> > > > > > > >
> > > > > > > > > "Brian F. G. Bidulock" wrote:
> > > > > > > > > >
> > > > > > > > > > Jacob,
> > > > > > > > > >
> > > > > > > > > > On Fri, 08 Jun 2001, Jacob Heitz wrote:
> > > > > > > > > >
> > > > > > > > > > > This is also well documented in Q.703:
> > > > > > > > > > >
> > > > > > > > > > >   It should be noted that in the case that processor
> > > > > > > > > > >   outage is of "long term", i.e. when timer T1 in MTP
> > > > > > > > > > >   level 3 (see 16.8/Q.704) has expired, problems exist
> > > > > > > > > > >   with old messages, which are those messages
> > > > > > > > > > >   stored within level 2 buffers after the switch of
> > > > > > > > > > >   new traffic on the alternative link(s) has been
> > > > > > > > > > >   performed. This is because, in general, the level
> > > > > > > > > > >   2 buffers on both sides of the link contain some
> > > > > > > > > > >   MSUs. If normal operation of the link is resumed,
> > > > > > > > > > >   (re)transmission of these messages would result in
> > > > > > > > > > >   message missequencing. Furthermore, it is very
> > > > > > > > > > >   likely that these messages are related to calls that
> > > > > > > > > > >   have already been released or to network management
> > > > > > > > > > >   situations that have long since passed.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > This is simply the rationale for MTP3 clearing buffers
> > > > > > > > > > when MTP2 recovered from processor outage.
> > > > > > > > >
> > > > > > > > > It also says "problems exist with old messages" regardless
> > > > > > > > > of the "rationale".
> > > > > > > >
> > > > > > > > Since you seem to have problems with this passage,
> > > > > > > > read T1.111.4 where it has been rewritten to avoid
> > > > > > > > problems with old messages by clearing buffers.
> > > > > > >
> > > > > > > The SG does not know the messages are old. The MGC knows.
> > > > > > > The link is congested. The MGC cannot get a message to
> > > > > > > the SG to tell it.
> > > > > >
> > > > > > It is the sending MTP Level 3 which needs to know that
> > > > > > the messages are old, because that's where the procedures
> > > > > > are.
> > > > >
> > > > > It is the sending MTP2 that needs to know the messages are
> > > > > old, because that is who will send them if he doesn't know.
> > > > > Best of all, the receiving MTP should know that the messages
> > > > > are old. Time-controlled changeover does not tell the
> > > > > receiving end. Emergency (and normal) changeover does.
> > > >
> > > > It is the sending MTP2 knows not to send them because it
> > > > is in Processor Outage.  The sending MTP3 knows to clear
> > > > them before telling the sending MTP2 to recover from LPO.
> > >
> > > It is not in processor outage. We've been over this before.
> > > Congestion does not occur in both directions at the same
> > > time in general. In the previous threads, the consensus
> > > agrees with this.
> > 
> > It can be made to detect in both directions at the
> > same time with an M2UA to M2UA peer ack.  There are
> > several algorithms which can accomplish this.
> > 
> > >
> > > >
> > > > Neither emergency (nor normal) changeover inform the
> > > > other end in all cases.
> > >
> > > Time-controlled changeover never informs. Emergency
> > > changeover sends ECO. Normal changeover sends COO.
> > > I call that informing.
> > 
> > Not if it cannot reach the other side.
> 
> If it cannot reach the other side, then neither will
> any changed over messages. The ECO or COO are sent
> reliably, so if they don't reach the other side, the
> alternate link will fail too.
> 
> Again, time-controlled changeover never informs.
> 
> > 
> > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > When the path from MGC to SG congests, the MTP2 on the
> > > > > > > > > > > SG is very much alive and completely unaware of a
problem.
> > > > > > > > > > > It is very able to send "old messages" that arrive
from
> > > > > > > > > > > the congested M2UA. There is nothing the MGC can do
> > > > > > > > > > > about it. A FLUSH_BUFFERS message would take too long
> > > > > > > > > > > to get through and will be in line behind all the
> > > > > > > > > > > "old messages" anyway.
> > > > > > > > > >
> > > > > > > > > > It can easily be made aware of the problem using ECN.
> > > > > > > > > > This is a responsibility of the underlying SCTP and
> > > > > > > > > > network implementation, not M2UA.
> > > > > > > > >
> > > > > > > > > Then you must mandate that ECN be implemented and can
> > > > > > > > > ALWAYS get a message through. I can do without this
> > > > > > > > > impossible restriction.
> > > > > > > >
> > > > > > > > No problem, acknowledge all messages M2UA peer to peer
> > > > > > > > and end to end and you will know when one got through.
> > > > > > > > It could be provided in M2UA protocol as well.  I proposed
> > > > > > > > it with the use of Corellation Id and Acks or the
> > > > > > > > use of gap acking over cumulative acking in SCTP.  This
> > > > > > > > approach is necessary to resolve other buffer handling
> > > > > > > > problems.
> > > > > > >
> > > > > > > This is irrelevant to congestion handling.
> > > > > >
> > > > > > Quite relevant, at that is what permits MTP Level 2 to
> > > > > > know the age of messages.  This would permit the MGC M2UA
> > > > > > to know the age of the message as you claim is necessary
> > > > > > above.
> > > > >
> > > > > The age of a message does not determine whether it is too
> > > > > old or not. "Too old" means than MTP3 is about to transmit
> > > > > newer messages on an alternate link and those will arrive
> > > > > at the receiving end before the "too old" messages. The only
> > > > > one that can know that for sure is the receiving end.
> > > > > Time-controlled changeover, initiated by processor outage,
> > > > > does not inform the receiving end.
> > > >
> > > > That is why MTP3 clears them before sending on an alternate
> > > > link set using the time-controlled procedure.  It is not
> > > > necessary to inform the receiving end because the link will
> > > > have already failed due to the same timer values being used
> > > > at the peer MTP3.
> > >
> > > The link will not fail at the other end at the same time
> > > in general. Again, we'we been over this.
> > 
> > Yes, because it will be informed of processor outage
> > via SIPO and run the same timer.
> 
> The peer MTP2-MTP3 has nothing to do with congestion
> between the local MTP2-MTP3 and has no knowledge of
> that congestion and no reason to send SIPO.
> 
> > 
> > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > You go do it the way you want, Jacob, but there is no
> > > > > > > > need to force your implementation view in the spec.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > So, you see, it really doesn't matter what the
precedent
> > > > > > > > > > > is. What matters is that these "old messages" will
> > > > > > > > > > > get delivered out of order once MTP3 does
time-controlled
> > > > > > > > > > > changeover.
> > > > > > > > > >
> > > > > > > > > > No they won't, not in my implementation.  Did you want
> > > > > > > > > > to send them in yours?
> > > > > > > > >
> > > > > > > > > Then your implementation only works on a wire. It needs
> > > > > > > > > to work on an IP network where there is a chance that a
> > > > > > > > > message, any message, may be delayed. We engineer a
network
> > > > > > > > > to make the chance of long delay low, but we must design
> > > > > > > > > for the rare case when it happens.
> > > > > > > >
> > > > > > > > Then your's won't work across the wire (the one from
> > > > > > > > MTP2 to MTP2) which exists for M2UA.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > The draft might say "response to congestion is
> > > > > > > > > > > implementation dependent" and give some suggestions of
> > > > > > > > > > > what to do. It should also state that processor
> > > > > > > > > > > outage SHOULD NOT be signalled for the reason outlined
> > > > > > > > > > > above.
> > > > > > > > > >
> > > > > > > > > > Certainly not.  It is a very usable approach which is
> > > > > > > > > > in full alignment with the existing MTP procedures.
> > > > > > > > >
> > > > > > > > > No, it isn't. Processor outage is not an existing
procedure
> > > > > > > > > for congestion between MTP2 and MTP3, because this
interface
> > > > > > > > > has always been assumed to be "frictionless" to use your
> > > > > > > > > own term.
> > > > > > > >
> > > > > > > > I said that it was "frictionless" in the SDLs, not in
> > > > > > > > implementation.  In real implementations internal congestion
> > > > > > > > between link processor modules and level 3 processor modules
> > > > > > > > can commonly occur.  If you have ever been involved in STP
> > > > > > > > designs, you should know this.  Production STP's that I know
> > > > > > > > of never fail links just because there are swerring, losing
> > > > > > > > MSUs on the floor, or suffering interprocessor communication
> > > > > > > > congestion.
> > > > > > >
> > > > > > > The MTP3-T1 timer assumes that by the time it expires, no old
> > > > > > > messages capable of being delivered will exist in the system.
> > > > > > > That is a reasonable assumption in most implementations of
> > > > > > > MTP. When MTP3 and MTP2 are separated by an IP network, this
> > > > > > > is no longer a reasonable assumption. That is what makes
> > > > > > > processor-outage a dangerous response to congestion on that
> > > > > > > IP network.
> > > > > > >
> > > > > >
> > > > > > No, the MTP Level 3 know that old message have not been
delivered,
> > > > > > because it knows that it can issue a clear buffers before
transfer
> > > > > > will resume from MTP L2 peer to L2 peer.
> > > > >
> > > > > The "clear buffers" needs to reach the MTP2 on the other side
> > > > > of a congested SCTP association before the MTP2 of the new
> > > > > link starts sending. You cannot be sure that will happen.
> > > >
> > > > Sure you can.  The MTP2 being in LPO does not send messages until
> > > > the SCTP association congestion ceases and it receives a resume
> > > > (after, possiblu,  a clear buffers) from the MTP3.
> > >
> > > The MTP2 is not in LPO. See previous comments.
> > 
> > It should be, and can be made to do so easily with
> > end-to-end acks.
> > 
> > >
> > > >
> > > > >
> > > > > > It is not an assumption,
> > > > > > it is how it is designed.  Separating MTP3 and MTP2 by an IP
> > > > > > network does not necessitate procedural changes in MTP as you
> > > > > > propose.  Processor outage reduces mis-sequencing by reducing
> > > > > > the number of spurious changeovers, particularly in quasi-
> > > > > > associated mode.
> > > > >
> > > > > Time-controlled changeovers, initiated by processor outage,
> > > > > cause mis-sequencing.
> > > >
> > > > No, time-controlled changeover is, as stated in the standard,
> > > > a procedure to prevent mis-sequencing.
> > >
> > > Please copy us the statement in the standard.
> > 
> > Section 5.6.2: "the purpose of witholding traffic for time
> >  T1 (see 16.8) is to reduce the probability of message
> >  mis-sequencing."
> 
> That assumes that all old messages have been flushed from
> the system by the time T1 expires. That is normally a valid
> assumption, until you have a congested IP network between
> MTP3 and MTP2. Then the assumption is no longer valid and
> mis-sequencing is highly likely.
> 
> > 
> > >
> > > Section 5.6.2 of Q.704 even says this:
> > >
> > >   If time-controlled changeover has been initiated
> > >   according to case ii) above and if a changeover order
> > >   is received from the remote and during the Time
> > >   T1, it is advantageous to switch to the normal
> > >   changeover procedure including retrieval because
> > >   unnecessary message loss or sending of old
> > >   messages is avoided in a simple way.
> > 
> > And MTP3 will do this.  If it is in LPO and it receives
> > COO or ECO from the MTP3 peer (because the peer has
> > detected the failure of the link while the local MTP3
> > has not due to the processor outage condition) it will
> > change to normal or emergency changeover procedures.
> > This is a given.  It has nothing to do with M2UA.
> > 
> > >
> > > "case ii) above" is the initiation of time-controlled
> > > changeover due to processor outage.
> > >
> > > This implies that normal changeover is preferrable,
> > > because it avoids sending of old messages that
> > > time-controlled changeover may cause.
> > 
> > No.  Normal changeover is not preferrable outside of this
> > case.  It is preferrable to wait T1 to see if the link
> > recovers before performing a changeover at all.  This is
> > because case c) of 5.2.2 (as diagrammed in Figure 11/Q.704
> > as the quasi-associated mode) is the only case where "a
> > possibility of message mis-sequencing exist[s]".  And
> > "therefore its use should take into account the overal
> > service dependability described in Recommendation Q.706."
> > 
> > The idea of time-controlled changeover as described in
> > 5.6.2 is to not fail a link, because normal and emergency
> > changeover procedures resulting from a failed link can
> > mis-sequence messages.  Time-controlled changeover
> > procedures an intended to reduce the number of changeovers
> > which are required by waiting until it is necessary and
> > suit their intended purpose.  By removing them, the number
> > of changeover would increase and the probability of message
> > mis-sequencing would increase, possible above Q.706 limits.
> > 
> > This has been verified by the queuing model and simulation.
> > Your approach has not.
> 
> Neither has your approach. There has never been a congested
> IP network between MTP2 and MTP3 to verify your approach.
> 
> Time-controlled changeover runs a timer to prevent
> mis-sequencing of old messages. Normal and emergency
> changeover informs the remote end to prevent the
> mis-sequencing.
> 
> My proposal is to run a timer, as well as inform the
> remote end. The timer is the SCTP lifetime timer.
> The remote end is informed through the changeover
> notification, initiated because of the out-of-service
> notification to MTP3 when the lifetime expires.
> 
> > 
> > >
> > > > The only situation cited
> > > > in which mis-sequencing can occur is during normal or emergency
> > > > changeover in the quasi-associated mode.
> > >
> > > Please quote the citation.
> > >
> > Citations above.
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Sun, 10 Jun 2001 12:52:33 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M3UA M2UA: ASP Partitioning
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

Sorry for the delayed response.  I understand your concern now that we are
adding the loadshare and broadcast options to M2UA.  I will add ASP ID to
the next version of M2UA.

Regards,

Ken

At 12:30 PM 6/4/01 -0500, you wrote:
>All,
>
>I understand that ASP to ASP communications is outside the
>scope of both the M2UA and M3UA documents, however, I am
>trying to find a solution to the problem where ASPs lose
>communication with each other.  Take the a simple two ASP
>case in the same AS as follows:
>
>                +-------+           +-------+
>                |       |           |       |
>                |  ASP  +-----------+  ASP  |
>                |   1   |           |   2   |
>                +---+---+           +---+---+
>                    |                   |
>                    |                   |
>      Association   +-------+   +-------+  Association
>                            |   |
>                            |   |
>                          +-+---+-+
>                          |       |
>                          |  SGP  |
>                          |       |
>                          +-------+
>
>Now, a couple of comments:  The ASPs are geographically
>separated (otherwise there isn't much point in having
>them use separate associations).  Therefore, the ASP-ASP
>communications link can suffer failures.  When the ASP-ASP
>communications fails we have the following problem:
>
>                +-------+           +-------+
>                |       |           |       |
>                |  ASP  +--   X   --+  ASP  |
>                |   1   |           |   2   |
>                +---+---+           +---+---+
>                    |                   |
>                    |                   |
>      Association   +-------+   +-------+  Association
>                            |   |
>                            |   |
>                          +-+---+-+
>                          |       |
>                          |  SGP  |
>                          |       |
>                          +-------+
>
>In the above diagram, ASP2 no longer knows the state of
>ASP1.  Nor can ASP2 tell whether ASP1 has failed or whether
>simply communications to ASP1 has failed.  That is ASP2
>cannot locally determine whether the above is the case
>or whether the following diagram is the case:
>
>                X X X X X           +-------+
>                                    |       |
>                X  ASP  X--   X   --+  ASP  |
>                    1               |   2   |
>                X X X X X           +---+---+
>                    |                   |
>                                        |
>      Association       X  -+   +-------+  Association
>                            |   |
>                            |   |
>                          +-+---+-+
>                          |       |
>                          |  SGP  |
>                          |       |
>                          +-------+
>
>In both cases, the SG is aware of what the state of ASP1
>is with regards to being able to exchange information with
>the SS7 network.
>
>I would like to see a mechanism in the UAs which allows
>ASP2 to be notified of the change in state of ASP1 with
>respect to the SG.  This would require an ASP identifier
>which is provided to the SG with the ASP-Up and a
>notification (NTFY) sent to other ASPs in the AS when
>an ASP makes some state transitions.  These notifications
>can be completely advisory (in that it is still up to the
>ASP to take action on them or ignore them).
>
>The addition of an ASP Id would also help the SG determine
>whether it has multiple associations open to the same
>ASP.
>
>--Brian
>
>
>-- 
>Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
>[email-masked]    ¦ world; the unreasonable one persists in  ¦
>http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Sun, 10 Jun 2001 12:07:44 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA draft 7 questions (SCTP congestion at ASP)
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      MAA09247
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.213]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

On Sun, 10 Jun 2001, Ken Morneault wrote:

> Jacob, Brian
> 
> I just caught up on the past two days of email between the
> two of you.  I agree with Jacob that there is not be an 
> agreement at this time on how to respond to SCTP congestion.

I don't think that there is even agreement on what constitutes congestion!

> I will change the text to "implementation dependent".  Hopefully,
> at bake-offs and through other testing, we will get an opportunity
> to evaluate.

It makes some sense to not, on the one hand, tell an implementor that
meeting any reliability and quality of service objectives for SS7 is their
responsibility, and, on the other hand, constrain how the implementor goes
about fulfilling that responsibility without consideration for the impact of
the constraints on that obligation.

Not to be antagonistic, but, I believe that it is unlikely that bake-offs
will yield any fruit: they normally only test interoperability on the
required portions of the specification and don't get around to testing
implementation dependent functions to the degree which may be necessary to
determine these impacts.

I don't really know what you mean by "other testing": in the past it has
taken fairly expensive modelling and simulation to verify the impacts of
link-level procedures on an SS7 network.  (Some spent $10-20M, others spent
more.)

Resolving these issues, however, or even making explicit recommendations in
their regard appears to be beyond the resources of the IETF.

> Regards,
> Ken

I would still like to see the addition of a Correlation Id and a Correlation
Id Ack so that the implementor of the M2UA may be able to coorination the
splitting of the RB, TB and RTB across the SCTP association as alluded to by
Al Varney in his note of November 30th.  Using the acknolwedged data service
available in some SCTP implementations is not sufficient, because it is
based on a 16-bit stream sequence number where 24-bits are likely called
for.

There is also the difficulty in the current use of M2UA to place an SS7 link
in a single stream, that the data rate may demand a stream sequence number
with wider range than 16 bits.  A case in point is Q.703 Annex A operation
where a 24 bit sequence number is required to permit a wide enough window
for acknolwedgement.
Also, because M2UA has not been restricted from interworking with MTP3b
links, SCTP's restricted SSN range may be quite problematic.

Therefore, I would like to see the M2UA recommendation permit the
implementation to split the SLS components of link onto separate streams (in
an open fashion such as M3UA allows) in an attempt to extend the 16-bit SCTP
SSN by the number of bits of the SLS (4 or 5) for use with high speed links.

The Correlation Id has another purpose.  It is to permit an M2UA/MTP2
implementation to receive acknowledgements from an MTP3/M2AU (Correlation Id
Ack) when MSUs have been received.  This permits the splitting of the RB
across the SCTP assoc.

It also would permit MTP3/M2UA to receive acknowledgements from M2UA/MTP2
when messages have been accepted by M2UA or possibly when they have been
acknolwedged to MTP2.  This would permit the splitting of the TB/RTB across
the SCTP assoc.

These parameters would permit an implementor to handle the RB/TB/RTB in a
number of different implementation dependent fashions which could possibly
be more in fitting with both the implementation's MTP2 and MTP3's
expectations for buffer handling (SIPO, SIB, and Transmit Congestion).

(I don't belive that Jacob should have a problem with this one, he proposed
a similar arrangement last year.)

The Correlation Id should be optional to generate, but invoke a mandatory
response for the sake of improved interoperability.
See the proposed text which I provided for M3UA.

--Brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Sun, 10 Jun 2001 14:11:35 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: SCTP lifetime
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-213.dallas.net [209.44.42.213]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Jacob,

Please see comments below...

On Sat, 09 Jun 2001, Jacob Heitz wrote:
> 
> "Brian F. G. Bidulock" wrote:
> > 
> > Jacob,
> > 
> > On Sat, 09 Jun 2001, Jacob Heitz wrote:
> > 
> > > "Brian F. G. Bidulock" wrote:
> > > >
> > > > Jacob,
> > > >
> > > > On Sat, 09 Jun 2001, Jacob Heitz wrote:
> > > >
> > > > > "Brian F. G. Bidulock" wrote:
> > > > > >
> > > > > > Jacob,
> > > > > >
> > > > > > On Sat, 09 Jun 2001, Jacob Heitz wrote:
> > > > > >
> > > > > > > "Brian F. G. Bidulock" wrote:
> > > > > > > >
> > > > > > > > Jacob,
> > > > > > > >
> > > > > > > > On Fri, 08 Jun 2001, Jacob Heitz wrote:
> > > > > > > >
> > > > > > > > > "Brian F. G. Bidulock" wrote:
> > > > > > > > > >
> > > > > > > > > > Jacob,
> > > > > > > > > >
> > > > > > > > > > On Fri, 08 Jun 2001, Jacob Heitz wrote:
> > > > > > > > > >
> > > > > > > > > > > This is also well documented in Q.703:
> > > > > > > > > > >
> > > > > > > > > > >   It should be noted that in the case that processor
> > > > > > > > > > >   outage is of "long term", i.e. when timer T1 in MTP
> > > > > > > > > > >   level 3 (see 16.8/Q.704) has expired, problems exist
> > > > > > > > > > >   with old messages, which are those messages
> > > > > > > > > > >   stored within level 2 buffers after the switch of
> > > > > > > > > > >   new traffic on the alternative link(s) has been
> > > > > > > > > > >   performed. This is because, in general, the level
> > > > > > > > > > >   2 buffers on both sides of the link contain some
> > > > > > > > > > >   MSUs. If normal operation of the link is resumed,
> > > > > > > > > > >   (re)transmission of these messages would result in
> > > > > > > > > > >   message missequencing. Furthermore, it is very
> > > > > > > > > > >   likely that these messages are related to calls that
> > > > > > > > > > >   have already been released or to network management
> > > > > > > > > > >   situations that have long since passed.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > This is simply the rationale for MTP3 clearing buffers
> > > > > > > > > > when MTP2 recovered from processor outage.
> > > > > > > > >
> > > > > > > > > It also says "problems exist with old messages" regardless
> > > > > > > > > of the "rationale".
> > > > > > > >
> > > > > > > > Since you seem to have problems with this passage,
> > > > > > > > read T1.111.4 where it has been rewritten to avoid
> > > > > > > > problems with old messages by clearing buffers.
> > > > > > >
> > > > > > > The SG does not know the messages are old. The MGC knows.
> > > > > > > The link is congested. The MGC cannot get a message to
> > > > > > > the SG to tell it.
> > > > > >
> > > > > > It is the sending MTP Level 3 which needs to know that
> > > > > > the messages are old, because that's where the procedures
> > > > > > are.
> > > > >
> > > > > It is the sending MTP2 that needs to know the messages are
> > > > > old, because that is who will send them if he doesn't know.
> > > > > Best of all, the receiving MTP should know that the messages
> > > > > are old. Time-controlled changeover does not tell the
> > > > > receiving end. Emergency (and normal) changeover does.
> > > >
> > > > It is the sending MTP2 knows not to send them because it
> > > > is in Processor Outage.  The sending MTP3 knows to clear
> > > > them before telling the sending MTP2 to recover from LPO.
> > >
> > > It is not in processor outage. We've been over this before.
> > > Congestion does not occur in both directions at the same
> > > time in general. In the previous threads, the consensus
> > > agrees with this.
> > 
> > It can be made to detect in both directions at the
> > same time with an M2UA to M2UA peer ack.  There are
> > several algorithms which can accomplish this.
> > 
> > >
> > > >
> > > > Neither emergency (nor normal) changeover inform the
> > > > other end in all cases.
> > >
> > > Time-controlled changeover never informs. Emergency
> > > changeover sends ECO. Normal changeover sends COO.
> > > I call that informing.
> > 
> > Not if it cannot reach the other side.
> 
> If it cannot reach the other side, then neither will
> any changed over messages. The ECO or COO are sent
> reliably, so if they don't reach the other side, the
> alternate link will fail too.

Per 5.6.2 if there is no route to the adjacent SP, time-controlled
changeover will be performed.  You cannot guarantee that failing the link
will generate COO/ECO.  MTP3 will decide which procedure to use.

> 
> Again, time-controlled changeover never informs.

But can recover within a wider time window, reducing the number of
changeovers and lowering the probability of mis-sequencing in
quasi-associated mode.  Failing the link will, in some circumstances, invoke
ECO/COO which will complete rapidly, increasing the probability of
changeover and the probability of mis-sequencing in quasi-associated mode.

Your logic is flawed.

Increasing the number of changeovers using ECO/COO increases the probability
of mis-sequencing in quasi- associated mode.

Decreasing the number of changeovers by filtering spurious changeovers with
recovery using the time-controlled procedures, reduces the probability of
mis-sequencing in quasi-associated mode.

Your proposal has the opposite effect of what you are trying to acheive, it
increases mis-sequencing.

> 
> > 
> > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > When the path from MGC to SG congests, the MTP2 on the
> > > > > > > > > > > SG is very much alive and completely unaware of a
problem.
> > > > > > > > > > > It is very able to send "old messages" that arrive
from
> > > > > > > > > > > the congested M2UA. There is nothing the MGC can do
> > > > > > > > > > > about it. A FLUSH_BUFFERS message would take too long
> > > > > > > > > > > to get through and will be in line behind all the
> > > > > > > > > > > "old messages" anyway.
> > > > > > > > > >
> > > > > > > > > > It can easily be made aware of the problem using ECN.
> > > > > > > > > > This is a responsibility of the underlying SCTP and
> > > > > > > > > > network implementation, not M2UA.
> > > > > > > > >
> > > > > > > > > Then you must mandate that ECN be implemented and can
> > > > > > > > > ALWAYS get a message through. I can do without this
> > > > > > > > > impossible restriction.
> > > > > > > >
> > > > > > > > No problem, acknowledge all messages M2UA peer to peer
> > > > > > > > and end to end and you will know when one got through.
> > > > > > > > It could be provided in M2UA protocol as well.  I proposed
> > > > > > > > it with the use of Corellation Id and Acks or the
> > > > > > > > use of gap acking over cumulative acking in SCTP.  This
> > > > > > > > approach is necessary to resolve other buffer handling
> > > > > > > > problems.
> > > > > > >
> > > > > > > This is irrelevant to congestion handling.
> > > > > >
> > > > > > Quite relevant, at that is what permits MTP Level 2 to
> > > > > > know the age of messages.  This would permit the MGC M2UA
> > > > > > to know the age of the message as you claim is necessary
> > > > > > above.
> > > > >
> > > > > The age of a message does not determine whether it is too
> > > > > old or not. "Too old" means than MTP3 is about to transmit
> > > > > newer messages on an alternate link and those will arrive
> > > > > at the receiving end before the "too old" messages. The only
> > > > > one that can know that for sure is the receiving end.
> > > > > Time-controlled changeover, initiated by processor outage,
> > > > > does not inform the receiving end.
> > > >
> > > > That is why MTP3 clears them before sending on an alternate
> > > > link set using the time-controlled procedure.  It is not
> > > > necessary to inform the receiving end because the link will
> > > > have already failed due to the same timer values being used
> > > > at the peer MTP3.
> > >
> > > The link will not fail at the other end at the same time
> > > in general. Again, we'we been over this.
> > 
> > Yes, because it will be informed of processor outage
> > via SIPO and run the same timer.
> 
> The peer MTP2-MTP3 has nothing to do with congestion
> between the local MTP2-MTP3 and has no knowledge of
> that congestion and no reason to send SIPO.

You mis-understand.  I am talking about the other end which is receiving
SIPO from the MTP2 at the congested end.  Because it is receiving SIPO it
will be running remote processor outage timers at MTP3.  If they expire, the
link will be failed and COO/ECO launched to the MTP3 peer which is in SCTP
congestion.
That MTP3 peer may still switch from time-controlled to normal/ emerg
changeover upon receipt of the COO/ECO.  Starting with the time-controlled
procedure suits the purpose of filtering spurious changeovers with a
recovery procedure, while permitting normal/emerg changeover when the other
end detects link failure.

> 
> > 
> > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > You go do it the way you want, Jacob, but there is no
> > > > > > > > need to force your implementation view in the spec.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > So, you see, it really doesn't matter what the
precedent
> > > > > > > > > > > is. What matters is that these "old messages" will
> > > > > > > > > > > get delivered out of order once MTP3 does
time-controlled
> > > > > > > > > > > changeover.
> > > > > > > > > >
> > > > > > > > > > No they won't, not in my implementation.  Did you want
> > > > > > > > > > to send them in yours?
> > > > > > > > >
> > > > > > > > > Then your implementation only works on a wire. It needs
> > > > > > > > > to work on an IP network where there is a chance that a
> > > > > > > > > message, any message, may be delayed. We engineer a
network
> > > > > > > > > to make the chance of long delay low, but we must design
> > > > > > > > > for the rare case when it happens.
> > > > > > > >
> > > > > > > > Then your's won't work across the wire (the one from
> > > > > > > > MTP2 to MTP2) which exists for M2UA.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > The draft might say "response to congestion is
> > > > > > > > > > > implementation dependent" and give some suggestions of
> > > > > > > > > > > what to do. It should also state that processor
> > > > > > > > > > > outage SHOULD NOT be signalled for the reason outlined
> > > > > > > > > > > above.
> > > > > > > > > >
> > > > > > > > > > Certainly not.  It is a very usable approach which is
> > > > > > > > > > in full alignment with the existing MTP procedures.
> > > > > > > > >
> > > > > > > > > No, it isn't. Processor outage is not an existing
procedure
> > > > > > > > > for congestion between MTP2 and MTP3, because this
interface
> > > > > > > > > has always been assumed to be "frictionless" to use your
> > > > > > > > > own term.
> > > > > > > >
> > > > > > > > I said that it was "frictionless" in the SDLs, not in
> > > > > > > > implementation.  In real implementations internal congestion
> > > > > > > > between link processor modules and level 3 processor modules
> > > > > > > > can commonly occur.  If you have ever been involved in STP
> > > > > > > > designs, you should know this.  Production STP's that I know
> > > > > > > > of never fail links just because there are swerring, losing
> > > > > > > > MSUs on the floor, or suffering interprocessor communication
> > > > > > > > congestion.
> > > > > > >
> > > > > > > The MTP3-T1 timer assumes that by the time it expires, no old
> > > > > > > messages capable of being delivered will exist in the system.
> > > > > > > That is a reasonable assumption in most implementations of
> > > > > > > MTP. When MTP3 and MTP2 are separated by an IP network, this
> > > > > > > is no longer a reasonable assumption. That is what makes
> > > > > > > processor-outage a dangerous response to congestion on that
> > > > > > > IP network.
> > > > > > >
> > > > > >
> > > > > > No, the MTP Level 3 know that old message have not been
delivered,
> > > > > > because it knows that it can issue a clear buffers before
transfer
> > > > > > will resume from MTP L2 peer to L2 peer.
> > > > >
> > > > > The "clear buffers" needs to reach the MTP2 on the other side
> > > > > of a congested SCTP association before the MTP2 of the new
> > > > > link starts sending. You cannot be sure that will happen.
> > > >
> > > > Sure you can.  The MTP2 being in LPO does not send messages until
> > > > the SCTP association congestion ceases and it receives a resume
> > > > (after, possiblu,  a clear buffers) from the MTP3.
> > >
> > > The MTP2 is not in LPO. See previous comments.
> > 
> > It should be, and can be made to do so easily with
> > end-to-end acks.
> > 
> > >
> > > >
> > > > >
> > > > > > It is not an assumption,
> > > > > > it is how it is designed.  Separating MTP3 and MTP2 by an IP
> > > > > > network does not necessitate procedural changes in MTP as you
> > > > > > propose.  Processor outage reduces mis-sequencing by reducing
> > > > > > the number of spurious changeovers, particularly in quasi-
> > > > > > associated mode.
> > > > >
> > > > > Time-controlled changeovers, initiated by processor outage,
> > > > > cause mis-sequencing.
> > > >
> > > > No, time-controlled changeover is, as stated in the standard,
> > > > a procedure to prevent mis-sequencing.
> > >
> > > Please copy us the statement in the standard.
> > 
> > Section 5.6.2: "the purpose of witholding traffic for time
> >  T1 (see 16.8) is to reduce the probability of message
> >  mis-sequencing."
> 
> That assumes that all old messages have been flushed from
> the system by the time T1 expires. That is normally a valid
> assumption, until you have a congested IP network between
> MTP3 and MTP2. Then the assumption is no longer valid and
> mis-sequencing is highly likely.

Again, end to end acks and other simple algorithms already provided for in
SCTP (SRTT test, acknolwedged data receipt) could be used to ensure that
M2UA/MTP2 is in processor outage at about the same time as MTP3/M2UA.  The
procedure allows for some slippage here as well.

> 
> > 
> > >
> > > Section 5.6.2 of Q.704 even says this:
> > >
> > >   If time-controlled changeover has been initiated
> > >   according to case ii) above and if a changeover order
> > >   is received from the remote and during the Time
> > >   T1, it is advantageous to switch to the normal
> > >   changeover procedure including retrieval because
> > >   unnecessary message loss or sending of old
> > >   messages is avoided in a simple way.
> > 
> > And MTP3 will do this.  If it is in LPO and it receives
> > COO or ECO from the MTP3 peer (because the peer has
> > detected the failure of the link while the local MTP3
> > has not due to the processor outage condition) it will
> > change to normal or emergency changeover procedures.
> > This is a given.  It has nothing to do with M2UA.
> > 
> > >
> > > "case ii) above" is the initiation of time-controlled
> > > changeover due to processor outage.
> > >
> > > This implies that normal changeover is preferrable,
> > > because it avoids sending of old messages that
> > > time-controlled changeover may cause.
> > 
> > No.  Normal changeover is not preferrable outside of this
> > case.  It is preferrable to wait T1 to see if the link
> > recovers before performing a changeover at all.  This is
> > because case c) of 5.2.2 (as diagrammed in Figure 11/Q.704
> > as the quasi-associated mode) is the only case where "a
> > possibility of message mis-sequencing exist[s]".  And
> > "therefore its use should take into account the overal
> > service dependability described in Recommendation Q.706."
> > 
> > The idea of time-controlled changeover as described in
> > 5.6.2 is to not fail a link, because normal and emergency
> > changeover procedures resulting from a failed link can
> > mis-sequence messages.  Time-controlled changeover
> > procedures an intended to reduce the number of changeovers
> > which are required by waiting until it is necessary and
> > suit their intended purpose.  By removing them, the number
> > of changeover would increase and the probability of message
> > mis-sequencing would increase, possible above Q.706 limits.
> > 
> > This has been verified by the queuing model and simulation.
> > Your approach has not.
> 
> Neither has your approach. There has never been a congested
> IP network between MTP2 and MTP3 to verify your approach.

Uh, yes it has.  The probability and distribution of processor outages was
part of the simulation model.

> 
> Time-controlled changeover runs a timer to prevent
> mis-sequencing of old messages. Normal and emergency
> changeover informs the remote end to prevent the
> mis-sequencing.

No.  Mis-sequencing can occur in normal/emerg changeover in the
quasi-associated mode.  To meet Q.706 requirements on mis-sequencing, the
number and occurence of changeovers in the quasi-associated mode must be
restricted.  SS7's way of restricting spurious changeovers resulting from
short- term failures is the time-controlled procedures.

> 
> My proposal is to run a timer, as well as inform the
> remote end. The timer is the SCTP lifetime timer.
> The remote end is informed through the changeover
> notification, initiated because of the out-of-service
> notification to MTP3 when the lifetime expires.

The remote end is informed by performing normal/emerg changeover, which in
the quasi-associated mode increases the probability of message
mis-sequencing with each occurence.

> 
> > 
> > >
> > > > The only situation cited
> > > > in which mis-sequencing can occur is during normal or emergency
> > > > changeover in the quasi-associated mode.
> > >
> > > Please quote the citation.
> > >
> > Citations above.
> 

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: Reinventing the Wheel
Date: Mon, 11 Jun 2001 08:53:33 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x4.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x4.nokia.com [131.228.20.27]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

> Did anyone consider in the specification of SUA that SCCP
> is nothing more than an ISO Network Service with the intention
> of supporting an ISO Transport Service (TCAP), and that the
> use of ISO Transport and Network Service over TCP/IP has been
> well documented and implemented in accordance with RFC 1006,
> RFC 1859 and RFC 2126?

There are other possible SUA users than simply TCAP.  As this is the case, I
believe SUA to still be worthwhile.

best regards,
John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 11 Jun 2001 01:30:46 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Reinventing the Wheel
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.213]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

Which SCCP users are those that are other than TCAP?

--Brian

On Mon, 11 Jun 2001, [email-masked] wrote:

> Hi Brian,
> 
> > Did anyone consider in the specification of SUA that SCCP
> > is nothing more than an ISO Network Service with the intention
> > of supporting an ISO Transport Service (TCAP), and that the
> > use of ISO Transport and Network Service over TCP/IP has been
> > well documented and implemented in accordance with RFC 1006,
> > RFC 1859 and RFC 2126?
> 
> There are other possible SUA users than simply TCAP.  As this
> is the case, I believe SUA to still be worthwhile.
> 
> best regards,
> John

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: Reinventing the Wheel
Date: Mon, 11 Jun 2001 10:19:22 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x2.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x2.nokia.com [131.228.20.22]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

> Which SCCP users are those that are other than TCAP?

RANAP and RNSAP (radio access network control plan protocols) as defined by
3GPP.  The references are as follows:

[RANAP] 	3G TS 25.413 V3.5.0 (2001-03) 'Technical Specification 3rd
Generation Partnership Project; Technical Specification Group Radio Access
Network; UTRAN Iu Interface RANAP Signalling'

[UTRAN IUR]	3G TS 25.422 V3.5.0 (2000-12) "Technical Specification 3rd
Generation Partnership Project; Technical Specification Group Radio Access
Network; UTRAN Iur Interface Signaling Transport (Release 1999)"

br,
John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
To: "sigtran" <[email-masked]>
Date: Mon, 11 Jun 2001 14:40:16 +0530
From: Anal Srivastava <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Mailer: MailCity Service
Subject: RE: Reinventing the Wheel
X-Sender-Ip: 203.190.131.2
Organization: Lycos Mail (http://mail.lycos.com:80)
X-SMTP-HELO: mailcity.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: fes.whowhere.com [209.185.123.154]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hi,

BSSMAP (used between BSC & MSC) also uses SCCP (though connection oriented
services).

-Anal.
--

On Mon, 11 Jun 2001 10:19:22  
 john.loughney wrote:
>Hi Brian,
>
>> Which SCCP users are those that are other than TCAP?
>
>RANAP and RNSAP (radio access network control plan protocols)
>as defined by 3GPP.  The references are as follows:
>
>[RANAP] 	3G TS 25.413 V3.5.0 (2001-03) 'Technical Specification 3rd
>Generation Partnership Project; Technical Specification Group Radio Access
>Network; UTRAN Iu Interface RANAP Signalling'
>
>[UTRAN IUR]	3G TS 25.422 V3.5.0 (2000-12) "Technical Specification 3rd
>Generation Partnership Project; Technical Specification Group Radio Access
>Network; UTRAN Iur Interface Signaling Transport (Release 1999)"
>
>br,
>John
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked]

Get 250 color business cards for FREE!
http://businesscards.lycos.com/vp/fastpath/

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: Address Mapping Function & Relay Node text
Date: Mon, 11 Jun 2001 12:35:01 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x2.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x2.nokia.com [131.228.20.22]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Srini,

> Along with the IP and Hostname as routing keys you may want 
> to add GT also.
> Since once could make the routinmg decisions at SRF (Relay 
> Node) using GT information.

That one of the possibilities already.

thanks,
John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 11 Jun 2001 04:38:56 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Reinventing the Wheel
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-213.dallas.net [209.44.42.213]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

I believe that RFC 1006 also maps the ISO Network Services N-Primitives onto
TCP.  As SCCP provides no more than the ISO N-Primitives, the RFCs sited
would be sufficient, I believe, for these SCCP users as well.

Are there any other, more compelling reasons, why the existing ISO work in
the IETF and elsewhere has been discarded?

It just doesn't make much sense to me on the surface to take an ISO Network
Service interface and, rather than implementing it over TCP/IP, attempting
to implement an SS7- specific SCCP in between the ISO interface and SCTP,
particularly when SS7 went to so much trouble in the first place to provide
ISO Network Services interface to SCCP.

Could you perhaps humor me with several compelling technical reasons for
doing so?

--Brian

On Mon, 11 Jun 2001, [email-masked] wrote:

> Hi Brian,
> 
> > Which SCCP users are those that are other than TCAP?
> 
> RANAP and RNSAP (radio access network control plan protocols)
> as defined by 3GPP.  The references are as follows:
> 
> [RANAP] 	3G TS 25.413 V3.5.0 (2001-03) 'Technical Specification 3rd
> Generation Partnership Project; Technical Specification Group Radio Access
> Network; UTRAN Iu Interface RANAP Signalling'
> 
> [UTRAN IUR]	3G TS 25.422 V3.5.0 (2000-12) "Technical Specification 3rd
> Generation Partnership Project; Technical Specification Group Radio Access
> Network; UTRAN Iur Interface Signaling Transport (Release 1999)"
> 
> br,
> John
> 

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Coene Lode <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Reinventing the Wheel
Date: Mon, 11 Jun 2001 12:20:25 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades6.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [194.78.143.126]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: Reinventing the Wheel</TITLE> </HEAD>
<BODY>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT> <BR><FONT SIZE=2>&gt;
From: Brian F. G. Bidulock [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: zondag 10 juni 2001 20:04</FONT> <BR><FONT
SIZE=2>&gt; To: sigtran</FONT> <BR><FONT SIZE=2>&gt; Cc:
[email-masked]; [email-masked]</FONT> <BR><FONT
SIZE=2>&gt; Subject: SUA: Reinventing the Wheel</FONT> <BR><FONT SIZE=2>&gt;
</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Gentlemen,</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Did anyone consider in the specification of SUA that
SCCP</FONT> <BR><FONT SIZE=2>&gt; is nothing more than an ISO Network
Service with the intention</FONT> <BR><FONT SIZE=2>&gt; of supporting an ISO
Transport Service (TCAP), and that the</FONT> <BR><FONT SIZE=2>&gt; use of
ISO Transport and Network Service over TCP/IP has been</FONT> <BR><FONT
SIZE=2>&gt; well documented and implemented in accordance with RFC
1006,</FONT> <BR><FONT SIZE=2>&gt; RFC 1859 and RFC 2126?</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>Neither SCCP nor TCAP are ISO network or transport
services. Especially SCCP is NOT a ISO network service. I have never run
into a ISO spec specifying anything close to the things SCCP do. (Oh yes ,
apart from doing the Connection oriented service but that is only one of the
SCCP services, big deal)</FONT></P>

<P><FONT SIZE=2>TCAP cannot be a tranport service , it is a aplication
service. Oh yes it is very similar to ROSE and ACSE, but ROSE/ACSE were
supposed to be used on top of a connection oriented transport service. Hey,
TCAP was made to run on top of a connectionless transport service. And where
are those connectionless service specified somewhere in the RFC 1006,1859
and 2126.&nbsp; I looked, they ain't. </FONT></P>

<P><FONT SIZE=2>Thus we have to specify that ourselves and thus we are NOT
reinventing the wheel.</FONT> <BR><FONT SIZE=2>And how are we going to
transport our addresses, namely our Global Titles. As OSI NSAP's maybe? With
no support for any numbering plan besides E164(well tell that to a GSM
operator and most important to its customers -&gt; they are going to kill
you, especially the female part), no translation type, nature-of-address:
somewhere in the middle of nowhere.</FONT></P>

<P><FONT SIZE=2>&gt; Also, these approaches to ISO Transport over TCP do
not</FONT> <BR><FONT SIZE=2>&gt; encapsulate the transport primitives in the
TCP data stream,</FONT> <BR><FONT SIZE=2>&gt; but rather, map the primitives
onto TCP's ULP interface.</FONT> <BR><FONT SIZE=2>&gt; I put it to you that
the transport of TCAP (SCCP users) over</FONT> <BR><FONT SIZE=2>&gt; TCP has
already been specified in the cited RFCs and that</FONT> <BR><FONT
SIZE=2>&gt; all is missing is a similar mapping to SCTP as these RFCs</FONT>
<BR><FONT SIZE=2>&gt; provide for TCP.</FONT> </P>

<P><FONT SIZE=2>Great, every SCCP connection gets its own TCP/SCTP
connection, congratulations. And where the hell is the connectionless
service???. The one that makes everything WORK.</FONT></P>

<P><FONT SIZE=2>And if you map TCAP over TCP,how will that happen. A TCAP
transaction per SCTP connection. Good lord, that means for one that the
SCTP(or TCP) congestion algorithms will never have the possibility to
engage. TCAP is a request/ response. It waits for the response, it isn't a
file transfer protocol where you send a bunch of messages and the
acknowledges come back after a time, followed after a bit more time by the
response(if any was needed) of the filetransfer itself. Windows(No not
Microsoft, but the Cwnd) are very usefull in those cases for not overloading
the network. With TCAP you would get one msg in flight and that's it. Due to
to heavy use of TCAP you would have a lot of TCAP/SCTP dialogues/connections
open at the same time but hey without congestion control actually working,
but the endpoints and links clearly in trouble(meaning dropping messages).
then the congestion manager would come in handy, but that doesn't take into
acount the way everything is addressed. (And I could get one for hours and
hours ranting...)</FONT></P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Are we not reinventing the wheel here?</FONT> </P>

<P><FONT SIZE=2>NO</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; --Brian</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -- </FONT>
<BR><FONT SIZE=2>&gt; Brian F. G. Bidulock</FONT> <BR><FONT SIZE=2>&gt;
[email-masked]</FONT> <BR><FONT SIZE=2>&gt; <A
HREF="http://www.openss7.org/"
TARGET="_blank">http://www.openss7.org/</A></FONT> <BR><FONT SIZE=2>&gt;
</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
</P>

<P><FONT SIZE=2>Yours sincerly,</FONT>
<BR><FONT SIZE=2>Lode Coene</FONT>
</P>

<P><FONT SIZE=2>Siemens Atea ICN D CS D</FONT> <BR><FONT SIZE=2>Software
Development </FONT> <BR><FONT SIZE=2>Atealaan 34&nbsp;&nbsp;&nbsp;&nbsp;
</FONT> <BR><FONT SIZE=2>B-2200&nbsp;&nbsp;&nbsp;
Herentals&nbsp;&nbsp;&nbsp;
Belgium&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>Tel +32-14-25-2081&nbsp;&nbsp; /&nbsp; Fax +32-14-25-3212</FONT>
<BR><FONT SIZE=2>E-mail:&nbsp;&nbsp; [email-masked]</FONT> </P>

---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY>
</HTML>

</x-html>
From: A Srivastav <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: Re: AS state machine sharing between SGPs
Date: Mon, 11 Jun 2001 18:23:36 +0800
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-SMTP-HELO: myrealbox.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [192.108.102.201]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi All,
It should be obvious that SCTP associations can not be synchronized across
multiple boxes
But viewing SG as composed of multiple SGPs provides a definite way of
failover/loadshare facility on the SG side. In my opinion, it makes sense to
provide multiple-ASP-in-a-AS kind of semantics for the SGPs as well.

The need for correlation id will arise once we agree that multiple SGPs can
exist in a SG and procedures are defined for an ASP to shift traffic load
from one SGP to another.

-- Anubhav

> DATE: Thu, 31 May 2001 09:35:30
> From: "Brian F. G. Bidulock" <[email-masked]>
> To: "sigtran" <[email-masked]>
>
> Anal,
>
> Your definition of SGP's as being "completely in sync" is unrealistic.
> At least each SGP would have it's own SCTP association, which has no
> means for syncrhonization with other SGP associations.
>
> Do you see the need for a correlation id yet?
>
> --Brian
>
> On Thu, 31 May 2001, Anal Srivastava wrote:
>
> > Hi All,
> >
> > With reference to earlier thread "AS state machine sharing between
SGPs", I
> > think we need to settle the definitions of SG & SGP for once and for
all.
> > Basically we need to distinguish the multiple SGPs and multiple SGs
cases and
> > this requires a clear cut view of an SG/SGP from an ASP's point of view.
> >
> > From an ASP's view point, SG has a single point code, (SG may be having
> > multiple point codes appearing in the SS7 network), while an SGP is one
of the
> > computing element that forms an SG and may be required for distributed
> > processing or otherwise at SG.  In particular SG is a logical entity
while SGP
> > is a physical machine.
> >
> > As Greg has correctly pointed out, it makes no sense to host more than
one
> > SGPs on a signle physical machine for network redundancy (because SCTP
> > multihoming feature can take care of this). However, a big SG could
clearly be
> > built using multiple machines (probably dispersed geographically) in
virtual
> > synchrony in which scenario the set of machines form the logical SG
while each
> > machine individually classifes as an SGP. It is understood that all the
SGPs
> > take great pains to coordinate themselves with regard to MTP3 & SPMC
state to
> > the SS7 network and AS/ASP state to the IP side. In effect the SS7 side
view
> > and IP side view at each SGP is same.
> >
> > Now that we agree on this definition, the question should be framed as,
if all
> > the SGPs are in complete sync, does it make sense to expose multiple SGP
view
> > to the ASP i.e. can ASP or SG derive any benefit out of this?
> >
> > cheers,
> > Anal.
> >
> >
> > Get 250 color business cards for FREE!
> > http://businesscards.lycos.com/vp/fastpath/
> >
> >
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to
[email-masked]
>
> --
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
>
>
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]
>
> --------- End Forwarded Message ---------
>
>
>
> Get 250 color business cards for FREE!
> http://businesscards.lycos.com/vp/fastpath/
>
>

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Coene Lode <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Reinventing the Wheel
Date: Mon, 11 Jun 2001 13:13:14 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades6.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mailhost2.atea.be [194.78.143.126]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: Reinventing the Wheel</TITLE> </HEAD>
<BODY>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT> <BR><FONT SIZE=2>&gt;
From: Brian F. G. Bidulock [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: maandag 11 juni 2001 11:39</FONT> <BR><FONT
SIZE=2>&gt; To: sigtran</FONT> <BR><FONT SIZE=2>&gt; Subject: Re:
Reinventing the Wheel</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; John,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I believe that RFC 1006 also maps the ISO Network
Services</FONT> <BR><FONT SIZE=2>&gt; N-Primitives onto TCP.&nbsp; As SCCP
provides no more than the ISO</FONT> <BR><FONT SIZE=2>&gt; N-Primitives, the
RFCs sited would be sufficient, I believe, for</FONT> <BR><FONT SIZE=2>&gt;
these SCCP users as well.</FONT> </P>

<P><FONT SIZE=2>No they ain't.</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Are there any other, more compelling reasons, why the
existing</FONT> <BR><FONT SIZE=2>&gt; ISO work in the IETF and elsewhere has
been discarded?</FONT> <BR><FONT SIZE=2>First of all, they are completely
unknown.</FONT> <BR><FONT SIZE=2>Secondly, they seem to apply to ISO stuff.
As SCCP and TCAP are not part of the rank-and-file ISO protocol suite, they
do not apply. Especiallly the part that are most used by SCCP are simply not
supported in those RFC'. That should answer the question.</FONT></P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; It just doesn't make much sense to me on the surface
to</FONT> <BR><FONT SIZE=2>&gt; take an ISO Network Service interface and,
rather than</FONT> <BR><FONT SIZE=2>&gt; implementing it over TCP/IP,
attempting to implement an SS7-</FONT> <BR><FONT SIZE=2>&gt; specific SCCP
in between the ISO interface and SCTP,</FONT> <BR><FONT SIZE=2>&gt;
particularly when SS7 went to so much trouble in the first</FONT> <BR><FONT
SIZE=2>&gt; place to provide ISO Network Services interface to SCCP.</FONT>
</P>

<P><FONT SIZE=2>That is the first time I've ever heard of that. The last I
heard about ISO stuff trying to get incorporated in SS7 was when there was
talk about supporting ISO NSAP addresses in SCCP addressing. Never came to
anything. SCCP to date only supports usefull addresses.</FONT></P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Could you perhaps humor me with several compelling
technical</FONT> <BR><FONT SIZE=2>&gt; reasons for doing so?</FONT> </P>

<P><FONT SIZE=2>Hope it gave you a good laugh. Always happy to be of service
:-)</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; --Brian</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; On Mon, 11 Jun 2001, [email-masked]
wrote:</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Hi Brian,</FONT> <BR><FONT SIZE=2>&gt; &gt;
</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Which SCCP users are those that are other
than TCAP?</FONT> <BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; RANAP and RNSAP (radio access network control
plan protocols)</FONT> <BR><FONT SIZE=2>&gt; &gt; as defined by 3GPP.&nbsp;
The references are as follows:</FONT> <BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; [RANAP] &nbsp;&nbsp;&nbsp; 3G TS 25.413 V3.5.0
(2001-03) 'Technical </FONT> <BR><FONT SIZE=2>&gt; Specification 3rd</FONT>
<BR><FONT SIZE=2>&gt; &gt; Generation Partnership Project; Technical
Specification </FONT> <BR><FONT SIZE=2>&gt; Group Radio Access</FONT>
<BR><FONT SIZE=2>&gt; &gt; Network; UTRAN Iu Interface RANAP
Signalling'</FONT> <BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; [UTRAN IUR] 3G TS 25.422 V3.5.0 (2000-12)
&quot;Technical </FONT> <BR><FONT SIZE=2>&gt; Specification 3rd</FONT>
<BR><FONT SIZE=2>&gt; &gt; Generation Partnership Project; Technical
Specification </FONT> <BR><FONT SIZE=2>&gt; Group Radio Access</FONT>
<BR><FONT SIZE=2>&gt; &gt; Network; UTRAN Iur Interface Signaling Transport
(Release 1999)&quot;</FONT> <BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; br,</FONT>
<BR><FONT SIZE=2>&gt; &gt; John</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -- </FONT>
<BR><FONT SIZE=2>&gt; Brian F. G. Bidulock</FONT> <BR><FONT SIZE=2>&gt;
[email-masked]</FONT> <BR><FONT SIZE=2>&gt; <A
HREF="http://www.openss7.org/"
TARGET="_blank">http://www.openss7.org/</A></FONT> <BR><FONT SIZE=2>&gt;
</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>Yours sincerly,</FONT> <BR><FONT SIZE=2>Lode</FONT>
</P>

<P><FONT SIZE=2>Siemens Atea ICN D CS D</FONT> <BR><FONT SIZE=2>Software
Development </FONT> <BR><FONT SIZE=2>Atealaan 34&nbsp;&nbsp;&nbsp;&nbsp;
</FONT> <BR><FONT SIZE=2>B-2200&nbsp;&nbsp;&nbsp;
Herentals&nbsp;&nbsp;&nbsp;
Belgium&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>Tel +32-14-25-2081&nbsp;&nbsp; /&nbsp; Fax +32-14-25-3212</FONT>
<BR><FONT SIZE=2>E-mail:&nbsp;&nbsp; [email-masked]</FONT> </P>

---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY>
</HTML>

</x-html>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Mon, 11 Jun 2001 07:23:18 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: IUA issues draft
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

All:

For those interested in IUA, you may want to review 

draft-morneault-sigtran-iua-issues-00.txt

It contains a summary of all issues found in IUA (RFC3057).

The draft was recently posted to the IETF web site, but for some reason was
not announced on this list.

Regards,

Ken

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Mon, 11 Jun 2001 11:53:11 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA draft 7 questions (SCTP congestion at ASP)
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

..snip...

see comments below.

>I would still like to see the addition of a Correlation Id and
>a Correlation Id Ack so that the implementor of the M2UA may be
>able to coorination the splitting of the RB, TB and RTB across
>the SCTP association as alluded to by Al Varney in his note of
>November 30th.  Using the acknolwedged data service available
>in some SCTP implementations is not sufficient, because it is
>based on a 16-bit stream sequence number where 24-bits are likely
>called for.
>
>There is also the difficulty in the current use of M2UA to place
>an SS7 link in a single stream, that the data rate may demand
>a stream sequence number with wider range than 16 bits.  A case
>in point is Q.703 Annex A operation where a 24 bit sequence number
>is required to permit a wide enough window for acknolwedgement.
>Also, because M2UA has not been restricted from interworking
>with MTP3b links, SCTP's restricted SSN range may be quite
>problematic.
>
>Therefore, I would like to see the M2UA recommendation permit the
>implementation to split the SLS components of link onto separate
>streams (in an open fashion such as M3UA allows) in an attempt to
>extend the 16-bit SCTP SSN by the number of bits of the SLS (4 or 5)
>for use with high speed links.

Currently, an implementation can distribute message traffic across SCTP
streams in this fashion.  The document does recommend a stream per link, but
does not require it.  I can expand the recommendation for high speed links.

>The Correlation Id has another purpose.  It is to permit an
>M2UA/MTP2 implementation to receive acknowledgements from an
>MTP3/M2AU (Correlation Id Ack) when MSUs have been received.  This
>permits the splitting of the RB across the SCTP assoc.
>
>It also would permit MTP3/M2UA to receive acknowledgements from
>M2UA/MTP2 when messages have been accepted by M2UA or possibly when
>they have been acknolwedged to MTP2.  This would permit the
>splitting of the TB/RTB across the SCTP assoc.
>
>These parameters would permit an implementor to handle the RB/TB/RTB
>in a number of different implementation dependent fashions which
>could possibly be more in fitting with both the implementation's
>MTP2 and MTP3's expectations for buffer handling (SIPO, SIB, and
>Transmit Congestion).
>
>(I don't belive that Jacob should have a problem with this one,
>he proposed a similar arrangement last year.)
>
>The Correlation Id should be optional to generate, but invoke a
>mandatory response for the sake of improved interoperability.
>See the proposed text which I provided for M3UA.

Is it feasible to have inter-operability between a SG and MGC if one side
makes use of Correlation ID and the other doesn't (i.e. one designs
RB/TB/RTB to be split across the SCTP association and the other does not).

Are there others that plan (or would be interested) in making use of a
Correlation ID and Correlation ID Ack?

>--Brian
>
>
>-- 
>Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
>[email-masked]    ¦ world; the unreasonable one persists in  ¦
>http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA: Changes
Date: Mon, 11 Jun 2001 13:49:01 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.59">
<TITLE>RE: M3UA: Changes</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi Brian,</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; My apologies for the delay in responding.&nbsp;
The last week or so was a write-off.&nbsp; Responses below ...</FONT> </P>

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
SIZE=2>From: &nbsp; Brian F. G. Bidulock [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
<BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Thursday, May 31, 2001 8:04 PM</FONT>
<BR><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT> <BR><FONT
SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: M3UA:
Changes</FONT> </P>

<P><FONT SIZE=2>Greg,</FONT>
</P>

<P><FONT SIZE=2>Please see comments below...</FONT> </P>

<P><FONT SIZE=2>(Pardom me, but I won't be gentle.)</FONT> </P>

<P><FONT SIZE=2>On Thu, 31 May 2001, Sidebottom, Greg [BCNR:7M01:EXCH]
wrote:</FONT> </P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Hi Brian,</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Well, I guess I asked for it - thanks for the
very detailed rationale</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
...</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; From:&nbsp;&nbsp; Brian F. G.
Bidulock [[1]<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; Sent:&nbsp;&nbsp; Thursday, May
31, 2001 1:12 PM</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;
To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Re: M3UA: Changes</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;
</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; Greg,</FONT> <BR><FONT
SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; The first paragraph to strike on Page 17 implies that
the NIF</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; should hook into
the MTP Level 3 TSFC function for a</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; destination which in the SEP case is considered local
and has</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; no place in the
function.&nbsp; This paragraph recommends</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; alterations to MTP Level 3 state machines as
described in</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; Q.704 and
other documents.&nbsp; It is not the place of the M3UA</FONT> <BR><FONT
SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; document to recommend changes to MTP
Level 3 standards</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;
documents, even in passing, not to mention that the operation</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; of the TSFC is *not* considered
&quot;implementation dependent&quot;.</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; It has already been cited that &quot;current MTP3
procedures&quot; do</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; not
allow the proscribed action in the SEP case for some</FONT> <BR><FONT
SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; variants.&nbsp; It is certainly not the
place of the M3UA document</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; to proscribe an actions which, with the exception of
ANSI, is</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; prohibited by
the SS7 standards.</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; [Greg]&nbsp;&nbsp;&nbsp; Very
colorful!&nbsp; OK - I agree with your point that this</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; paragraph covers only an STP-like case - it
definitely needs a change</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; to
be more general, taking into account the SEP-like case, and</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; mentioning that appropriate SG behavior needs
take into account the</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
different MTP3 variants and the architecture.&nbsp; That would improve
it</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; as a &quot;blanket
statement&quot;.&nbsp; Or I think there may be some text covering</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; this in other sections, which may be
sufficient to allow removal -</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
I'll take a look.</FONT> </P>

<P><FONT SIZE=2>I believe that the text is inappropriate for the STP case as
well.</FONT> <BR><FONT SIZE=2>This is because in the STP case, the NIF must
interface with more</FONT> <BR><FONT SIZE=2>than just the &quot;top&quot; of
the MTP Level 3.&nbsp; You are reaching into</FONT> <BR><FONT SIZE=2>routing
functions and other things.&nbsp; Attempting to discuss the</FONT> <BR><FONT
SIZE=2>needs and functions of the MTP Level 3 to NIF interface is
taking</FONT> <BR><FONT SIZE=2>a step towards specifying the NIF.&nbsp; The
NIF is intentionally scoped</FONT> <BR><FONT SIZE=2>out of the document, so
why talk about it?&nbsp; The NIF is the implementor's</FONT> <BR><FONT
SIZE=2>responsibility.&nbsp; M3UA should just address whether the necessary
set</FONT> <BR><FONT SIZE=2>of syntactic elements exist.</FONT> </P>

<P><FONT SIZE=2>[Greg2]&nbsp; I'll agree that the paragraph probably goes
too far into describing an SG internal function, given the
discussion.&nbsp;&nbsp; We tried not to talk about the NIF entity when it
came to management text as it is obviously a very slippery slope, but
readers are &quot;implying&quot; it anyway.&nbsp; Should we not say
something generic here though?&nbsp;&nbsp; I haven't seen a rush to defend
the text but for some MTP3 variants it is possible for an SS7 node (SEP-like
model) to send an indication of congestion (TFC) into the SS7 network.&nbsp;
For the STP-like model it is possible in all variants.&nbsp;&nbsp; If no-one
else cares though I will certainly delete the paragraph.</FONT></P> <BR>

<P><FONT SIZE=2>Further, in networks which do not support multiple
congestion levels,</FONT> <BR><FONT SIZE=2>TFC is the equivalent of a
targetted TFP.&nbsp; The sender will not send</FONT> <BR><FONT
SIZE=2>signalling network or traffic management messages until the
congestion</FONT> <BR><FONT SIZE=2>clears.&nbsp; This does not properly
reflect the case of the STP SG, which</FONT> <BR><FONT SIZE=2>is still able
to process signalling network and traffic management</FONT> <BR><FONT
SIZE=2>messages on behalf of the SPMC.&nbsp; It is, you see, only the user
parts</FONT> <BR><FONT SIZE=2>which are congested.</FONT> </P>

<P><FONT SIZE=2>[Greg2]&nbsp;&nbsp; For this case I don't believe that
reception of a TFC causes the sender to cut back on sending MTP3 management
messages, if that is what you are saying.&nbsp; Per Q.704 international
method the congestion indication is simply handed up to the MTP3-User and no
state is retained in the MTP3.&nbsp;&nbsp; We probably agree anyway that the
semantics of any TFC sent from an SG should conform to the MTP3 protocol
variant of the network and take into account its position architecturally
(e.g., SEP-like or STP-like).</FONT></P> <BR>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; I disagree that it has any impact on the MTP3
standards.&nbsp; It is</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
nothing more than what current distributed MTP3-processor nodes do</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; today.&nbsp; Data on
congested/unavailable destinations/User Parts or local</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; resources usually needs to be disseminated to
all the MTP3 management</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
instance(s).&nbsp; I don't see this as a change to the MTP3
standards,</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; which really
assume a monolithic all-knowing MTP3 layer.&nbsp; A Gateway is</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; under an obligation to ensure that
all the network management</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
instances on both sides are &quot;synchronized&quot; and
&quot;coordinated&quot; (maybe</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; not the best wording).&nbsp; Both network
management sides somehow need to</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; take into account events on the other side or
on other processors on</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; the
same side.&nbsp; How they propagate this is implementation dependent.</FONT>
</P>

<P><FONT SIZE=2>It affects standards because in the STP case it is clear
what the</FONT> <BR><FONT SIZE=2>triggers are for sending TFC in the
standards documents.&nbsp; M3UA events</FONT> <BR><FONT SIZE=2>are not among
them.&nbsp; (Not to mention that, again, your are starting</FONT> <BR><FONT
SIZE=2>to specify the NIF).</FONT> </P>

<P><FONT SIZE=2>[Greg2]&nbsp; Agree with your parenthetical remark.&nbsp; Of
course the MTP3 standards do not take into account M3UA events - this was
obviously not foreseen.&nbsp; But as long as an SG vendor ensures that when
triggering a TFC based on an M3UA event that the TFC is appropriate, no
changes are needed to the MTP3 standard.&nbsp; The reception of a TFC from
an SG should be treated exactly the same way as from any other node.&nbsp;
</FONT></P> <BR>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; The second paragraph to strict on Page 17 implies
that the NIF</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; should hook
into the MTP Level 3 TSFC function for a</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; destination which in the SEP case is considered local
and has</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; no place in the
function.&nbsp; This paragraph also recommends</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; alterations to MTP Level 3 state machines.&nbsp;
&quot;Current MTP3</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;
procedures&quot; do not allow the proscribed action in the SEP</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; case.&nbsp; SEP's do not send
TFP for their point code or alias</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; point codes.</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; [Greg] I agree with your last statement, but I
think the text is</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; pretty
clear that the TFP is sent only for the case of the SG acting</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &quot;as an STP&quot;.&nbsp;&nbsp; I
can't imagine why MTP3 management at an SEP or STP</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; would internally maintain routes to itself so
I thought it obvious</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; that an
SG wouldn't mark a route unavailable to an affected</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; destination that includes itself.&nbsp;&nbsp;
This could be made clearer though.</FONT> </P>

<P><FONT SIZE=2>No. This is not applicable in the STP case either.&nbsp; The
SG is responsible</FONT> <BR><FONT SIZE=2>for the MTP management for the
SPMC point code.&nbsp; As a result, the SG</FONT> <BR><FONT SIZE=2>is still
capable of processing all signalling network management messages</FONT>
<BR><FONT SIZE=2>which are adddressed to the SPMC point code.&nbsp; Sending
TFP will shut these</FONT> <BR><FONT SIZE=2>off.&nbsp; The ASP is *not*
responsible for SPMC signalling network management,</FONT> <BR><FONT
SIZE=2>it only provide an MTP-User part service.&nbsp; Therefore, when all
ASPs in the</FONT> <BR><FONT SIZE=2>AS are down, it is merely the case that
all user parts of the SPMC are</FONT> <BR><FONT SIZE=2>unavailable.&nbsp;
The MTP entity (signalling network and traffic management)</FONT> <BR><FONT
SIZE=2>are still alive and kicking.&nbsp; The view that unavailable user
parts equates</FONT> <BR><FONT SIZE=2>to and unavailable MTP is false
logic.</FONT> </P>

<P><FONT SIZE=2>[Greg2] This is not my view.&nbsp; How does the sending of a
TFP shut down signalling network management messages to the SG?&nbsp; As you
say the SG MTP3 is still available.&nbsp; I have a feeling you will say that
the ASPs do not have an MTP3 but I don't think that is relevant. The TFP is
coming from the SG's Point Code to an adjacent SS7 SP.&nbsp; The SP has no
reason to send MTP3 management messages to any other Point Codes.</FONT></P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; Furthermore, the recommendations of the second
paragraph are</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; in error
for the case described.&nbsp; When all of the ASPs in a</FONT> <BR><FONT
SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; SPMC are down, there still exists at the
SEP SG the MTP Level</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; 3
Signalling Network Management functions.&nbsp; It is just the</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; MTP-Users which have gone away
when all of the ASPs are down.</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; There is no ASP for the Signalling Network Management
function</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; and as far as
the SS7 network is concerned, the signalling</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; point code is still available.&nbsp; That is, the SG
can still</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; receive SNM
messages addressed to the SPMC's point code and</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; process them on its behalf.&nbsp; Sending TFP in this
case is</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; completely
inappropriate, an appropriate action on the part of</FONT> <BR><FONT
SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; the SG would be to send UPU's for all of
the unavailable user</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;
parts when they receive messages.</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; [Greg]&nbsp; I think we are mixing up the
cases here - the second</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
paragraph, especially when talking about TFPs, is covering the</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; STP-like case (i.e., where the SG is
not included in the SPMC).&nbsp;&nbsp; The</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; STP-like case is analogous to an SS7 STP -
when all of the routes to</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; an
affected destination are down, the STP still has its MTP Level 3</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; management functions.&nbsp;
Actually, sending of either a TFP or UPU does</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; not imply that the MTP3 management is down,
just than an ongoing</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
&quot;route&quot; is unavailable.&nbsp; If the ASPs are/were handling
multiple</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; MTP3-Users (e.g,
ISUP and SCP) and all of them are unavailable perhaps</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; TFP is better (again assuming the MTP3 variant
and architecture</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; doesn't
preclude it).&nbsp; I agree with you for the SEP case as I stated</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; above, but again I'm not sure why
the SG MTP3 would be maintaining the</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; state of a route to itself in any case, so it
would not really be in a</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
position to send a TFP about itself.</FONT> </P>

<P><FONT SIZE=2>No.&nbsp; As described above, the continued availability of
signalling network</FONT> <BR><FONT SIZE=2>and traffic management functions
at the SG for the concerned SP indicate</FONT> <BR><FONT SIZE=2>that the SP
MTP has not been isolated and TFP is not called for.&nbsp; The ASPs</FONT>
<BR><FONT SIZE=2>(user parts) have been isolated and should be reported as
unavailable.</FONT> <BR><FONT SIZE=2>This is what you get when you place the
MTP on the SG and merely remote</FONT> <BR><FONT SIZE=2>the MTP to MTP-User
interface to the ASP, regardless of whether you are</FONT> <BR><FONT
SIZE=2>talking about the SEP case or the STP case (which I would like to
discuss</FONT> <BR><FONT SIZE=2>alot further anyway ;).</FONT> </P>

<P><FONT SIZE=2>[Greg2] See above.&nbsp; Assuming I am understanding your
point, a TFP does not isolate the MTP3.</FONT> </P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; The third paragraph is just as incorrect because SEPs
do not</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; send TFA's and
TFA's are only sent when the SNM at the SPMC</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; becomes available at the SG an not when user parts
become</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; available.</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; [Greg] Same point as above.</FONT> </P>

<P><FONT SIZE=2>Same as above.</FONT>
</P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; Furthermore, user part documents are full of
descriptions of</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; what
actions should be taken with respect to the SS7 network</FONT> <BR><FONT
SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; should the user part become isolated from
the MTP.&nbsp; For ISUP,</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;
see GR-317-CORE and Q.764/767.</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; [Greg] How do these User Parts determine that
they are isolated from</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; the
SS7 network?&nbsp; There is no primitive defined for this -</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; MTP-PAUSE?.&nbsp; Of course I am only being
half serious - this is</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
something I have really struggled with.&nbsp; Vendors have generally</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; implemented MTP3-to-MTP3_User
interfaces that have something to manage</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; this isolation inside an SS7 SEP, or now in
the ASP.&nbsp; We could add a</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
new primitive but that would be changing the MTP3 standard.</FONT> </P>

<P><FONT SIZE=2>The user parts do not determine that they are isolated from
the SS7</FONT> <BR><FONT SIZE=2>network, they determine that they are
isolated from MTP.&nbsp; I.e, that</FONT> <BR><FONT SIZE=2>they are unable
to transfer prmitives across the L4 - L3 interface.</FONT> <BR><FONT
SIZE=2>This is implementation dependent of course, but in the M3UA</FONT>
<BR><FONT SIZE=2>*implementation* isolation can easily be determined at the
ASP by</FONT> <BR><FONT SIZE=2>the state of communications with the SG(s)
and the state of other</FONT> <BR><FONT SIZE=2>ASPs in the AS.&nbsp; I don't
mind the default ASP approach as long as</FONT> <BR><FONT SIZE=2>the default
ASP is coincident with the SGP.</FONT> </P>

<P><FONT SIZE=2>[Greg2] Like you say it is implementation dependent.&nbsp;
The ASP M3UA can now determine that it is isolated but my point was that the
M3UA still has the same limited primitives to the resident
MTP3-User.</FONT></P> <BR>

<P><FONT SIZE=2>If you are talking about isolation from the SS7 network,
the</FONT> <BR><FONT SIZE=2>implementation dependent functions
MTP-RESTART-BEGINS and</FONT> <BR><FONT SIZE=2>MTP-RESTART-ENDS are a good
start.&nbsp; These are not primitives per se</FONT> <BR><FONT
SIZE=2>(although MTP-RESTART-ENDS is alluded to in the SS7 specs), but
M3UA</FONT> <BR><FONT SIZE=2>already has the DUNA and DAVA with an mask of
24 to cover both these</FONT> <BR><FONT SIZE=2>cases.</FONT>
</P>

<P><FONT SIZE=2>[Greg2] Agree - this was the intent.&nbsp; The ASP still has
the MTP3-to-MTP3-User interface and this is not changed.&nbsp; </FONT> </P>

<P><FONT SIZE=2>It is very important to understand that an AS being
separated from</FONT> <BR><FONT SIZE=2>an SG, in either the SEP or STP case,
is an MTP User Part being</FONT> <BR><FONT SIZE=2>separated from MTP and
*not* MTP being separated from the SS7</FONT> <BR><FONT
SIZE=2>network.&nbsp; The point being that your Signalling Point
Management</FONT> <BR><FONT SIZE=2>Cluster concept must also include the
SG.</FONT> </P>

<P><FONT SIZE=2>[Greg2] I understand you - I think we only differ
philosophically in the internal model within the SG.&nbsp; In my model not
all SPMCs have to include the SG.&nbsp; An SPMC not including the SG does
not imply that the ASPs making it up are (virtually) running an MTP3.&nbsp;
I'm not sure if it is worth debating these models as I think we end up with
the same result.</FONT></P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; The last sentences in the forth paragraph attempt to
place a</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; requirement on
the semantics of the MTP to MTP-User interface</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; by requiring that MTP-PAUSE and MTP-RESUME change
only when</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; status
changes.&nbsp; It is not the place of the M3UA document to</FONT> <BR><FONT
SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; place requirements on an interface
standardized by other</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;
documents and where the semantics are adequately explained.</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; [Greg]&nbsp;&nbsp; OK - I agree the word
&quot;only&quot; is too restrictive - there are</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; also cases where PAUSE is sent upon reception
of a messages from the</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; upper
layer.&nbsp;&nbsp;&nbsp; This text was added because some people
originally</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; thought that TFPs
or TFRs or TFAs from the MTP3 network were received</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; by the MTP3 management and simply encapsulated
and passed on to the</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
ASPs.&nbsp; This would be bad.&nbsp; These sentences tried to make it
explicit</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; that these messages
were processed by MTP3 management.</FONT> </P>

<P><FONT SIZE=2>My point: there is no place in an M3UA document to
outline</FONT> <BR><FONT SIZE=2>the responsibilities of MTP Level 3 as they
are adequately</FONT> <BR><FONT SIZE=2>explained in the standards
documents.&nbsp; Rather than attempting</FONT> <BR><FONT SIZE=2>to
&quot;teach&quot; readers about MTP Level 3, citing the appropriate</FONT>
<BR><FONT SIZE=2>standards should be sufficient.</FONT> </P>

<P><FONT SIZE=2>[Greg2] OK, the text was just trying to help with
interoperability.&nbsp; Do you still propose to delete or should the
clarification now point to an MTP3 reference?</FONT></P>

<P><FONT SIZE=2>Cheers,</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; Greg Sidebottom</FONT> </P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; So, I suppose it is not the specificity of the
statements</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; which make me
call to have them struck, but that they are</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; erroneous, misrepresentative, and
inappropriate.</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; --Brian</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; [Greg] Well I guess a little hyperbole never
hurt anyone.&nbsp;&nbsp; Please</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Brian, don't hold back - please tell us all
what you really think!</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
2;^)</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; With appropriate changes to take into account
Brian's technical</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; comments,
and covering the SEP case more explicitly, would the</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; paragraphs be useful or would people prefer
them struck?</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Cheers,</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Greg</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> </P>

<P><FONT SIZE=2>Let me dig into this a little bit further...&nbsp; Let's
attempt to</FONT> <BR><FONT SIZE=2>rewrite one of the paragraphs so that
they make sense.&nbsp; Let's</FONT> <BR><FONT SIZE=2>take the TFP
paragraph.&nbsp; Here is my rewriting:</FONT> </P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When the SG
determines that the transport and processing</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SS7 signalling network
management, signalling traffic</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; management and signalling
test management messages for</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a particular signalling
point are interrupted, if the SG</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is equipped with the
transfer function, the SG SHOULD</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mark the signalling point
as unavailable via the pseudo-</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; M3UA route set per local
MTP procedures.&nbsp; If the SG offers</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; route sets to the affected
signalling point, and if the</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; affected signalling point
is not itself a signalling point</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; which contains the
transfer function, and if the SG has</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; no other route to the
affected signalling point (i.e,</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; over C-links) and if the
signalling point(s) to which the</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SG offers signalling
route(s) to the affected signalling</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; point are not themselves
unavailable then the SG MAY send</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a tranfer prohibited
message to the available signalling</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; points to which it offers
route(s) to the affected</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; signalling point.&nbsp; If
the SG has another route to the</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; affected signalling point
via a signalling route with a</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; lower priority than the
newly affected route set, the</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SG MAY send a transfer
prohibited message on this route</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; set and MAY (if the MTP is
equipped with the optional</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; transfer-restricted
option) send a transfer restricted</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; message to the available
adjacent signalling points to</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; which the SG offers a
route to the affected signalling</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; point.</FONT> </P>

<P><FONT SIZE=2>To be accurate I would literally have to quote a
significant</FONT> <BR><FONT SIZE=2>portion of the Q.704 and other MTP
standards, including most</FONT> <BR><FONT SIZE=2>of the definitions.</FONT>
</P>

<P><FONT SIZE=2>I suggest you leave it alone.</FONT> </P>
<BR>

<P><FONT SIZE=2>-- </FONT>
<BR><FONT SIZE=2>Brian F. G. Bidulock&nbsp;&nbsp;&nbsp; ¦ The reasonable man
adapts himself to the ¦</FONT> <BR><FONT
SIZE=2>[email-masked]&nbsp;&nbsp;&nbsp; ¦ world; the unreasonable one
persists in&nbsp; ¦</FONT> <BR><FONT SIZE=2><A
HREF="http://www.openss7.org/" TARGET="_blank">http://www.openss7.org/</A> ¦
trying&nbsp; to adapt the&nbsp; world&nbsp; to himself. ¦</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ¦
Therefore&nbsp; all&nbsp; progress&nbsp; depends on the ¦</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ¦
unreasonable man. -- George Bernard Shaw ¦</FONT> </P>

---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY>
</HTML>

</x-html>
Date: Mon, 11 Jun 2001 14:37:43 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA: Changes
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.213]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

Please see additional comments below...

On Mon, 11 Jun 2001, Sidebottom, Greg [BCNR:7M01:EXCH] wrote:
> 
>    Hi Brian,
>    
>       My apologies for the delay in responding.  The last week
>    or so was a write-off.  Responses below ...
>    
>>     -----Original Message-----
>>    From:   Brian F. G. Bidulock [[1]mailto:[email-masked]]
>>    Sent:   Thursday, May 31, 2001 8:04 PM
>>    To:     sigtran
>>    Subject:        Re: M3UA: Changes
>>    
>>    Greg,
>>    
>>    Please see comments below...
>>    
>>    (Pardom me, but I won't be gentle.)
>>    
>>    On Thu, 31 May 2001, Sidebottom, Greg [BCNR:7M01:EXCH] wrote:
>>    
>>>
>>>    Hi Brian,
>>>
>>>    Well, I guess I asked for it - thanks for the very
>>>    detailed rationale ...
>>>
>>>>     -----Original Message-----
>>>>    From:   Brian F. G. Bidulock [[1][2]mailto:[email-masked]]
>>>>    Sent:   Thursday, May 31, 2001 1:12 PM
>>>>    To:     sigtran
>>>>    Subject:        Re: M3UA: Changes
>>>>
>>>>    Greg,
>>>>
>>>>    The first paragraph to strike on Page 17 implies that the
>>>>    NIF should hook into the MTP Level 3 TSFC function for a
>>>>    destination which in the SEP case is considered local and
>>>>    has no place in the function.  This paragraph recommends
>>>>    alterations to MTP Level 3 state machines as described in
>>>>    Q.704 and other documents.  It is not the place of the M3UA
>>>>    document to recommend changes to MTP Level 3 standards
>>>>    documents, even in passing, not to mention that the
>>>>    operation of the TSFC is *not* considered "implementation
>>>>    dependent".  It has already been cited that "current MTP3
>>>>    procedures" do not allow the proscribed action in the SEP
>>>>    case for some variants.  It is certainly not the place of
>>>>    the M3UA document to proscribe an actions which, with the
>>>>    exception of ANSI, is prohibited by the SS7 standards.
>>>
>>>    [Greg]    Very colorful!  OK - I agree with your point that
>>>    this paragraph covers only an STP-like case - it definitely
>>>    needs a change to be more general, taking into account the
>>>    SEP-like case, and mentioning that appropriate SG behavior
>>>    needs take into account the different MTP3 variants and the
>>>    architecture.  That would improve it as a "blanket
>>>    statement".  Or I think there may be some text covering this
>>>    in other sections, which may be sufficient to allow removal -
>>>    I'll take a look.
>>    
>>    I believe that the text is inappropriate for the STP case as
>>    well.  This is because in the STP case, the NIF must interface
>>    with more than just the "top" of the MTP Level 3.  You are
>>    reaching into routing functions and other things.  Attempting
>>    to discuss the needs and functions of the MTP Level 3 to NIF
>>    interface is taking a step towards specifying the NIF.  The
>>    NIF is intentionally scoped out of the document, so why talk
>>    about it?  The NIF is the implementor's responsibility.  M3UA
>>    should just address whether the necessary set of syntactic
>>    elements exist.
>    
>    [Greg2]  I'll agree that the paragraph probably goes too far
>    into describing an SG internal function, given the discussion.
>    We tried not to talk about the NIF entity when it came to
>    management text as it is obviously a very slippery slope, but
>    readers are "implying" it anyway.  Should we not say something
>    generic here though?   I haven't seen a rush to defend the text
>    but for some MTP3 variants it is possible for an SS7 node
>    (SEP-like model) to send an indication of congestion (TFC) into
>    the SS7 network.  For the STP-like model it is possible in all
>    variants.   If no-one else cares though I will certainly delete
>    the paragraph.

Greg, why do you keep saying TFC?  TFC is an MTP3 peer-to-peer message whose
use and procedures are defined in SS7 specifications.
It implies that an NIF could be conceived of which does not contain a fully
functioning MTP Level 3 at the SG, and that some simple little protocol
conversion box could just sent TFC.

I believe that what you are trying to indicate is that the NIF tells MTP3 in
some implementation depedent way that it has detected an MSU which was to be
routed on a congested link, or somehow spliced into the HMRT functions.
Then MTP3 decides, per appropriate standards whether and when to launch a
TFC.

However, if the SPMC is considered local to the SG, there is no HMRT
function to "splice into".  It is only the HMDT function in MTP3 which
provides access to MTP users.  There is no way of "splicing into" the HMDT
function with a congestion indication as MTP3 is defined.

You muddy the picture by making reference to the detection of an event in
M3UA and them mapping it onto an MTP3 message which is seen on the other
side of MTP3.  You cannot make statements like this without placing implicit
restrictions on the procedures of MTP3.  See the following diagram:

                +------------------+
                |       NIF        |
                +-------+-+--------+
                | MTP3  | |  M3UA  |
                +-------+ +--------+<-- (A)
                | MTP2  | |  SCTP  |
                +-------+ +--------+
                | MTP1  | |   IP   |
        (B)     +-------+ +--------+
         |          |          |
         V          |          |
    ----------------+

The language is mapping an event detected at (A) congestion in the diagram
onto a message sent at (B).  This has the effect of dictating the behavior
of the NIF and MTP3, and the text uses the word "should".

Furthermore, the text says "parts of an SPMC".  Why would one ever want to
trigger transfer-controlled procedures for parts of an SPMC?  It doesn't
make any sense to me.  What is this supposed to mean in relation to MTP3
procedures at the SG?

The text also says "should inform the MTP3 route management function (by an
implementation dependent mechanism)".

Get rid of the "should" and identify the "implementation dependent
mechanism" which has already been defined in the reference architecture as
the NIF.  This really translates directly to `the NIF SHOULD inform MTP3
route management of M3UA congestion' which is why I object to the text.
M3UA SHOULD NOT be specifying the behavior of the NIF in this lapsidasical
fashion (not giving consideration to all the other issues faced by the NIF
implementor).

Quite frankly, the real case is that when the SG M3UA encounters congestion,
the NIF can do what it likes and the MTP3 will act as it will, because it is
outside the scope of the document.

Yes, please strike the paragraph.  I have not heard anyone defend it either.

>    
>>    Further, in networks which do not support multiple congestion
>>    levels, TFC is the equivalent of a targetted TFP.  The sender
>>    will not send signalling network or traffic management
>>    messages until the congestion clears.  This does not properly
>>    reflect the case of the STP SG, which is still able to process
>>    signalling network and traffic management messages on behalf
>>    of the SPMC.  It is, you see, only the user parts which are
>>    congested.
>    
>    [Greg2]   For this case I don't believe that reception of a TFC
>    causes the sender to cut back on sending MTP3 management
>    messages, if that is what you are saying.  Per Q.704
>    international method the congestion indication is simply handed
>    up to the MTP3-User and no state is retained in the MTP3.   We
>    probably agree anyway that the semantics of any TFC sent from
>    an SG should conform to the MTP3 protocol variant of the
>    network and take into account its position architecturally
>    (e.g., SEP-like or STP-like).

See above.  By the very nature that the text says "TFC", you are faced with
qualifying the statement based on MTP3 variants and SS7 network
configuration.  It is sufficient that M3UA may tell the NIF about the
congestion that it has detected and it is the NIF's (and NIF implementor's)
responsibility for making whatever communications needs be made to MTP3.

>    
>>>
>>>    I disagree that it has any impact on the MTP3 standards.  It
>>>    is nothing more than what current distributed MTP3-processor
>>>    nodes do today.  Data on congested/unavailable
>>>    destinations/User Parts or local resources usually needs to
>>>    be disseminated to all the MTP3 management instance(s).  I
>>>    don't see this as a change to the MTP3 standards, which
>>>    really assume a monolithic all-knowing MTP3 layer.  A Gateway
>>>    is under an obligation to ensure that all the network
>>>    management instances on both sides are "synchronized" and
>>>    "coordinated" (maybe not the best wording).  Both network
>>>    management sides somehow need to take into account events on
>>>    the other side or on other processors on the same side.  How
>>>    they propagate this is implementation dependent.
>>    
>>    It affects standards because in the STP case it is clear what
>>    the triggers are for sending TFC in the standards documents.
>>    M3UA events are not among them.  (Not to mention that, again,
>>    your are starting to specify the NIF).
>    
>    [Greg2]  Agree with your parenthetical remark.  Of course the
>    MTP3 standards do not take into account M3UA events - this was
>    obviously not foreseen.  But as long as an SG vendor ensures
>    that when triggering a TFC based on an M3UA event that the TFC
>    is appropriate, no changes are needed to the MTP3 standard.
>    The reception of a TFC from an SG should be treated exactly the
>    same way as from any other node.

By not qualifying the statement, the "should" makes it appear as though it
is to be generally applied.

Gee, I don't care of the spec says that "the M3UA at the SG MUST inform the
NIF at the SG of any congestion experienced towards an ASP".  (It might even
be a good idea to say this.) Just don't tell the NIF what to do in relation
to MTP.

>    
>>>
>>>>    The second paragraph to strict on Page 17 implies that the
>>>>    NIF should hook into the MTP Level 3 TSFC function for a
>>>>    destination which in the SEP case is considered local and
>>>>    has no place in the function.  This paragraph also
>>>>    recommends alterations to MTP Level 3 state machines.
>>>>    "Current MTP3 procedures" do not allow the proscribed action
>>>>    in the SEP case.  SEP's do not send TFP for their point code
>>>>    or alias point codes.
>>>
>>>    [Greg] I agree with your last statement, but I think the text
>>>    is pretty clear that the TFP is sent only for the case of the
>>>    SG acting "as an STP".   I can't imagine why MTP3 management
>>>    at an SEP or STP would internally maintain routes to itself
>>>    so I thought it obvious that an SG wouldn't mark a route
>>>    unavailable to an affected destination that includes itself.
>>>    This could be made clearer though.
>>    
>>    No. This is not applicable in the STP case either.  The SG is
>>    responsible for the MTP management for the SPMC point code.
>>    As a result, the SG is still capable of processing all
>>    signalling network management messages which are adddressed to
>>    the SPMC point code.  Sending TFP will shut these off.  The
>>    ASP is *not* responsible for SPMC signalling network
>>    management, it only provide an MTP-User part service.
>>    Therefore, when all ASPs in the AS are down, it is merely the
>>    case that all user parts of the SPMC are unavailable.  The MTP
>>    entity (signalling network and traffic management) are still
>>    alive and kicking.  The view that unavailable user parts
>>    equates to and unavailable MTP is false logic.
>    
>    [Greg2] This is not my view.  How does the sending of a TFP
>    shut down signalling network management messages to the SG?  As
>    you say the SG MTP3 is still available.  I have a feeling you
>    will say that the ASPs do not have an MTP3 but I don't think
>    that is relevant. The TFP is coming from the SG's Point Code to
>    an adjacent SS7 SP.  The SP has no reason to send MTP3
>    management messages to any other Point Codes.

Sending TFP will suppress all signalling network management messages
addressed to the affected point code, because it is an SEP.  The signalling
points receiving the TFP should not send any messages whatsoever to the
affected point code, that includes SNMM messages.

Besides the fact that referring to "TFP" is the same as in the diagram above
for "TFC" (it spans both the NIF and MTP), it is not appropriate in the
above regards.

Again, if you say "the M3UA at the SG MUST inform the NIF at the SG of any
ASP unavailabilty towards an AS", then I don't have a problem; however,
there is already a layer management for this purpose.

>    
>>>
>>>>    Furthermore, the recommendations of the second paragraph are
>>>>    in error for the case described.  When all of the ASPs in a
>>>>    SPMC are down, there still exists at the SEP SG the MTP
>>>>    Level 3 Signalling Network Management functions.  It is just
>>>>    the MTP-Users which have gone away when all of the ASPs are
>>>>    down.  There is no ASP for the Signalling Network Management
>>>>    function and as far as the SS7 network is concerned, the
>>>>    signalling point code is still available.  That is, the SG
>>>>    can still receive SNM messages addressed to the SPMC's point
>>>>    code and process them on its behalf.  Sending TFP in this
>>>>    case is completely inappropriate, an appropriate action on
>>>>    the part of the SG would be to send UPU's for all of the
>>>>    unavailable user parts when they receive messages.
>>>
>>>    [Greg]  I think we are mixing up the cases here - the second
>>>    paragraph, especially when talking about TFPs, is covering
>>>    the STP-like case (i.e., where the SG is not included in the
>>>    SPMC). The STP-like case is analogous to an SS7 STP - when
>>>    all of the routes to an affected destination are down, the
>>>    STP still has its MTP Level 3 management functions.
>>>    Actually, sending of either a TFP or UPU does not imply that
>>>    the MTP3 management is down, just than an ongoing "route" is
>>>    unavailable.  If the ASPs are/were handling multiple
>>>    MTP3-Users (e.g, ISUP and SCP) and all of them are
>>>    unavailable perhaps TFP is better (again assuming the MTP3
>>>    variant and architecture doesn't preclude it).  I agree with
>>>    you for the SEP case as I stated above, but again I'm not
>>>    sure why the SG MTP3 would be maintaining the state of a
>>>    route to itself in any case, so it would not really be in a
>>>    position to send a TFP about itself.
>>    
>>    No.  As described above, the continued availability of
>>    signalling network and traffic management functions at the SG
>>    for the concerned SP indicate that the SP MTP has not been
>>    isolated and TFP is not called for.  The ASPs (user parts)
>>    have been isolated and should be reported as unavailable.
>>    This is what you get when you place the MTP on the SG and
>>    merely remote the MTP to MTP-User interface to the ASP,
>>    regardless of whether you are talking about the SEP case or
>>    the STP case (which I would like to discuss alot further
>>    anyway ;).
>    
>    [Greg2] See above.  Assuming I am understanding your point, a
>    TFP does not isolate the MTP3.

It isolates affected PC in the TFP, because it is only sent in response to
isolation.  The affected PC will receive no messages on the route for which
TFP was signalled until TFA is sent.

>    
>>>
>>>>    The third paragraph is just as incorrect because SEPs do not
>>>>    send TFA's and TFA's are only sent when the SNM at the SPMC
>>>>    becomes available at the SG an not when user parts become
>>>>    available.
>>>
>>>    [Greg] Same point as above.
>>    
>>    Same as above.
>>    
>>>
>>>>    Furthermore, user part documents are full of descriptions of
>>>>    what actions should be taken with respect to the SS7 network
>>>>    should the user part become isolated from the MTP.  For
>>>>    ISUP, see GR-317-CORE and Q.764/767.
>>>
>>>    [Greg] How do these User Parts determine that they are
>>>    isolated from the SS7 network?  There is no primitive defined
>>>    for this - MTP-PAUSE?.  Of course I am only being half
>>>    serious - this is something I have really struggled with.
>>>    Vendors have generally implemented MTP3-to-MTP3_User
>>>    interfaces that have something to manage this isolation
>>>    inside an SS7 SEP, or now in the ASP.  We could add a new
>>>    primitive but that would be changing the MTP3 standard.
>>    
>>    The user parts do not determine that they are isolated from
>>    the SS7 network, they determine that they are isolated from
>>    MTP.  I.e, that they are unable to transfer prmitives across
>>    the L4 - L3 interface.  This is implementation dependent of
>>    course, but in the M3UA *implementation* isolation can easily
>>    be determined at the ASP by the state of communications with
>>    the SG(s) and the state of other ASPs in the AS.  I don't mind
>>    the default ASP approach as long as the default ASP is
>>    coincident with the SGP.
>    
>    [Greg2] Like you say it is implementation dependent.  The ASP
>    M3UA can now determine that it is isolated but my point was
>    that the M3UA still has the same limited primitives to the
>    resident MTP3-User.

The mechanism for detection is implementation dependent, the actions to be
taken are explicit and MTP-User specific.

>    
>>    If you are talking about isolation from the SS7 network, the
>>    implementation dependent functions MTP-RESTART-BEGINS and
>>    MTP-RESTART-ENDS are a good start.  These are not primitives
>>    per se (although MTP-RESTART-ENDS is alluded to in the SS7
>>    specs), but M3UA already has the DUNA and DAVA with an mask of
>>    24 to cover both these cases.
>    
>    [Greg2] Agree - this was the intent.  The ASP still has the
>    MTP3-to-MTP3-User interface and this is not changed.
>    
>>    It is very important to understand that an AS being separated
>>    from an SG, in either the SEP or STP case, is an MTP User Part
>>    being separated from MTP and *not* MTP being separated from
>>    the SS7 network.  The point being that your Signalling Point
>>    Management Cluster concept must also include the SG.
>    
>    [Greg2] I understand you - I think we only differ
>    philosophically in the internal model within the SG.  In my
>    model not all SPMCs have to include the SG.  An SPMC not
>    including the SG does not imply that the ASPs making it up are
>    (virtually) running an MTP3.  I'm not sure if it is worth
>    debating these models as I think we end up with the same
>    result.

I think that it is not worth specifying the internal model in the SG in the
M3UA spec, because its specification must include a discussion on the NIF.
By implying an SG model in more than just example (by saying what the NIF
"should" do) brings this matter up.

Why not just say "when the M3UA detects ___(this)___ that it SHOULD (or
MUST) inform Layer Management"????  Gee, isn't that already said somewhere
for ASPs going up and down and congestion being experienced?

Striking these paragraphs permits the NIF implementor access to the set of
events necessary to achieve the implementation of the NIF, without the
constraint of the draft making such assumptions about what the NIF should or
should not do with those events.

>    
>>>
>>>>    The last sentences in the forth paragraph attempt to place a
>>>>    requirement on the semantics of the MTP to MTP-User
>>>>    interface by requiring that MTP-PAUSE and MTP-RESUME change
>>>>    only when status changes.  It is not the place of the M3UA
>>>>    document to place requirements on an interface standardized
>>>>    by other documents and where the semantics are adequately
>>>>    explained.
>>>
>>>    [Greg]   OK - I agree the word "only" is too restrictive -
>>>    there are also cases where PAUSE is sent upon reception of a
>>>    messages from the upper layer.  This text was added because
>>>    some people originally thought that TFPs or TFRs or TFAs from
>>>    the MTP3 network were received by the MTP3 management and
>>>    simply encapsulated and passed on to the ASPs.  This would be
>>>    bad.  These sentences tried to make it explicit that these
>>>    messages were processed by MTP3 management.
>>    
>>    My point: there is no place in an M3UA document to outline the
>>    responsibilities of MTP Level 3 as they are adequately
>>    explained in the standards documents.  Rather than attempting
>>    to "teach" readers about MTP Level 3, citing the appropriate
>>    standards should be sufficient.
>    
>    [Greg2] OK, the text was just trying to help with
>    interoperability.  Do you still propose to delete or should the
>    clarification now point to an MTP3 reference?

Strike them.  The MTP3 documents are already referenced with regard to the
primitive interface between MTP and its Users.

>    
>    Cheers,
>    
>       Greg Sidebottom
>    
>>>
>>>>    So, I suppose it is not the specificity of the statements
>>>>    which make me call to have them struck, but that they are
>>>>    erroneous, misrepresentative, and inappropriate.
>>>>
>>>>    --Brian
>>>
>>>    [Greg] Well I guess a little hyperbole never hurt anyone.
>>>    Please Brian, don't hold back - please tell us all what you
>>>    really think!  2;^)
>>>
>>>    With appropriate changes to take into account Brian's
>>>    technical comments, and covering the SEP case more
>>>    explicitly, would the paragraphs be useful or would people
>>>    prefer them struck?
>>>
>>>    Cheers,
>>>
>>>       Greg
>>>
>>    
>>    Let me dig into this a little bit further...  Let's attempt to
>>    rewrite one of the paragraphs so that they make sense.  Let's
>>    take the TFP paragraph.  Here is my rewriting:
>>    
>>            When the SG determines that the transport and
>>            processing SS7 signalling network management,
>>            signalling traffic management and signalling test
>>            management messages for a particular signalling point
>>            are interrupted, if the SG is equipped with the
>>            transfer function, the SG SHOULD mark the signalling
>>            point as unavailable via the pseudo- M3UA route set
>>            per local MTP procedures.  If the SG offers route sets
>>            to the affected signalling point, and if the affected
>>            signalling point is not itself a signalling point
>>            which contains the transfer function, and if the SG
>>            has no other route to the affected signalling point
>>            (i.e, over C-links) and if the signalling point(s) to
>>            which the SG offers signalling route(s) to the
>>            affected signalling point are not themselves
>>            unavailable then the SG MAY send a tranfer prohibited
>>            message to the available signalling points to which it
>>            offers route(s) to the affected signalling point.  If
>>            the SG has another route to the affected signalling
>>            point via a signalling route with a lower priority
>>            than the newly affected route set, the SG MAY send a
>>            transfer prohibited message on this route set and MAY
>>            (if the MTP is equipped with the optional
>>            transfer-restricted option) send a transfer restricted
>>            message to the available adjacent signalling points to
>>            which the SG offers a route to the affected signalling
>>            point.
>>    
>>    To be accurate I would literally have to quote a significant
>>    portion of the Q.704 and other MTP standards, including most
>>    of the definitions.
>>    
>>    I suggest you leave it alone.
>>    

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Mon, 11 Jun 2001 15:38:35 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: IUA/Q.921/ISUP basic question
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Mike,

ISUP signaling is not a Q.921 user.  ISUP is a User Part of the SS7
protocol.  You may want to look at the M3UA draft
(draft-ietf-sigtran-m3ua-05.txt).

Regards,

Ken

At 02:57 PM 6/11/01 -0400, you wrote:
>Sigtran list members,
>  
>Forgive my novice question regarding the RFC3057, IUA (ISDN Q.921-User
Adaptation Layer)! Anyways, here goes..
>  
>Would I be right in stating that ISUP signaling is a Q.921-user, and can be
transported via IUA?  If so, is ISUP considered a Q.931 protocol?  I
understand that ISUP can be transported via SS7/MTP3,/SCCP, etc but can it
also be sent via IUA?  Maybe I am reading too much into the ISUP acronym
(ISDN User Part).  Can someone help clear the mud for my confused self :)  ?
>  
>Thanks,
>Mike
>  
>
>  
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: IUA/Q.921/ISUP basic question
Date: Mon, 11 Jun 2001 12:44:05 -0700
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: zmamail03.zma.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: zmamail03.zma.compaq.com [161.114.64.103]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: M3UA: Changes</TITLE>

<META content="MSHTML 5.50.4522.1800" name=GENERATOR></HEAD> <BODY>
<DIV><SPAN class=172083519-11062001><FONT face=Arial color=#0000ff
size=2>Mike,</FONT></SPAN></DIV>
<DIV><SPAN class=172083519-11062001><FONT face=Arial color=#0000ff
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=172083519-11062001><FONT face=Arial color=#0000ff size=2>I
don't follow the IUA discussion but I though that I would respond to your
message.</FONT></SPAN></DIV>
<DIV><SPAN class=172083519-11062001><FONT face=Arial color=#0000ff
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=172083519-11062001><FONT face=Arial color=#0000ff
size=2>ISUP is an SS7 protocol.&nbsp; There are interworking specs. out
there that define how ISUP can be converted into Q.921/Q.931 and vis
versa.&nbsp; The bulk of ISUP can be transported by MTP3 (M3UA).&nbsp; There
are a few occasions where ISUP wants to communicate end-to-end with going
through every switch in the path.&nbsp; In these occasions, special ISUP
messages are transported by SCCP.</FONT></SPAN></DIV>
<DIV><SPAN class=172083519-11062001><FONT face=Arial color=#0000ff
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=172083519-11062001><FONT face=Arial color=#0000ff
size=2>You did read to much into the ISUP acronym.</FONT></SPAN></DIV>
<DIV><SPAN class=172083519-11062001><FONT face=Arial color=#0000ff
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=172083519-11062001><FONT face=Arial color=#0000ff
size=2>John</FONT></SPAN></DIV>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Mike Furey 
  [mailto:[email-masked]]<BR><B>Sent:</B> Monday, June 11, 2001
1:58 
  PM<BR><B>To:</B> sigtran<BR><B>Subject:</B> IUA/Q.921/ISUP basic 
  question<BR><BR></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=030184618-11062001>Sigtran list members,</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=030184618-11062001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=030184618-11062001>Forgive my novice question regarding the RFC3057,
IUA 
  (ISDN Q.921-User Adaptation Layer)! Anyways, here
goes..</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=030184618-11062001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=030184618-11062001>Would I be right in stating that ISUP signaling
is a 
  Q.921-user, and can be transported via IUA?&nbsp; If so, is ISUP
considered a 
  Q.931 protocol?&nbsp; I understand that ISUP can be transported via 
  SS7/MTP3,/SCCP, etc but can it also be sent via IUA?&nbsp; Maybe I am
reading 
  too much into the ISUP acronym (ISDN User Part).&nbsp; Can someone help
clear 
  the mud for my confused self :)&nbsp; ?</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=030184618-11062001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=030184618-11062001>Thanks,</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=030184618-11062001>Mike</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=030184618-11062001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=030184618-11062001><BR>&nbsp;</DIV></SPAN></FONT>---<BR>You are 
  currently subscribed to sigtran as: [email-masked]<BR>To
unsubscribe 
  send a blank email to [email-masked]
</BLOCKQUOTE>
---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY></HTML>

</x-html>
Date: Mon, 11 Jun 2001 16:15:53 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: AS state machine sharing between SGPs
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      QAA31124
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-233.dallas.net [209.44.41.233]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Anubhav,

On Mon, 11 Jun 2001, A Srivastav wrote:

> Hi All,
> It should be obvious that SCTP associations can not be synchronized across
> multiple boxes
> But viewing SG as composed of multiple SGPs provides a definite way of
> failover/loadshare facility on the SG side. In my opinion, it makes sense
to
> provide multiple-ASP-in-a-AS kind of semantics for the SGPs as well.

I agree with you 100%.  In fact, I think that it is essential that the SGP
be treated distinctly within an SG and that some SGP management is
necessary.  I also believe that SGP Id and ASP Id are necessary to acheive
this.  I don't believe that either of these need necessarily compromise the
generality of the M3UA framework and would be straightforward to add to the
specification.

> 
> The need for correlation id will arise once we agree that multiple SGPs
can
> exist in a SG and procedures are defined for an ASP to shift traffic load
> from one SGP to another.
> 
> -- Anubhav
> 

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 11 Jun 2001 16:19:55 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA draft 7 questions (SCTP congestion at ASP)
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      QAA31142
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-233.dallas.net [209.44.41.233]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

On Mon, 11 Jun 2001, Ken Morneault wrote:
> 
> 
> Currently, an implementation can distribute message traffic
> across SCTP streams in this fashion.  The document does
> recommend a stream per link, but does not require it.  I can
> expand the recommendation for high speed links.
> 

Fair enough.  Pardon my oversight.

> 
> Is it feasible to have inter-operability between a SG and MGC
> if one side makes use of Correlation ID and the other doesn't
> (i.e. one designs RB/TB/RTB to be split across the SCTP
> association and the other does not).

It is "possible".  I am not too sure about "feasible".
(I don't believe that it is feasible not to split the buffers!  Otherwise, I
wouldn't be asking for it...)

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 11 Jun 2001 16:23:52 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: IUA/Q.921/ISUP basic question
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-233.dallas.net [209.44.41.233]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Mike,

On Mon, 11 Jun 2001, Mike Furey wrote:
>
>    What would be a practical application for using IUA?  Isn't most of
>    the Q.921/31 signaling traffic within the ISDN PRI/BRIs in the same
>    trunk/circuit as the bearer channels?  Might the benefits of using IUA
>    be specific to VoIP (M:M environment) , or is there another use for
>    IUA within the trenches of the circuit-switched world?
>    

It is also useful for building trunk converters which convert PRI to SS7 IMT
and back, and where the bearers and call control to perform the conversion
are separated.  But this is still a softswitch type of approach (and thus
the backhaul of ISDN and SS7).

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 11 Jun 2001 17:43:16 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Reinventing the Wheel
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-233.dallas.net [209.44.41.233]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Coene,

It sounds like you really responded from the gut this time, because you are
full of little red ants! ;)

On Mon, 11 Jun 2001, Coene Lode wrote:
>
>    Neither SCCP nor TCAP are ISO network or transport services.
>    Especially SCCP is NOT a ISO network service. I have never run into a
>    ISO spec specifying anything close to the things SCCP do. (Oh yes ,
>    apart from doing the Connection oriented service but that is only one
>    of the SCCP services, big deal)
>    

ANSI T1.112.1 Section 1.1:

        "The Network Service Part meets the requirements for Layer
         3 services as defined in the CCITT Recommendation X.200,
         Reference Model of Open Systems Interconnect for CCITT
         Applications."

Q.711 Section 5.1:

        "The service interfaces to the upper layers and to MTP are
         described by means of primitives and parameters, as recommended
         in Recommendation X.200."
        
Perhaps you didn't know that X.200 was ISO/IEC 7498.

ANSI T1.112.1 Sction 2.1.1.2.1:

        "(Refer to CCITT Recommendation X.213, Network Layer Service
         Definition of Openn Systems Interconnect for CCITT Application.)"

An in Q.711, we find X.213 (ISO/IEC 8348) as a "Normative" reference...

Perhaps you didn't know that X.213 was ISO/IEC 8348.

I'm, sorry, but SCCP *is* an OSI/ISO network service provider.

>    TCAP cannot be a tranport service , it is a aplication service. Oh yes

Q.771 Section 1.1 General:

        "The term "Transaction Capabilities" refers to a set of
communication
         capabilities that provide an interface between applications and a
         network layer service."

As such, TC must provide a transport service by definition in the OSI model.

>    it is very similar to ROSE and ACSE, but ROSE/ACSE were supposed to be
>    used on top of a connection oriented transport service.

Q.771 Section 2.2.4:

        "The component sublayer of TCAP is in partial alignment with the
         capailities of the Remote Operation Service Element (ROSE).  The
         current status of TCAP and ROSE alignment is on the basis of
         protocol alignment, namely the X.229 protocol is contained within
         the TCAP component protocol. ....."

Yes they were, but TCAP has more than simularities: it has full alignment in
many respects, particularly X.229.

>    Hey, TCAP was
>    made to run on top of a connectionless transport service.

No.  It was made to run on top of a connectionless *network* service.

>    And where
>    are those connectionless service specified somewhere in the RFC
>    1006,1859 and 2126.  I looked, they ain't.

SCCP does not provide a "true" connection-less service.  It only provides
the "appearance" of a connection-less service to NSP users.

Q.711 Section 5.5:
        
        "NOTE - This model is intended solely to describe the appearance
         of the connectionless-mode network service to the SCCP users.
         It is not intended to be a model of the internal operation of
         the service provider in providing the connectionless network
         service."
>    
>    Thus we have to specify that ourselves and thus we are NOT reinventing
>    the wheel.

The reason the you will not find this in 1006, 1859 and 2126 is because the
mapping from N-UNITDATA request and N-UNITDATA indication onto UDP for
connection-less support is trivial.  Even the (for further study) N-NOTICE
is a trivial and direct mapping onto ICMP.

In those specifications, you will see that TCP with the extensions provided,
define a connection-oriented *Network Service* in support of OSI transport.

>    And how are we going to transport our addresses, namely our Global
>    Titles. As OSI NSAP's maybe? With no support for any numbering plan
>    besides E164(well tell that to a GSM operator and most important to
>    its customers -> they are going to kill you, especially the female
>    part), no translation type, nature-of-address: somewhere in the middle
>    of nowhere.

Gee, the IP network already has an addressing scheme, I would suggest that
the SG map from SS7 GTT to the addresses (IP address, port numbers, even
SCTP stream ids) already available in the IP network.

>    
>    > Also, these approaches to ISO Transport over TCP do not
>    > encapsulate the transport primitives in the TCP data stream,
>    > but rather, map the primitives onto TCP's ULP interface.
>    > I put it to you that the transport of TCAP (SCCP users) over
>    > TCP has already been specified in the cited RFCs and that
>    > all is missing is a similar mapping to SCTP as these RFCs
>    > provide for TCP.
>    
>    Great, every SCCP connection gets its own TCP/SCTP connection,
>    congratulations.

Uh, no.  It is possible to map connections onto streams, rather than
associations.

>    And where the hell is the connectionless service???.
>    The one that makes everything WORK.

No need to swear.  Where is the connectionless service in MTP?  MTP does not
provide true connectionless network services.  Where is it in TCP/IP?  It
happens to be called UDP.

>    
>    And if you map TCAP over TCP,how will that happen. A TCAP transaction

Gee, worked really well on the Telcordia GDI (SR-35whatever).  Also, TCAP
maps well even to RPC (which runs over TCP or UDP fine: no-one seems to be
claiming that opening up all those RPC sockets is a problem).

>    per SCTP connection. Good lord, that means for one that the SCTP(or
>    TCP) congestion algorithms will never have the possibility to engage.
>    TCAP is a request/ response. It waits for the response, it isn't a
>    file transfer protocol where you send a bunch of messages and the
>    acknowledges come back after a time, followed after a bit more time by
>    the response(if any was needed) of the filetransfer itself. Windows(No
>    not Microsoft, but the Cwnd) are very usefull in those cases for not
>    overloading the network. With TCAP you would get one msg in flight and
>    that's it. Due to to heavy use of TCAP you would have a lot of
>    TCAP/SCTP dialogues/connections open at the same time but hey without
>    congestion control actually working, but the endpoints and links
>    clearly in trouble(meaning dropping messages). then the congestion
>    manager would come in handy, but that doesn't take into acount the way
>    everything is addressed. (And I could get one for hours and hours
>    ranting...)

You don't need a connection per transaction for heaven's sake.  Your not
even thinking.

Look.  TCAP runs fine over ISO NS.  It has run over X.25 (ISO Network
Service Provider) just fine in the IS-41 network for many years.
RFC 1006, etc., provide a way for TCP to provide ISO Network Services to an
ISO Network Service User (ISO Transport).  TCAP could be transported over
this ISO Network Service Provider just as easily as over X.25 (which *is*
connection oriented I might add).

Besides, I asked nicely for a compelling technical reason, not a treatise
showing how much a person can forget about a topic. ;)

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 11 Jun 2001 17:45:05 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Reinventing the Wheel
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-233.dallas.net [209.44.41.233]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Coene,

This note was about as useful as the last one.

On Mon, 11 Jun 2001, Coene Lode wrote:

> 
>    > -----Original Message-----
>    > From: Brian F. G. Bidulock [[1]mailto:[email-masked]]
>    > Sent: maandag 11 juni 2001 11:39
>    > To: sigtran
>    > Subject: Re: Reinventing the Wheel
>    >
>    >
>    > John,
>    >
>    > I believe that RFC 1006 also maps the ISO Network Services
>    > N-Primitives onto TCP.  As SCCP provides no more than the ISO
>    > N-Primitives, the RFCs sited would be sufficient, I believe, for
>    > these SCCP users as well.
>    
>    No they ain't.
>    
>    >
>    > Are there any other, more compelling reasons, why the existing
>    > ISO work in the IETF and elsewhere has been discarded?
>    First of all, they are completely unknown.
>    Secondly, they seem to apply to ISO stuff. As SCCP and TCAP are not
>    part of the rank-and-file ISO protocol suite, they do not apply.
>    Especiallly the part that are most used by SCCP are simply not
>    supported in those RFC'. That should answer the question.
>    
>    >
>    > It just doesn't make much sense to me on the surface to
>    > take an ISO Network Service interface and, rather than
>    > implementing it over TCP/IP, attempting to implement an SS7-
>    > specific SCCP in between the ISO interface and SCTP,
>    > particularly when SS7 went to so much trouble in the first
>    > place to provide ISO Network Services interface to SCCP.
>    
>    That is the first time I've ever heard of that. The last I heard about
>    ISO stuff trying to get incorporated in SS7 was when there was talk
>    about supporting ISO NSAP addresses in SCCP addressing. Never came to
>    anything. SCCP to date only supports usefull addresses.
>    
>    >
>    > Could you perhaps humor me with several compelling technical
>    > reasons for doing so?
>    
>    Hope it gave you a good laugh. Always happy to be of service:-)
>    >
>    > --Brian
>    >

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Balani, Sandeep" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2UA - TTC-DATA ..
Date: Mon, 11 Jun 2001 16:51:04 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: thalia.fm.intel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: fmfdns02.fm.intel.com [132.233.247.11]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi all, 
  I have a little concern regarding existance of message type TTC-DATA. To
my understanding TTC-DATA is sort of protocol parameter at  MTP3/MTP2
interface,  and we don't need to diffrentiate between TTC-DATA and normal
DATA message at M2UA level.  
Whenever MTP3 will be running for Japnese n/w, In the message Buffer for
data it will always send extra Byte with 2 bits of priority, and MTP2 will
assume the extra byte is there and behaves accordingly. Same thing is true
for non-japnese n/w in which MTP3/MTP2 will know that there is no extra byte
and no priority in MTP3 message.
Therefore at the M2UA level, does it really matter whether we diffrentiate
between TTC-DATA or normal DATA. My assumption was that the MTP2/MTP3 will
compiled with TTC option for working accordingly and the data type should
not be a  run time parameter in Data Req/Ind between MTP3-MTP2 interface. 

so if MTP3/MTP2 are compiled with same options, then M2UA will not know the
data type (TTC/NON-TTC) at MTP3/M2UA interface and will not care about the
data type.  M2UA just transparently backhauls message buffer from MTP3 (MGC)
to MTP2 (SG) for Data Request.  
Please correct me if i am wrong here. 

Thanks
Sandeep   

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Reinventing the Wheel
Date: Tue, 12 Jun 2001 11:09:32 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades6.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mailhost2.atea.be [194.78.143.126]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: Reinventing the Wheel</TITLE> </HEAD>
<BODY>

<P><FONT SIZE=2>Hello Brian,</FONT>
</P>

<P><FONT SIZE=2>There are a number of alternatives already to transport
SCCP-user messages over an IP-network :</FONT> </P>

<P><FONT SIZE=2>- use SCCP over M3UA</FONT> <BR><FONT SIZE=2>- use TI-SCCP
(Transport Independent-SCCP) over STC (Signalling Transport Converter, as
defined in Q.1901) over SCTP</FONT> <BR><FONT SIZE=2>- use SUA</FONT>
<BR><FONT SIZE=2>- use RFC 2126, with adaptation to SCTP as the transport
layer.</FONT> </P>

<P><FONT SIZE=2>One solution or the other will be easier to implement,
depending on what you have already in your boxes. And in my opinion, either
one would work fine, at least in small networks.</FONT></P>

<P><FONT SIZE=2>Now SCCP extends the addressing capabilities of MTP
(pointcodes), by the use of Global Title routing. It is the intention
(whenever SUA issue 6 gets out, John ?) to have the possibility of extensive
addressing mechanisms in SUA as well. As such SUA would allow pointcodes,
GTs, IP addresses, hostnames, ... as valid addresses and make use of an
address mapping function (AMF) to resolve these to the SCTP association ID
towards the end-node or a relay-node (where AMF is repeated).</FONT></P>

<P><FONT SIZE=2>This feature will offer scalability : for larger networks it
would be rather cumbersome to have a fully meshed overlay of SCTP
associations, and an overloaded management system to boot.</FONT></P>

<P><FONT SIZE=2>The AMF would offer the routing functionality like that of
an SS7 STP (I'm not talking about any management procedures), with any kind
of address.</FONT></P>

<P><FONT SIZE=2>Another thing in SUA is to extend the ASP management, which
is just informing the other end of an SCTP association. A proposal was made
to have an SUA relay node inform it's other (concerned) neighbours as well,
by extension of the DUNA, DAVA, SCON messages.</FONT></P>

<P><FONT SIZE=2>If you have any ideas/comments ... well I'm sure I don't
have to ask you this ;)</FONT> </P>

<P><FONT SIZE=2>One question for you though : what do you mean by
&quot;true&quot; connectionless services as opposed to
&quot;appearance&quot; ? MTP nor SCCP keep any state for (connectionless)
messages being sent/received. Or do you allude to the management functions,
keeping track of link- and route-state, where UDP couldn't care less
?</FONT></P>

<P><FONT SIZE=2>Best regards,</FONT>
</P>

<P><FONT SIZE=2>____________________________</FONT> </P>

<P><FONT SIZE=2>Gery Verwimp</FONT>
<BR><FONT SIZE=2>&gt; SIEMENS ATEA</FONT> <BR><FONT SIZE=2>&gt; ICN D CS
D5</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Tel. : +32 14 25 3424</FONT> <BR><FONT SIZE=2>Fax :
+32 14 25 3212</FONT> <BR><FONT SIZE=2><A
HREF="mailto:[email-masked]">mailto:[email-masked].
be</A></FONT> <BR><FONT SIZE=2>____________________________________</FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT> <BR><FONT SIZE=2>From:
Brian F. G. Bidulock [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>Sent: dinsdag 12 juni 2001 0:43</FONT> <BR><FONT SIZE=2>To:
sigtran</FONT>
<BR><FONT SIZE=2>Subject: Re: Reinventing the Wheel</FONT> </P>
<BR>

<P><FONT SIZE=2>Coene,</FONT>
</P>

<P><FONT SIZE=2>It sounds like you really responded from the gut this
time,</FONT> <BR><FONT SIZE=2>because you are full of little red ants!
;)</FONT> </P>

<P><FONT SIZE=2>On Mon, 11 Jun 2001, Coene Lode wrote:</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Neither SCCP nor TCAP are ISO
network or transport services.</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Especially SCCP is NOT a ISO network service.
I have never run into a</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; ISO
spec specifying anything close to the things SCCP do. (Oh yes ,</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; apart from doing the Connection
oriented service but that is only one</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; of the SCCP services, big deal)</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> </P>

<P><FONT SIZE=2>ANSI T1.112.1 Section 1.1:</FONT> </P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;The Network
Service Part meets the requirements for Layer</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 services as
defined in the CCITT Recommendation X.200,</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Reference Model of
Open Systems Interconnect for CCITT</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Applications.&quot;</FONT> </P>

<P><FONT SIZE=2>Q.711 Section 5.1:</FONT> </P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;The service
interfaces to the upper layers and to MTP are</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; described by means
of primitives and parameters, as recommended</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in Recommendation
X.200.&quot;</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>Perhaps you didn't know that X.200 was ISO/IEC 7498.</FONT> </P>

<P><FONT SIZE=2>ANSI T1.112.1 Sction 2.1.1.2.1:</FONT> </P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;(Refer to
CCITT Recommendation X.213, Network Layer Service</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Definition of Openn
Systems Interconnect for CCITT Application.)&quot;</FONT> </P>
<BR>

<P><FONT SIZE=2>An in Q.711, we find X.213 (ISO/IEC 8348) as a
&quot;Normative&quot; reference...</FONT> </P>

<P><FONT SIZE=2>Perhaps you didn't know that X.213 was ISO/IEC 8348.</FONT>
</P>

<P><FONT SIZE=2>I'm, sorry, but SCCP *is* an OSI/ISO network service
provider.</FONT> </P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; TCAP cannot be a tranport service ,
it is a aplication service. Oh yes</FONT> </P>

<P><FONT SIZE=2>Q.771 Section 1.1 General:</FONT> </P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;The term
&quot;Transaction Capabilities&quot; refers to a set of communication</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
capabilities that provide an interface between applications and a</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; network
layer service.&quot;</FONT> </P>

<P><FONT SIZE=2>As such, TC must provide a transport service by definition
in the OSI</FONT> <BR><FONT SIZE=2>model.</FONT>
</P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; it is very similar to ROSE and ACSE,
but ROSE/ACSE were supposed to be</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; used on top of a connection oriented transport
service.</FONT> </P>

<P><FONT SIZE=2>Q.771 Section 2.2.4:</FONT> </P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;The
component sublayer of TCAP is in partial alignment with the</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; capailities of the
Remote Operation Service Element (ROSE).&nbsp; The</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; current status of
TCAP and ROSE alignment is on the basis of</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; protocol alignment,
namely the X.229 protocol is contained within</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the TCAP component
protocol. .....&quot;</FONT> </P>

<P><FONT SIZE=2>Yes they were, but TCAP has more than simularities: it has
full</FONT> <BR><FONT SIZE=2>alignment in many respects, particularly
X.229.</FONT> </P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Hey, TCAP was</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; made to run on top of a connectionless
transport service.</FONT> </P>

<P><FONT SIZE=2>No.&nbsp; It was made to run on top of a connectionless
*network* service.</FONT> </P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; And where</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; are those connectionless service specified
somewhere in the RFC</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
1006,1859 and 2126.&nbsp; I looked, they ain't.</FONT> </P>
<BR>

<P><FONT SIZE=2>SCCP does not provide a &quot;true&quot; connection-less
service.&nbsp; It only</FONT> <BR><FONT SIZE=2>provides the
&quot;appearance&quot; of a connection-less service to NSP users.</FONT>
</P>

<P><FONT SIZE=2>Q.711 Section 5.5:</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;NOTE - This model is
intended solely to describe the appearance</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of the
connectionless-mode network service to the SCCP users.</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It is not intended
to be a model of the internal operation of</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the service provider
in providing the connectionless network</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
service.&quot;</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Thus we have to specify that
ourselves and thus we are NOT reinventing</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; the wheel.</FONT> </P>

<P><FONT SIZE=2>The reason the you will not find this in 1006, 1859 and 2126
is because</FONT> <BR><FONT SIZE=2>the mapping from N-UNITDATA request and
N-UNITDATA indication onto UDP</FONT> <BR><FONT SIZE=2>for connection-less
support is trivial.&nbsp; Even the (for further study)</FONT> <BR><FONT
SIZE=2>N-NOTICE is a trivial and direct mapping onto ICMP.</FONT> </P>

<P><FONT SIZE=2>In those specifications, you will see that TCP with the
extensions</FONT> <BR><FONT SIZE=2>provided, define a connection-oriented
*Network Service* in support of </FONT> <BR><FONT SIZE=2>OSI
transport.</FONT>
</P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; And how are we going to transport our
addresses, namely our Global</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
Titles. As OSI NSAP's maybe? With no support for any numbering plan</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; besides E164(well tell that to a GSM
operator and most important to</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; its customers -&gt; they are going to kill
you, especially the female</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
part), no translation type, nature-of-address: somewhere in the
middle</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; of nowhere.</FONT>
</P>

<P><FONT SIZE=2>Gee, the IP network already has an addressing scheme, I
would suggest</FONT> <BR><FONT SIZE=2>that the SG map from SS7 GTT to the
addresses (IP address, port numbers,</FONT> <BR><FONT SIZE=2>even SCTP
stream ids) already available in the IP network.</FONT> </P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &gt; Also, these approaches to ISO Transport
over TCP do not</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &gt;
encapsulate the transport primitives in the TCP data stream,</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &gt; but rather, map the primitives
onto TCP's ULP interface.</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
&gt; I put it to you that the transport of TCAP (SCCP users) over</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &gt; TCP has already been specified
in the cited RFCs and that</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
&gt; all is missing is a similar mapping to SCTP as these RFCs</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &gt; provide for TCP.</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Great, every SCCP connection gets its own
TCP/SCTP connection,</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
congratulations.</FONT> </P>

<P><FONT SIZE=2>Uh, no.&nbsp; It is possible to map connections onto
streams, rather than</FONT> <BR><FONT SIZE=2>associations.</FONT>
</P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; And where the hell is the
connectionless service???.</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
The one that makes everything WORK.</FONT> </P>

<P><FONT SIZE=2>No need to swear.&nbsp; Where is the connectionless service
in MTP?&nbsp; MTP</FONT> <BR><FONT SIZE=2>does not provide true
connectionless network services.&nbsp; Where is it</FONT> <BR><FONT
SIZE=2>in TCP/IP?&nbsp; It happens to be called UDP.</FONT> </P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; And if you map TCAP over TCP,how will that
happen. A TCAP transaction</FONT> </P>

<P><FONT SIZE=2>Gee, worked really well on the Telcordia GDI
(SR-35whatever).&nbsp; Also,</FONT> <BR><FONT SIZE=2>TCAP maps well even to
RPC (which runs over TCP or UDP fine: no-one seems</FONT> <BR><FONT
SIZE=2>to be claiming that opening up all those RPC sockets is a
problem).</FONT> </P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; per SCTP connection. Good lord, that
means for one that the SCTP(or</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; TCP) congestion algorithms will never have the
possibility to engage.</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; TCAP
is a request/ response. It waits for the response, it isn't a</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; file transfer protocol where you
send a bunch of messages and the</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; acknowledges come back after a time, followed
after a bit more time by</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; the
response(if any was needed) of the filetransfer itself. Windows(No</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; not Microsoft, but the Cwnd) are
very usefull in those cases for not</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; overloading the network. With TCAP you would
get one msg in flight and</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
that's it. Due to to heavy use of TCAP you would have a lot of</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; TCAP/SCTP dialogues/connections open
at the same time but hey without</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; congestion control actually working, but the
endpoints and links</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; clearly
in trouble(meaning dropping messages). then the congestion</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; manager would come in handy, but that doesn't
take into acount the way</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
everything is addressed. (And I could get one for hours and hours</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; ranting...)</FONT> </P>

<P><FONT SIZE=2>You don't need a connection per transaction for heaven's
sake.&nbsp; Your</FONT> <BR><FONT SIZE=2>not even thinking.</FONT> </P>

<P><FONT SIZE=2>Look.&nbsp; TCAP runs fine over ISO NS.&nbsp; It has run
over X.25 (ISO Network</FONT> <BR><FONT SIZE=2>Service Provider) just fine
in the IS-41 network for many years.</FONT> <BR><FONT SIZE=2>RFC 1006, etc.,
provide a way for TCP to provide ISO Network Services</FONT> <BR><FONT
SIZE=2>to an ISO Network Service User (ISO Transport).&nbsp; TCAP could
be</FONT> <BR><FONT SIZE=2>transported over this ISO Network Service
Provider just as easily as</FONT> <BR><FONT SIZE=2>over X.25 (which *is*
connection oriented I might add).</FONT> </P>

<P><FONT SIZE=2>Besides, I asked nicely for a compelling technical reason,
not a</FONT> <BR><FONT SIZE=2>treatise showing how much a person can forget
about a topic. ;)</FONT> </P>

<P><FONT SIZE=2>-- </FONT>
<BR><FONT SIZE=2>Brian F. G. Bidulock</FONT> <BR><FONT
SIZE=2>[email-masked]</FONT> <BR><FONT SIZE=2><A
HREF="http://www.openss7.org/"
TARGET="_blank">http://www.openss7.org/</A></FONT> </P>
<BR>

<P><FONT SIZE=2>---</FONT>
<BR><FONT SIZE=2>You are currently subscribed to sigtran as:
[email-masked]</FONT> <BR><FONT SIZE=2>To unsubscribe send a
blank email to [email-masked]</FONT> </P>

---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY>
</HTML>

</x-html>
From: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Reinventing the Wheel
Date: Tue, 12 Jun 2001 11:48:30 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades6.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mailhost2.atea.be [194.78.143.126]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: Reinventing the Wheel</TITLE> </HEAD>
<BODY>

<P><FONT SIZE=2>Brian,</FONT>
</P>

<P><FONT SIZE=2>When comparing the CCITT stack with the OSI-stack, the
layers 4 - 6 (transport, session, presentation) are considered
&quot;empty&quot; in the CCITT stack. TCAP and the applications are depicted
in layer 7.</FONT></P>

<P><FONT SIZE=2>Of course, the MTP/SCCP layers already provide so many
features (quasi no message loss, in sequence delivery, notification of
undeliverable messages, segmentation/reassembly, ...) that there's hardly
anything to do for these layers except for playing go-between.</FONT></P>

<P><FONT SIZE=2>Arguably, TCAP covers a little bit of all these layers
(ASN.1 encoding according to BER =&gt; layer 6 ? common framework for
executing remote operations and Application Context negotiation =&gt; layer
5 ? end-to-end transactions =&gt; layer 4 ?), but it's hardly a full-fledged
transport layer such as TCP or SCTP.</FONT></P>

<P><FONT SIZE=2>br,</FONT>
</P>

<P><FONT SIZE=2>____________________________</FONT> </P>

<P><FONT SIZE=2>Gery Verwimp</FONT>
<BR><FONT SIZE=2>&gt; SIEMENS ATEA</FONT> <BR><FONT SIZE=2>&gt; ICN D CS
D5</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Tel. : +32 14 25 3424</FONT> <BR><FONT SIZE=2>Fax :
+32 14 25 3212</FONT> <BR><FONT SIZE=2><A
HREF="mailto:[email-masked]">mailto:[email-masked].
be</A></FONT> <BR><FONT SIZE=2>____________________________________</FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT> <BR><FONT SIZE=2>From:
Brian F. G. Bidulock [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>Sent: dinsdag 12 juni 2001 0:43</FONT> <BR><FONT SIZE=2>To:
sigtran</FONT>
<BR><FONT SIZE=2>Subject: Re: Reinventing the Wheel</FONT> </P>
<BR>

<P><FONT SIZE=2>Q.771 Section 1.1 General:</FONT> </P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;The term
&quot;Transaction Capabilities&quot; refers to a set of communication</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
capabilities that provide an interface between applications and a</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; network
layer service.&quot;</FONT> </P>

<P><FONT SIZE=2>As such, TC must provide a transport service by definition
in the OSI</FONT> <BR><FONT SIZE=2>model.</FONT>
</P>

---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY>
</HTML>

</x-html>
From: [email-masked]
X-Lotus-FromDomain: HSS
To: "sigtran" <[email-masked]>
Date: Tue, 12 Jun 2001 16:30:57 +0530
Subject: M3UA : SG Load Sharing
X-SMTP-HELO: hindon.hss.co.in
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked],[email-masked]
X-SMTP-PEER-INFO: [202.54.26.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi,

This is regarding SG Load Sharing from ASP side.

As draft says the loadsharing can be done on the basis of SLS: "In order to
direct messages to the SS7 network, the ASP must also perform a message
distribution function in order to choose the proper SG or SGP for a given
message.
 This is accomplished by observing the
Destination Point Code (and possibly other elements of the outgoing message
such as the SLS value), together with the SS7 destination
availability/restricted/congestion status via the SG(s) and the availability
of the SG and SGPs themselves."

Suppose there are two SGs active in load shared mode and traffic is being
load shared on the basis of SLS value.  Both SGs give identical DPC
rechability to SS7 network.  Now if one SG goes down(or association to that
SG fails) then how should SLS values assigned to failed SG be handled in
order to avoid mis-sequencing.
a) Have a pre-defined set of SLS values for each SG.  In this case if one SG
failes its's assigned SLS values won't have a route.
OR
b) Using time controlled changeover i.e. retrieving messages from failed
association, wait for a timer period and then resent retrieved messages on
alternate association.

Or is there any other option.

Thanks and Regards
-Mukesh

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Tue, 12 Jun 2001 09:36:27 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA - TTC-DATA ..
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Sandeep,

There was significant discussion on the list and at the San Diego meeting of
how to best support TTC in M2UA and M3UA.  
The final decision was to create a parameter for TTC Data (as in M3UA) not a
new message type (as in M2UA).  The next version of M2UA will reflect the
decision.

Regards,

Ken

At 04:51 PM 6/11/01 -0700, you wrote:
>Hi all, 
>   I have a little concern regarding existance of message type TTC-DATA. To
>my understanding TTC-DATA is sort of protocol parameter at  MTP3/MTP2
>interface,  and we don't need to diffrentiate between TTC-DATA and normal
>DATA message at M2UA level.  
>Whenever MTP3 will be running for Japnese n/w, In the message Buffer for
>data it will always send extra Byte with 2 bits of priority, and MTP2 will
>assume the extra byte is there and behaves accordingly. Same thing is true
>for non-japnese n/w in which MTP3/MTP2 will know that there is no extra
byte
>and no priority in MTP3 message.
>Therefore at the M2UA level, does it really matter whether we diffrentiate
>between TTC-DATA or normal DATA. My assumption was that the MTP2/MTP3 will
>compiled with TTC option for working accordingly and the data type should
>not be a  run time parameter in Data Req/Ind between MTP3-MTP2 interface. 
>
>so if MTP3/MTP2 are compiled with same options, then M2UA will not know the
>data type (TTC/NON-TTC) at MTP3/M2UA interface and will not care about the
>data type.  M2UA just transparently backhauls message buffer from MTP3
(MGC)
>to MTP2 (SG) for Data Request.  
>Please correct me if i am wrong here. 
>
>Thanks
>Sandeep   
>
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 12 Jun 2001 17:03:44 -0500
From: Alex Audu <[email-masked]>
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
CC: [email-masked]
Subject: Re: M3UA M2UA: ASP Partitioning
X-MIME-Autoconverted: from 8bit to quoted-printable by netmail2.alcatel.com
id 
                      RAA29117
X-SMTP-HELO: netmail2.alcatel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [128.251.168.51]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Ken,

I am not sure if an ASP ID is really necessary in this case. The ASP ID  is
what the AS assigns to each
ASP object as they are instantiated. This ID is mapped to the unique IP
address of each physical ASP.
Remember, the ASP is the instance of the MGC at the SG.  So, the AS has all
it needs to do house keeping
monitoring the states and communicating with the ASPs.

Regards,
Alex.

Ken Morneault wrote:

> Brian,
>
> Sorry for the delayed response.  I understand your concern
> now that we are adding the loadshare and broadcast options
> to M2UA.  I will add ASP ID to the next version of M2UA.
>
> Regards,
>
> Ken
>
> At 12:30 PM 6/4/01 -0500, you wrote:
> >All,
> >
> >I understand that ASP to ASP communications is outside the
> >scope of both the M2UA and M3UA documents, however, I am
> >trying to find a solution to the problem where ASPs lose
> >communication with each other.  Take the a simple two ASP
> >case in the same AS as follows:
> >
> >                +-------+           +-------+
> >                |       |           |       |
> >                |  ASP  +-----------+  ASP  |
> >                |   1   |           |   2   |
> >                +---+---+           +---+---+
> >                    |                   |
> >                    |                   |
> >      Association   +-------+   +-------+  Association
> >                            |   |
> >                            |   |
> >                          +-+---+-+
> >                          |       |
> >                          |  SGP  |
> >                          |       |
> >                          +-------+
> >
> >Now, a couple of comments:  The ASPs are geographically
> >separated (otherwise there isn't much point in having
> >them use separate associations).  Therefore, the ASP-ASP
> >communications link can suffer failures.  When the ASP-ASP
> >communications fails we have the following problem:
> >
> >                +-------+           +-------+
> >                |       |           |       |
> >                |  ASP  +--   X   --+  ASP  |
> >                |   1   |           |   2   |
> >                +---+---+           +---+---+
> >                    |                   |
> >                    |                   |
> >      Association   +-------+   +-------+  Association
> >                            |   |
> >                            |   |
> >                          +-+---+-+
> >                          |       |
> >                          |  SGP  |
> >                          |       |
> >                          +-------+
> >
> >In the above diagram, ASP2 no longer knows the state of
> >ASP1.  Nor can ASP2 tell whether ASP1 has failed or whether
> >simply communications to ASP1 has failed.  That is ASP2
> >cannot locally determine whether the above is the case
> >or whether the following diagram is the case:
> >
> >                X X X X X           +-------+
> >                                    |       |
> >                X  ASP  X--   X   --+  ASP  |
> >                    1               |   2   |
> >                X X X X X           +---+---+
> >                    |                   |
> >                                        |
> >      Association       X  -+   +-------+  Association
> >                            |   |
> >                            |   |
> >                          +-+---+-+
> >                          |       |
> >                          |  SGP  |
> >                          |       |
> >                          +-------+
> >
> >In both cases, the SG is aware of what the state of ASP1
> >is with regards to being able to exchange information with
> >the SS7 network.
> >
> >I would like to see a mechanism in the UAs which allows
> >ASP2 to be notified of the change in state of ASP1 with
> >respect to the SG.  This would require an ASP identifier
> >which is provided to the SG with the ASP-Up and a
> >notification (NTFY) sent to other ASPs in the AS when
> >an ASP makes some state transitions.  These notifications
> >can be completely advisory (in that it is still up to the
> >ASP to take action on them or ignore them).
> >
> >The addition of an ASP Id would also help the SG determine
> >whether it has multiple associations open to the same
> >ASP.
> >
> >--Brian
> >
> >
> >--
> >Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> >[email-masked]    ¦ world; the unreasonable one persists in  ¦
> >http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
> >                         ¦ Therefore  all  progress  depends on the ¦
> >                         ¦ unreasonable man. -- George Bernard Shaw ¦
> >
> >
> >---
> >You are currently subscribed to sigtran as: [email-masked]
> >To unsubscribe send a blank email to
[email-masked]
>
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 12 Jun 2001 18:00:24 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA M2UA: ASP Partitioning
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      SAA20700
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.234]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Alex,

Yes, but it is intended in the very real an possible event that the AS
becomes partitioned.  Although each ASP has the information to identify
another ASP in the AS, it is no longer able to determine other ASPs state
with respect to the SGP.  In some traffic modes the ASP is faced with
placing itself inactive (and possibly taking down the entire AS), or
continuing to process traffic (which in Broadcast mode may also be processed
in duplicated by a partitioned ASP).

On Tue, 12 Jun 2001, Alex Audu wrote:

> Ken,
> 
> I am not sure if an ASP ID is really necessary in this case. The ASP ID
is
> what the AS assigns to each ASP object as they are instantiated. This ID
is
> mapped to the unique IP address of each physical ASP.  Remember, the ASP
is
> the instance of the MGC at the SG.  So, the AS has all it needs to do
house
> keeping monitoring the states and communicating with the ASPs.
> 
> Regards,
> Alex.
> 
> Ken Morneault wrote:
> 
> > Brian,
> >
> > Sorry for the delayed response.  I understand your concern
> > now that we are adding the loadshare and broadcast options
> > to M2UA.  I will add ASP ID to the next version of M2UA.
> >
> > Regards,
> >
> > Ken
> >
> > At 12:30 PM 6/4/01 -0500, you wrote:
> > >All,
> > >
> > >I understand that ASP to ASP communications is outside the
> > >scope of both the M2UA and M3UA documents, however, I am
> > >trying to find a solution to the problem where ASPs lose
> > >communication with each other.  Take the a simple two ASP
> > >case in the same AS as follows:
> > >
> > >                +-------+           +-------+
> > >                |       |           |       |
> > >                |  ASP  +-----------+  ASP  |
> > >                |   1   |           |   2   |
> > >                +---+---+           +---+---+
> > >                    |                   |
> > >                    |                   |
> > >      Association   +-------+   +-------+  Association
> > >                            |   |
> > >                            |   |
> > >                          +-+---+-+
> > >                          |       |
> > >                          |  SGP  |
> > >                          |       |
> > >                          +-------+
> > >
> > >Now, a couple of comments:  The ASPs are geographically
> > >separated (otherwise there isn't much point in having
> > >them use separate associations).  Therefore, the ASP-ASP
> > >communications link can suffer failures.  When the ASP-ASP
> > >communications fails we have the following problem:
> > >
> > >                +-------+           +-------+
> > >                |       |           |       |
> > >                |  ASP  +--   X   --+  ASP  |
> > >                |   1   |           |   2   |
> > >                +---+---+           +---+---+
> > >                    |                   |
> > >                    |                   |
> > >      Association   +-------+   +-------+  Association
> > >                            |   |
> > >                            |   |
> > >                          +-+---+-+
> > >                          |       |
> > >                          |  SGP  |
> > >                          |       |
> > >                          +-------+
> > >
> > >In the above diagram, ASP2 no longer knows the state of
> > >ASP1.  Nor can ASP2 tell whether ASP1 has failed or whether
> > >simply communications to ASP1 has failed.  That is ASP2
> > >cannot locally determine whether the above is the case
> > >or whether the following diagram is the case:
> > >
> > >                X X X X X           +-------+
> > >                                    |       |
> > >                X  ASP  X--   X   --+  ASP  |
> > >                    1               |   2   |
> > >                X X X X X           +---+---+
> > >                    |                   |
> > >                                        |
> > >      Association       X  -+   +-------+  Association
> > >                            |   |
> > >                            |   |
> > >                          +-+---+-+
> > >                          |       |
> > >                          |  SGP  |
> > >                          |       |
> > >                          +-------+
> > >
> > >In both cases, the SG is aware of what the state of ASP1
> > >is with regards to being able to exchange information with
> > >the SS7 network.
> > >
> > >I would like to see a mechanism in the UAs which allows
> > >ASP2 to be notified of the change in state of ASP1 with
> > >respect to the SG.  This would require an ASP identifier
> > >which is provided to the SG with the ASP-Up and a
> > >notification (NTFY) sent to other ASPs in the AS when
> > >an ASP makes some state transitions.  These notifications
> > >can be completely advisory (in that it is still up to the
> > >ASP to take action on them or ignore them).
> > >
> > >The addition of an ASP Id would also help the SG determine
> > >whether it has multiple associations open to the same
> > >ASP.
> > >
> > >--Brian
> > >
> > >
> > >--
> > >Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> > >[email-masked]    ¦ world; the unreasonable one persists in  ¦
> > >http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
> > >                         ¦ Therefore  all  progress  depends on the ¦
> > >                         ¦ unreasonable man. -- George Bernard Shaw ¦
> > >
> > >
> > >---
> > >You are currently subscribed to sigtran as: [email-masked]
> > >To unsubscribe send a blank email to
[email-masked]
> >
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to
[email-masked]
> 
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 12 Jun 2001 20:26:44 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: SUA5: SG Relay Problems
Reply-To: [email-masked]
Mail-Followup-To: [email-masked],
[email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-183.dallas.net [209.44.41.183]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

In Section 6.2 and 6.3 of v5 of the draft, some statements are made which
have some problems with them with regard to the SS7 network.

Section 6.2:

In the replicated end-point case no consideration has been given for the
nature of the signalling links between the STPs and the SGs.  I take it that
these are B/D-links, and that the SG are equipped with the transfer function
(i.e, they are perceived by the SS7 network to be STPs): any other
assumption would present a whole range of other difficulties.

The case presented does differ greatly from the case presented in 6.1.1.
To exist in this arrange each SG requires a separate and distinct signalling
point code for the purposes of MTP signalling and management.
For the ASP to be represented as an SEP, it must present at least a third
signalling point code to the SS7 network as being available "routes" via the
SGs acting as STPs.

Given that Final GTT is peformed in the STPs on the left of the diagram, the
SGs must "transfer" SS7 messages to the ASPs PC.  When the ASP sends SCCP
messages back to the SEP, it may be on the basis of PC+SSN but is routed on
DPC only.

This can be the case for both COTS and CNLS protocol classes.

Given that proper SLS selection, loadsharing, and SG selection based on
point code availability must be performed at the ASP, it will be necessary
for the ASP to maintain the status of each distant signalling point to which
it communicates on the basis of the SG through which it may route, similar
to M3UA's management of multiple SGs and multiple routes via multiple SGs.

Because of the nature of the SS7 network, selection of an SLS value
identical to that of the incoming message does not guarantee the same
reverse route through the network.  Also, for protocol class 0 and class 2,
there is no guarantee that any of the messages making up a transaction or a
connection will traverse the same SG.

If you are meaning that each SG in 6.2 appears to the network as one of two
replicated subsystems, each with their own signalling point code then there
is still a problem.  But if that is the case, it is certainly not necessary
to transfer SCCP peer-to- peer PDUs over SCTP: only the N-Primitives need be
transferred.

Section 6.3:

Even if in 6.2, each SG has its own point code, the problems come back in
6.3.  In this case, I assume that the SG, as a relay-point, is appearing to
the SS7 network as an STP.

The lack of C-links in the diagram simply ignores the predominant SS7
network arrangement in North America, and over-simplifies the scenario.

Limiting the scenario to one in which the Final GTT is performed at the SG
is highly restrictive and is not necessarily the normal case in an SS7
network.  The tools for GTT management already exist in both the originating
SEP and STPs on the left of the diagram.  When messages are routed on PC
only to the SG, and for protocol class 0, there is no guarantee that the UDT
messages which make up a transaction will traverse the same SG.

As it stands SUA will not support many of the routing scenarios available to
the SS7 network for SCCP messages and is unable to support operation with
the SG as a relay-point in protocol classes 0 and 2.

Does the new draft provide any procedural enhancements to support
transparent operation with the SS7 network?

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Reply-To: [email-masked]
From: srikanth <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: role and scope of local management in sigtran
Date: Wed, 13 Jun 2001 09:52:14 +0530
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-SMTP-HELO: india.mercurykr.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [165.133.13.60]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hi

 I am not understanding the role of local managment in m3ua,m2ua etc.The
local  mangement establish sctp connection,want to know the status of asp
as,also notify ,error condition.But I am not understanding who will inform
local management to do all this.
for example
M-SCTP Establish request
Direction LM->M3UA
 Purpose:LM requests ASP to establish an SCTP association with the SG or
IPSP

I am not understanding in the above case who will inform LM to make  a SCTP
estblish request.

Can anyone inform me the role and scope of Local Management in Sigtran
group.

Thanks
srikanth

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Satish K <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: role and scope of local management in sigtran
Date: Wed, 13 Jun 2001 10:04:31 +0530
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-SMTP-HELO: mail.convergsoft.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [203.197.163.45]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Srikanth,
  Local management is the internal entity of the layer it depends on how you
implement it. the local Management sends messsages to m3ua depending on the
primitives it receives from the SCTP. the primitives which are effecting the
LM are given in the SCTP RFC#2960 in page no:111.
Thanks
Satish

-----Original Message-----
From: srikanth [mailto:[email-masked]] Sent: 13 June 2001 09:52
To: sigtran
Subject: role and scope of local management in sigtran

Hi

 I am not understanding the role of local managment in m3ua,m2ua etc.The
local  mangement establish sctp connection,want to know the status of asp
as,also notify ,error condition.But I am not understanding who will inform
local management to do all this.
for example
M-SCTP Establish request
Direction LM->M3UA
 Purpose:LM requests ASP to establish an SCTP association with the SG or
IPSP

I am not understanding in the above case who will inform LM to make  a SCTP
estblish request.

Can anyone inform me the role and scope of Local Management in Sigtran
group.

Thanks
srikanth

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Coene Lode <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Reinventing the Wheel
Date: Wed, 13 Jun 2001 11:47:41 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades6.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [194.78.143.126]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: Reinventing the Wheel</TITLE> </HEAD>
<BODY>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT> <BR><FONT SIZE=2>&gt;
From: Brian F. G. Bidulock [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: dinsdag 12 juni 2001 0:43</FONT> <BR><FONT
SIZE=2>&gt; To: sigtran</FONT> <BR><FONT SIZE=2>&gt; Subject: Re:
Reinventing the Wheel</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Coene,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; It sounds like you really responded from the gut this
time,</FONT> <BR><FONT SIZE=2>&gt; because you are full of little red ants!
;)</FONT> </P>

<P><FONT SIZE=2>And you are the ant eater?</FONT> <BR><FONT SIZE=2>Maybe you
like describing the original X25 centric way that it was first conceived and
described(and subsequentely never removed in the specs) But what you
describe is the situation from 15 years back(where x25,it seems, was still
king). It evolved and practically junked all the X25 stuff. And sure also
ISO stuff was rather popular in those days. A couple a references to ISO
wouldn't hurt(even normative) but the specs of TCAP and SCCP are
selfcontained, meaning you can implement them without even giving the
slightest look to any of those ISO or X25 specs. I did it that way and
nobody ever complained. </FONT></P>

<P><FONT SIZE=2>By the way how you implement your primitives and their
parameters is a implementation dependant issue. The real gut lies in the
messages syntax and its semantics and those are a very far cry from OSI. You
get that wrong and everybody knows.</FONT></P>

<P><FONT SIZE=2>You have a point for TCAP(yes )..: It has nearly the same
syntax(and semantics) for its messages as the ROSE and the ACSE. But that
doesn't make it a ISO protocol just we borrowed a few good ideas from
them.</FONT></P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; On Mon, 11 Jun 2001, Coene Lode wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; Neither SCCP nor TCAP are ISO
network or transport services.</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; Especially SCCP is NOT a ISO network service. I have
</FONT> <BR><FONT SIZE=2>&gt; never run into a</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; ISO spec specifying anything close to the things SCCP
</FONT> <BR><FONT SIZE=2>&gt; do. (Oh yes ,</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; apart from doing the Connection oriented service but
</FONT> <BR><FONT SIZE=2>&gt; that is only one</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; of the SCCP services, big deal)</FONT> <BR><FONT
SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ANSI T1.112.1 Section 1.1:</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;The Network Service Part meets the requirements for Layer</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
3 services as defined in the CCITT Recommendation X.200,</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Reference
Model of Open Systems Interconnect for CCITT</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Applications.&quot;</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Q.711 Section 5.1:</FONT> <BR><FONT SIZE=2>&gt;
</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;The service interfaces to the upper layers and to MTP are</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
described by means of primitives and parameters, as </FONT> <BR><FONT
SIZE=2>&gt; recommended</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in
Recommendation X.200.&quot;</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; Perhaps you didn't know that X.200 was ISO/IEC
7498.</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ANSI T1.112.1 Sction 2.1.1.2.1:</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;(Refer to CCITT Recommendation X.213, Network Layer Service</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Definition of Openn Systems Interconnect for CCITT </FONT> <BR><FONT
SIZE=2>&gt; Application.)&quot;</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; An in Q.711, we find X.213 (ISO/IEC 8348) as a
&quot;Normative&quot; </FONT> <BR><FONT SIZE=2>&gt; reference...</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Perhaps you didn't know that X.213 was ISO/IEC
8348.</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I'm, sorry, but SCCP *is* an OSI/ISO network service
provider.</FONT> </P>

<P><FONT SIZE=2>Those are references to the primitive interface. And they
are only used in the introduction. They then go on specifying their own
protocol which can be understood without ever having to read the ISO
documents.</FONT></P>

<P><FONT SIZE=2>Perhaps the SCCP you know run on a ISO network but the girl
I know runs on a SS7 network The SCCP i know does not support ISO adresses.
Thus if the native ISO addressing is not supported , how the hell can be it
be anything ISO. That is just the same as claiming SCCP is a internet
protocol while it can not even support internet addressing. Now in due
course TI-SCCP and SUA will and they may rightly claim that title and some
other people will fight over that. </FONT></P>

<P><FONT SIZE=2>In the 10 years that I have done SS7, ISO has palyed a very
small role in SS7. And if it did, then it was in TCAP concering some
aligments with updated specs of ASN1. But real important groundbreaking
stuff, no. </FONT></P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; TCAP cannot be a tranport
service , it is a aplication </FONT> <BR><FONT SIZE=2>&gt; service. Oh
yes</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Q.771 Section 1.1 General:</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;The term &quot;Transaction Capabilities&quot; refers to a set </FONT>
<BR><FONT SIZE=2>&gt; of communication</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
capabilities that provide an interface between </FONT> <BR><FONT SIZE=2>&gt;
applications and a</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; network
layer service.&quot;</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; As such, TC must provide a transport service by
definition in the OSI</FONT> <BR><FONT SIZE=2>&gt; model.</FONT>
</P>

<P><FONT SIZE=2>Which sets you apart from the rest because that is simply
not the case. Transport layers are supposed to do much more than TCAP does.
Gey explains it even better than me, so read his mail. </FONT></P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; it is very similar to ROSE and
ACSE, but ROSE/ACSE were </FONT> <BR><FONT SIZE=2>&gt; supposed to be</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; used on top of a connection
oriented transport service.</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Q.771 Section 2.2.4:</FONT> <BR><FONT SIZE=2>&gt;
</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;The component sublayer of TCAP is in partial </FONT> <BR><FONT
SIZE=2>&gt; alignment with the</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
capailities of the Remote Operation Service Element </FONT> <BR><FONT
SIZE=2>&gt; (ROSE).&nbsp; The</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; current
status of TCAP and ROSE alignment is on the basis of</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; protocol
alignment, namely the X.229 protocol is </FONT> <BR><FONT SIZE=2>&gt;
contained within</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the TCAP
component protocol. .....&quot;</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Yes they were, but TCAP has more than simularities: it
has full</FONT> <BR><FONT SIZE=2>&gt; alignment in many respects,
particularly X.229.</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; Hey, TCAP was</FONT> <BR><FONT
SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; made to run on top of a connectionless
transport service.</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; No.&nbsp; It was made to run on top of a
connectionless *network* service.</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; And where</FONT> <BR><FONT
SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; are those connectionless service
specified somewhere in the RFC</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; 1006,1859 and 2126.&nbsp; I looked, they
ain't.</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; SCCP does not provide a &quot;true&quot;
connection-less service.&nbsp; It only</FONT> <BR><FONT SIZE=2>&gt; provides
the &quot;appearance&quot; of a connection-less service to NSP users.</FONT>
</P>

<P><FONT SIZE=2>It seems all those years I have been wrong. It was just a
apperance of connectionless service. That is a very weird concept, because
that would imply that MTP lvl 3 would also give the &quot;apperance&quot; of
a connectionless service. Maybe try to explain the difference between real
connectionless and &quot;fake&quot;(for sake of a better name)
connectionless.&nbsp; </FONT></P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Q.711 Section 5.5:</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;NOTE - This model is intended solely to describe the </FONT> <BR><FONT
SIZE=2>&gt; appearance</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of the
connectionless-mode network service to the SCCP users.</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It is not
intended to be a model of the internal operation of</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the
service provider in providing the connectionless network</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
service.&quot;</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; Thus we have to specify that
ourselves and thus we are </FONT> <BR><FONT SIZE=2>&gt; NOT
reinventing</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; the
wheel.</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The reason the you will not find this in 1006, 1859
and 2126 </FONT> <BR><FONT SIZE=2>&gt; is because</FONT> <BR><FONT
SIZE=2>&gt; the mapping from N-UNITDATA request and N-UNITDATA indication
onto UDP</FONT> <BR><FONT SIZE=2>&gt; for connection-less support is
trivial.&nbsp; Even the (for further study)</FONT> <BR><FONT SIZE=2>&gt;
N-NOTICE is a trivial and direct mapping onto ICMP.</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In those specifications, you will see that TCP with
the extensions</FONT> <BR><FONT SIZE=2>&gt; provided, define a
connection-oriented *Network Service* in </FONT> <BR><FONT SIZE=2>&gt;
support of </FONT> <BR><FONT SIZE=2>&gt; OSI transport.</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; And how are we going to
transport our addresses, namely </FONT> <BR><FONT SIZE=2>&gt; our
Global</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; Titles. As OSI
NSAP's maybe? With no support for any </FONT> <BR><FONT SIZE=2>&gt;
numbering plan</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; besides
E164(well tell that to a GSM operator and most </FONT> <BR><FONT SIZE=2>&gt;
important to</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; its
customers -&gt; they are going to kill you, especially </FONT> <BR><FONT
SIZE=2>&gt; the female</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;
part), no translation type, nature-of-address: somewhere </FONT> <BR><FONT
SIZE=2>&gt; in the middle</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; of nowhere.</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Gee, the IP network already has an addressing scheme,
I would suggest</FONT> <BR><FONT SIZE=2>&gt; that the SG map from SS7 GTT to
the addresses (IP address, </FONT> <BR><FONT SIZE=2>&gt; port
numbers,</FONT> <BR><FONT SIZE=2>&gt; even SCTP stream ids) already
available in the IP network.</FONT> </P>

<P><FONT SIZE=2>That doesn't answer the question, and by the way you break
the end-to-end principle(no not the internet one, but the SS7 one) if no
support for SCCP addressing is provided in this adaptation of yours.
</FONT></P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; &gt; Also, these approaches to ISO Transport over TCP
do not</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; &gt; encapsulate
the transport primitives in the TCP data stream,</FONT> <BR><FONT
SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; &gt; but rather, map the primitives onto
TCP's ULP interface.</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;
&gt; I put it to you that the transport of TCAP (SCCP users) over</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; &gt; TCP has already been
specified in the cited RFCs and that</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; &gt; all is missing is a similar mapping to SCTP as
these RFCs</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; &gt; provide
for TCP.</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; Great, every SCCP connection
gets its own TCP/SCTP connection,</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; congratulations.</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Uh, no.&nbsp; It is possible to map connections onto
streams, rather than</FONT> <BR><FONT SIZE=2>&gt; associations.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; And where the hell is the
connectionless service???.</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; The one that makes everything WORK.</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; No need to swear.&nbsp; Where is the connectionless
service in MTP?&nbsp; MTP</FONT> <BR><FONT SIZE=2>&gt; does not provide true
connectionless network services.&nbsp; Where is it</FONT> <BR><FONT
SIZE=2>&gt; in TCP/IP?&nbsp; It happens to be called UDP.</FONT> </P>

<P><FONT SIZE=2>Yes, but without congestion control. What you are suggesting
here is to do the connectionless stuff over UDP WITHOUT congestion
control.(..............................................)</FONT></P>

<P><FONT SIZE=2>Congestion occurs in the SS7 network, sometimes a lot more
than we would like. SS7 is not some small network(is not longer a little
girl) where the linkload never gets over 25%. It is a collection of SS7
networks(sometimes very big networks, certainly when looking at the number
of people using them) which at this moment has to service 300 million
people(give or take 100 million). We have a SMS craze over here and would
you believe it but those SMS run also over SS7. (SMS stands for Short
Message Service) </FONT></P>

<P><FONT SIZE=2>It tooks years in standaadisation to get some solutions for
that in MTP lvl 3 and SCCP congestion control and those battles were truly
breathtaking at times. </FONT></P>

<P><FONT SIZE=2>But they are in place in a classic SS7 network. And now
should we restart from scratch without congestion control. </FONT> <BR><FONT
SIZE=2>I gladly leave it to you trying to explain that to both the IETF and
the ITU/ETSI/ANSI. </FONT> </P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; And if you map TCAP over TCP,how will that happen. A
</FONT> <BR><FONT SIZE=2>&gt; TCAP transaction</FONT> <BR><FONT SIZE=2>&gt;
</FONT>
<BR><FONT SIZE=2>&gt; Gee, worked really well on the Telcordia GDI
(SR-35whatever).&nbsp; Also,</FONT> <BR><FONT SIZE=2>&gt; TCAP maps well
even to RPC (which runs over TCP or UDP fine: </FONT> <BR><FONT SIZE=2>&gt;
no-one seems</FONT> <BR><FONT SIZE=2>&gt; to be claiming that opening up all
those RPC sockets is a problem).</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; per SCTP connection. Good lord,
that means for one that </FONT> <BR><FONT SIZE=2>&gt; the SCTP(or</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; TCP) congestion algorithms will
never have the </FONT> <BR><FONT SIZE=2>&gt; possibility to engage.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; TCAP is a request/ response. It
waits for the response, </FONT> <BR><FONT SIZE=2>&gt; it isn't a</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; file transfer protocol where
you send a bunch of messages and the</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; acknowledges come back after a time, followed after a
</FONT> <BR><FONT SIZE=2>&gt; bit more time by</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; the response(if any was needed) of the filetransfer
</FONT> <BR><FONT SIZE=2>&gt; itself. Windows(No</FONT> <BR><FONT
SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; not Microsoft, but the Cwnd) are very
usefull in those </FONT> <BR><FONT SIZE=2>&gt; cases for not</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; overloading the network. With
TCAP you would get one msg </FONT> <BR><FONT SIZE=2>&gt; in flight
and</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; that's it. Due to to
heavy use of TCAP you would have a lot of</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; TCAP/SCTP dialogues/connections open at the same time
</FONT> <BR><FONT SIZE=2>&gt; but hey without</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; congestion control actually working, but the
endpoints and links</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;
clearly in trouble(meaning dropping messages). then the </FONT> <BR><FONT
SIZE=2>&gt; congestion</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;
manager would come in handy, but that doesn't take into </FONT> <BR><FONT
SIZE=2>&gt; acount the way</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; everything is addressed. (And I could get one for
hours and hours</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;
ranting...)</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; You don't need a connection per transaction for
heaven's sake.&nbsp; Your</FONT> <BR><FONT SIZE=2>&gt; not even
thinking.</FONT> </P>

<P><FONT SIZE=2>But I was taking YOUR thinking as basis. </FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Look.&nbsp; TCAP runs fine over ISO NS.&nbsp; It has
run over X.25 (ISO Network</FONT> <BR><FONT SIZE=2>&gt; Service Provider)
just fine in the IS-41 network for many years.</FONT> <BR><FONT SIZE=2>&gt;
RFC 1006, etc., provide a way for TCP to provide ISO Network Services</FONT>
<BR><FONT SIZE=2>&gt; to an ISO Network Service User (ISO Transport).&nbsp;
TCAP could be</FONT> <BR><FONT SIZE=2>&gt; transported over this ISO Network
Service Provider just as easily as</FONT> <BR><FONT SIZE=2>&gt; over X.25
(which *is* connection oriented I might add).</FONT> </P>

<P><FONT SIZE=2>Well good for you, but I am not interested in that. It was
and has never been used in GSM that way. (Yes, I have sold my soul to
GSM(and UMTS), allright , now we all know it)</FONT></P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Besides, I asked nicely for a compelling technical
reason, not a</FONT> <BR><FONT SIZE=2>&gt; treatise showing how much a
person can forget about a topic. ;)</FONT> </P>

<P><FONT SIZE=2>How can I forget something that wasn't there in the first
place.</FONT> </P>

<P><FONT SIZE=2>Conclusion:</FONT>
<BR><FONT SIZE=2>This thread is degrading into a yes/no shouting match with
very little added value. (except for &quot;history of SS7, the phantom
menace&quot;, Seems I am talking about &quot;A new hope&quot; and
&quot;Return of the jedi&quot;, interleaved naturally by &quot;the empire
strike back&quot;). Who said protocols are boring:-)</FONT></P>

<P><FONT SIZE=2>If you think you have a point, write a draft. </FONT>
<BR><FONT SIZE=2>I won't be contributing anymore to this specific
thread.</FONT> </P>

<P><FONT SIZE=2>yours sincerly,</FONT>
<BR><FONT SIZE=2>Lode</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -- </FONT>
<BR><FONT SIZE=2>&gt; Brian F. G. Bidulock</FONT> <BR><FONT SIZE=2>&gt;
[email-masked]</FONT> <BR><FONT SIZE=2>&gt; <A
HREF="http://www.openss7.org/"
TARGET="_blank">http://www.openss7.org/</A></FONT> <BR><FONT SIZE=2>&gt;
</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ---</FONT>
<BR><FONT SIZE=2>&gt; You are currently subscribed to sigtran as:
[email-masked]</FONT> <BR><FONT SIZE=2>&gt; To unsubscribe send
a blank email to </FONT> <BR><FONT SIZE=2>&gt;
[email-masked]</FONT> <BR><FONT SIZE=2>&gt;
</FONT>
</P>

---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY>
</HTML>

</x-html>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Wed, 13 Jun 2001 10:18:38 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: update to M2UA
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [161.44.85.169]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

All:

An update to the M2UA document has been submitted to the IETF editor.  It
should be available in a couple of days.

Outstanding proposals that could use a bit more discussion:

1)  change name of "Interface Identifier" to "Link Reference" as proposed by
      Heinz Prantner
2)  addition of Correlation ID and Correlation ID Ack as proposed by Brian
      Bidulock

Changes:

1)  added a section for timers
2)  separated parameter values into common and M2UA specific as in SUA 3)
removed suggestions for how M2UA should treat SCTP congestion 4)  added
load-share and broadcast traffic mode types 5)  added ASP Identifier to ASP
Up and Notify messages 6)  replaced TTC Data message with TTC Data parameter
to be consistent
     with M3UA

Regards,

Ken

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 13 Jun 2001 09:36:58 -0500
From: Alex Audu <[email-masked]>
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: role and scope of local management in sigtran
X-SMTP-HELO: netmail.alcatel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: netmail.alcatel.com [128.251.168.50]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Srikanth,

Typically, every layer in a layered protocol structure has a layer
management entity that "manages" it. Important functions of the Layer
Manager includes : initializing the protocol layer it controls and getting
it ready for service, monitoring errors during run-time, isolating faults,
collecting performance statistics, managing redundancy, etc,.. for the
protocol layer it manages. So the Layer Manager is an independed program in
its own rights. Once it has initialized the protocol layer (and in this
case, initiating the M-SCTP Establish request), it drops into the
background, monitoring errors, and exceptions etc, ready to react to make
sure the system
survives such exceptions. In short, it does all the maintenace-type jobs for
the protocol layer.

Regards,
Alex.

srikanth wrote:

> Hi
>
>  I am not understanding the role of local managment in m3ua,m2ua etc.The
> local  mangement establish sctp connection,want to know the status of asp
> as,also notify ,error condition.But I am not understanding who will inform
> local management to do all this.
> for example
> M-SCTP Establish request
> Direction LM->M3UA
>  Purpose:LM requests ASP to establish an SCTP association with the SG or
> IPSP
>
> I am not understanding in the above case who will inform LM to make  a
SCTP
> estblish request.
>
> Can anyone inform me the role and scope of Local Management in Sigtran
> group.
>
> Thanks
> srikanth
>
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Adams, Richard Anthony (Richard)" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA: Changes
Date: Wed, 13 Jun 2001 16:59:49 +0100
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: hoemail2.firewall.lucent.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: hoemail2.lucent.com [192.11.226.163]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian and Greg,
at the risk of duplicating others' emails (perhaps !), pls see comments
following:
With kind regards,
Richard A. Adams,
[email-masked], tel : +44 1666 83 2503 fax: + 44 1666 83 2712
Lucent Tech.,
Swindon Road,
Malmesbury,
Wiltshire SN16 9NA.

> >    [Greg2]  I'll agree that the paragraph probably goes too far
> >    into describing an SG internal function, given the discussion.
> >    We tried not to talk about the NIF entity when it came to
> >    management text as it is obviously a very slippery slope, but
> >    readers are "implying" it anyway.  Should we not say something
> >    generic here though?   I haven't seen a rush to defend the text
> >    but for some MTP3 variants it is possible for an SS7 node
> >    (SEP-like model) to send an indication of congestion (TFC) into
> >    the SS7 network.  For the STP-like model it is possible in all
> >    variants.   If no-one else cares though I will certainly delete
> >    the paragraph.
> 
> Greg, why do you keep saying TFC?  TFC is an MTP3 peer-to-peer
> message whose use and procedures are defined in SS7 specifications.
> It implies that an NIF could be conceived of which does not contain
> a fully functioning MTP Level 3 at the SG, and that some simple
> little protocol conversion box could just sent TFC.
	[RAA] According to Q.704 section 11.2.6, and T1.111.4, an "SEP" can
send a TFC if it is "congested". This use is network dependent. We interpret
this TFC to mean "overloaded", implying (admittedly an implementation
dependent) processor overload. As such, it isn't the MTP that detects this,
but nevertheless the SEP's MTP is instructed to send a TFC with the MTP
label OPC the same as the "destination" field inside the TFC. Since Q.704
doesn't say that the receiving node (that with point code the same as the
MTP label DPC) should check to see that the signalling point sending the TFC
is an STP, and since Q.704 doesn't say that the TFC's MTP label OPC should
be different from the referred-to destination, the receiving MTP will send
an MTP-status primitive to its local User(s). They then should reduce
(message) traffic to the affected DPC. So, any box with its own point code,
with a processor  that is overloaded could send a TFC. Whether or not you
want that in the networks here, I leave to you ![raa]
> I believe that what you are trying to indicate is that the NIF tells
> MTP3 in some implementation depedent way that it has detected an
> MSU which was to be routed on a congested link, or somehow spliced
> into the HMRT functions.  Then MTP3 decides, per appropriate
> standards whether and when to launch a TFC.
	[RAA] not my interpretation. [raa]
> However, if the SPMC is considered local to the SG, there is no
> HMRT function to "splice into".  It is only the HMDT function in
> MTP3 which provides access to MTP users.  There is no way of
> "splicing into" the HMDT function with a congestion indication
> as MTP3 is defined.
	[RAA] The SDLs won't show this, but the text is full of weasel
words! . I'll cut the rest of your emails, because the text in 11.2.6 of
Q.704 was inserted to be able to handle overload and congestion for
applications which at the time didn't have their own flow/load control. Some
still don't (e.g. SCCP now has flow control, but it relies upon the SCCP
User to specify message importance), and some can't relate anything about
nodal problems. [raa]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Balani, Sandeep" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: SS7 Links Inservice, and ASP goes INACTIVE/DOWN ....
Date: Wed, 13 Jun 2001 10:29:48 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hebe.or.intel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: jffdns02.or.intel.com [134.134.248.4]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Ken, 
   I was going thru the M2UA draft version 7  and i found the following text
inconsistent.  

In section 1.5.4 it says " If the AS moves to the DOWN state while SS7 links
are in-service, the SG SHOULD follow the MTP 2 processor outage procedures
[2]. " 

While in section 4.3.1.2 for describing T(r) timer expiry  in paragraph 4 it
states : 
 " If T(r) expires before an ASP becomes active, the SG stops queueing
messages and discards all previously queued messages.  In addition, the SG
SHALL send the Stop primitive to MTP2 to take the link out of service.  The
AS will move to AS-Inactive if at least one ASP is in ASP-Inactive state,
otherwise it will move to AS-DOWN state "

In first description it says follow "LPO procedure" for AS state change from
ACTIVE to INACTIVE/DOWN, but in second description it states take the "SS7
links Out Of Service" in same AS state transition. 

Ken, if u think that it is an descrepencies in M2UA version 7 draft
description, is it possible to change in the next version of M2UA draft. 

Thanks
Sandeep  

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Wed, 13 Jun 2001 15:07:58 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: SS7 Links Inservice, and ASP goes INACTIVE/DOWN ....
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Sandeep,

Yes, there is a discrepancy between these two statements.  Going back to
some old notes (the San Diego meeting), there was a general consensus to
take the links out-of-service if the AS transitioned to a "Down" state
whether due to a SCTP CDI or receipt of an ASP Down.

Of course, ideally an ASP would take the links out-of-service before sending
an ASP Down.

Regards,

Ken

At 10:29 AM 6/13/01 -0700, Balani, Sandeep wrote:
>Hi Ken, 
>    I was going thru the M2UA draft version 7  and i found the following
text
>inconsistent.  
>
>In section 1.5.4 it says " If the AS moves to the DOWN
>state while SS7 links are in-service, the SG SHOULD follow the MTP 2 
>processor outage procedures [2]. " 
>
>While in section 4.3.1.2 for describing T(r) timer expiry  in paragraph 4
it
>states : 
>  " If T(r) expires before an ASP becomes active, the SG stops queueing
>messages and discards all previously queued messages.  In addition,
>the SG SHALL send the Stop primitive to MTP2 to take the link out of 
>service.  The AS will move to AS-Inactive if at least one ASP is in 
>ASP-Inactive state, otherwise it will move to AS-DOWN state "
>
>In first description it says follow "LPO procedure" for AS state change
from
>ACTIVE to INACTIVE/DOWN, but in second description it states take the "SS7
>links Out Of Service" in same AS state transition. 
>
>Ken, if u think that it is an descrepencies in M2UA version 7 draft
>description, is it possible to change in the next version of M2UA draft. 
>
>Thanks
>Sandeep  
>
>
>
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Reply-To: [email-masked]
From: srikanth <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: role and scope of local management in sigtran
Date: Thu, 14 Jun 2001 10:24:23 +0530
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-SMTP-HELO: india.mercurykr.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [165.133.13.60]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hi

      Very many thanks for Alex for giving me useful information.I think
there are lot of primitives that has to be added in m3ua,m2ua,sctp for local
management in addition to that given in IETF draft.I want to know the
additional primitives that will be added in local management for this
adaptation layers .

Thanks
srikanth
----- Original Message -----
From: Alex Audu <[email-masked]> To: sigtran
<[email-masked]> Sent: Wednesday, June 13, 2001 8:06 PM
Subject: Re: role and scope of local management in sigtran

> Srikanth,
>
> Typically, every layer in a layered protocol structure has a layer
management entity
> that "manages" it. Important functions of the Layer Manager includes :
initializing
> the protocol layer it controls and getting it
> ready for service, monitoring errors during run-time, isolating faults,
collecting
> performance statistics, managing redundancy, etc,.. for the protocol layer
it
> manages. So the Layer Manager is an independed program in its own rights.
Once it has
> initialized the protocol layer (and in this case, initiating the M-SCTP
Establish
> request), it drops into the background, monitoring errors, and exceptions
etc, ready
> to react to make sure the system
> survives such exceptions. In short, it does all the maintenace-type jobs
for the
> protocol layer.
>
> Regards,
> Alex.
>
> srikanth wrote:
>
> > Hi
> >
> >  I am not understanding the role of local managment in m3ua,m2ua etc.The
> > local  mangement establish sctp connection,want to know the status of
asp
> > as,also notify ,error condition.But I am not understanding who will
inform
> > local management to do all this.
> > for example
> > M-SCTP Establish request
> > Direction LM->M3UA
> >  Purpose:LM requests ASP to establish an SCTP association with the SG or
> > IPSP
> >
> > I am not understanding in the above case who will inform LM to make  a
SCTP
> > estblish request.
> >
> > Can anyone inform me the role and scope of Local Management in Sigtran
> > group.
> >
> > Thanks
> > srikanth
> >
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to
[email-masked]
>
>
>
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 14 Jun 2001 01:43:04 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA : SG Load Sharing
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      BAA15243
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Mukesh,

Let me venture an answer:

In the multiple SG arrangement, each SG has its own signalling point code
and is acting as an STP in the network.  Selection of SG is implementation
dependent but could be performed on a similar basis as A-link selection at
an SEP in the SS7 network.  Should an SG fail, it is similar to an STP
failing in the SS7 network today.
Messages will be lost and the sending SEP will be faced with discarding all
messages which were already transmitted to the other end (whether
acknowledged or not).

STP's are engineered to fail for less than about 1 minute per year or to
about .999998 reliability, to avoid this situation.

In general, an SEP cannot distinguish between STP failure and the failure of
all signalling links to an STP, except that a transfer prohibited message
might be received on the alternate link in the case of STP failure.

Because M3UA has no changeover procedures from ASP to SG, it is likely that
messages will be mis-sequenced if traffic is not withheld for some period
before sending SLSs which were previouly sent via the failed SG to the
alternate SG.  I would recommend procedures similar to time-controlled
changeover.

To meet reliablity requirements, however, SCTP associations between an ASP
and an SG, by analogy might have to be engineered to the reliablity of an
entire SS7 linkset.  This would be particularly challenging.

So, it is not specified in the M3UA, but of your two choices, I would pick
(b), i.e, withhold traffic for a short period before restarting the SLSs on
the alternate SG.

Should the failed SG recover, it will be necessary to perform some sort of
changeback as well.  Here it might be quite possible for the ASP to slip a
changeback message into the data stream for the SLSs to be changed back and
if the SG will transfer the changeback acks, changeover the traffic in a
coordinated fashion instead of performing time-controlled rerouting.  I
suppose that is up to you.

It does bring up the question as to whether M3UA at the SG should rather
*not* terminal *all* MTP MGMT messages, but should allow changeback acks
through.

Certainly, if an Correlation Id and Acknowledgement were provided on MSUs
transfered between SG and ASP, normal or emergency changeover could be
performed in the event of a failed SCTP association, however, a
time-controlled changeover would still apply in the case of SG failure.

Withough some sort of sequence numbering, normal changeover is impossible,
resulting in an increase in discarded messages resulting from changeover.
Withough passing changeback messages, coordinated changeback is impossible,
resulting in increased delay and possibility of missequencing resulting from
changeback.

With this consideration, to meet the capabilities of a combined A-link set,
M3UA might need to required even more that A-link set reliability from the
SCTP association from ASP to SG.  This should be quite challenging for
implementors and operators.

A proposal for changeover and changeback procedures would alleviate some of
this requirement on SCTP reliability, but previous proposals for changeover
and changeback in M3UA have not been well received.

--Brian

[email-masked] wrote:                     (Tue, 12 Jun 2001 16:30:57)
> 
> 
> 
> 
> Hi,
> 
> This is regarding SG Load Sharing from ASP side.
> 
> As draft says the loadsharing can be done on the basis of SLS:
> "In order to direct messages to the SS7 network, the ASP must also perform
a
> message distribution function in order to choose the proper
> SG or SGP for a given message.
> 
>  This is accomplished by observing the
> Destination Point Code (and possibly other elements of the outgoing
> message such as the SLS value), together with the SS7 destination
> availability/restricted/congestion status via the SG(s) and the
availability of
> the SG and SGPs themselves."
> 
> Suppose there are two SGs active in load shared mode and traffic is being
load
> shared on the basis of SLS value.  Both SGs give identical DPC rechability
to
> SS7 network.  Now if one SG goes down(or association to that SG fails)
then how
> should SLS values assigned to failed SG be handled in order to avoid
> mis-sequencing.
> a) Have a pre-defined set of SLS values for each SG.  In this case if one
SG
> failes its's assigned SLS values won't have a route.
> OR
> b) Using time controlled changeover i.e. retrieving messages from failed
> association, wait for a timer period and then resent retrieved messages on
> alternate association.
> 
> Or is there any other option.
> 
> 
> Thanks and Regards
> -Mukesh
> 
> 

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 14 Jun 2001 02:01:09 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA: Changes
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Richard,

Please see comments below.

Adams, Richard Anthony (Richard) wrote:                    (Wed, 13 Jun 2001
16:59:49)
> 
> 
> > >    [Greg2]  I'll agree that the paragraph probably goes too far
> > >    into describing an SG internal function, given the discussion.
> > >    We tried not to talk about the NIF entity when it came to
> > >    management text as it is obviously a very slippery slope, but
> > >    readers are "implying" it anyway.  Should we not say something
> > >    generic here though?   I haven't seen a rush to defend the text
> > >    but for some MTP3 variants it is possible for an SS7 node
> > >    (SEP-like model) to send an indication of congestion (TFC) into
> > >    the SS7 network.  For the STP-like model it is possible in all
> > >    variants.   If no-one else cares though I will certainly delete
> > >    the paragraph.
> > 
> > Greg, why do you keep saying TFC?  TFC is an MTP3 peer-to-peer
> > message whose use and procedures are defined in SS7 specifications.
> > It implies that an NIF could be conceived of which does not contain
> > a fully functioning MTP Level 3 at the SG, and that some simple
> > little protocol conversion box could just sent TFC.
> 	[RAA] According to Q.704 section 11.2.6, and T1.111.4, an "SEP" can
> send a TFC if it is "congested". This use is network dependent. We
interpret
> this TFC to mean "overloaded", implying (admittedly an implementation
> dependent) processor overload. As such, it isn't the MTP that detects
this,
> but nevertheless the SEP's MTP is instructed to send a TFC with the MTP
> label OPC the same as the "destination" field inside the TFC. Since Q.704
> doesn't say that the receiving node (that with point code the same as the
> MTP label DPC) should check to see that the signalling point sending the
TFC
> is an STP, and since Q.704 doesn't say that the TFC's MTP label OPC should
> be different from the referred-to destination, the receiving MTP will send
> an MTP-status primitive to its local User(s). They then should reduce
> (message) traffic to the affected DPC. So, any box with its own point
code,
> with a processor  that is overloaded could send a TFC. Whether or not you
> want that in the networks here, I leave to you ![raa]

That is what I would like the M3UA spec to do: leave it to me to read,
implement, and conform to MTP specifications.  I would rather that M3UA does
not attempt to tell me what I "should" do in that regard.

Do you think that the text is necessary to the M3UA document?

> > I believe that what you are trying to indicate is that the NIF tells
> > MTP3 in some implementation depedent way that it has detected an
> > MSU which was to be routed on a congested link, or somehow spliced
> > into the HMRT functions.  Then MTP3 decides, per appropriate
> > standards whether and when to launch a TFC.
> 	[RAA] not my interpretation. [raa]

I don't understand this comment.  Is it not your interpretation that MTP3
decides when to launch a TFC per appropriate standards?  What is your
interpretation?

> > However, if the SPMC is considered local to the SG, there is no
> > HMRT function to "splice into".  It is only the HMDT function in
> > MTP3 which provides access to MTP users.  There is no way of
> > "splicing into" the HMDT function with a congestion indication
> > as MTP3 is defined.
> 	[RAA] The SDLs won't show this, but the text is full of weasel
> words! . I'll cut the rest of your emails, because the text in 11.2.6 of
> Q.704 was inserted to be able to handle overload and congestion for
> applications which at the time didn't have their own flow/load control.
Some
> still don't (e.g. SCCP now has flow control, but it relies upon the SCCP
> User to specify message importance), and some can't relate anything about
> nodal problems. [raa]

SCCP's may be crude, but many TCAPs have it.  SCCP class 3 has it for CO.
ISUP has it.  Which are those without flow control at the application level?

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Original-Received: by system.mail(WebEasyMail 3.2.0.1) 
                   http://www.rockislands.com Thu, 14 Jun 2001 12:15:53
-0000
PP-warning: Illegal Received field on preceding line
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: Computer/ Vacation Confirmation 88
Date: Thu, 14 Jun 2001 00:02:35
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-SMTP-HELO: ecarsaaa.nortelnetworks.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [202.103.25.168]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<HTML><FONT  COLOR="#000080" BACK="#ffffff" style="BACKGROUND-COLOR:
#ffffff" SIZE=3 PTSIZE=11 FAMILY="SERIF" FACE="Times New Roman"
LANG="0"><BR> </P><P ALIGN=CENTER></FONT><FONT  COLOR="#000080"
BACK="#ffffff" style="BACKGROUND-COLOR: #ffffff" SIZE=3 PTSIZE=12
FAMILY="SERIF" FACE="Times New Roman" LANG="0">Congratulations!</FONT><FONT
COLOR="#000080" BACK="#ffffff" style="BACKGROUND-COLOR: #ffffff" SIZE=3
PTSIZE=11 FAMILY="SERIF" FACE="Times New Roman" LANG="0"> You've been
selected<BR> for a chance to win one of the exclusive <BR> </FONT><FONT
COLOR="#0000ff" BACK="#ffffff" style="BACKGROUND-COLOR: #ffffff" SIZE=3
PTSIZE=11 FAMILY="SERIF" FACE="Times New Roman" LANG="0">Vacation Packages
and/or a Pentium PC</FONT><FONT  COLOR="#000080" BACK="#ffffff"
style="BACKGROUND-COLOR: #ffffff" SIZE=3 PTSIZE=11 FAMILY="SERIF"
FACE="Times New Roman" LANG="0"> <BR> below courtesy of...</FONT><FONT
COLOR="#000080" BACK="#ffffff" style="BACKGROUND-COLOR: #ffffff" SIZE=2
PTSIZE=10 FAMILY="SERIF" FACE="Times New Roman" LANG="0"><BR> </FONT><FONT
COLOR="#000000" BACK="#ffffff" style="BACKGROUND-COLOR: #ffffff" SIZE=2
PTSIZE=10 FAMILY="SERIF" FACE="Times New Roman" LANG="0"><BR> </FONT><FONT
COLOR="#ff0000" BACK="#ffffff" style="BACKGROUND-COLOR: #ffffff" SIZE=3
PTSIZE=12 FAMILY="SERIF" FACE="Times New Roman" LANG="0"><B>National
Vacation Promotions!</FONT><FONT  COLOR="#0000ff" BACK="#ffffff"
style="BACKGROUND-COLOR: #ffffff" SIZE=2 PTSIZE=10 FAMILY="SERIF"
FACE="Times New Roman" LANG="0"><BR> </FONT><FONT  COLOR="#000000"
BACK="#ffffff" style="BACKGROUND-COLOR: #ffffff" SIZE=2 PTSIZE=10
FAMILY="SERIF" FACE="Times New Roman" LANG="0"></B><BR> </FONT><FONT
COLOR="#000080" BACK="#ffffff" style="BACKGROUND-COLOR: #ffffff" SIZE=2
PTSIZE=10 FAMILY="SERIF" FACE="Times New Roman" LANG="0">This is the real
thing! <BR> Simply fill out the form below<BR>
and register to win - 5 drawings weekly.<BR> <BR>
</FONT><FONT  COLOR="#0000ff" BACK="#ffffff" style="BACKGROUND-COLOR:
#ffffff" SIZE=3 PTSIZE=12 FAMILY="SERIF" FACE="Times New Roman"
LANG="0"><B><A HREF="http://nieyongxin4.www12.cn4e.com/user9/">Register
Below and Win Today!</A></B></FONT><FONT  COLOR="#000000" BACK="#ffffff"
style="BACKGROUND-COLOR: #ffffff" SIZE=2 PTSIZE=10 FAMILY="SERIF"
FACE="Times New Roman" LANG="0"></B><BR> <BR>
</P><P ALIGN=LEFT><BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
</P><P ALIGN=CENTER></FONT><FONT  COLOR="#000000" BACK="#ffffff"
style="BACKGROUND-COLOR: #ffffff" SIZE=1 PTSIZE=8 FAMILY="SERIF" FACE="Times
New Roman" LANG="0">You were sent this message because your address is in
our subscriber database. <BR> If you wish to be removed, please <B><A
HREF="http://nieyongxin4.www12.cn4e.com/user9/remove.htm>CLICK
HERE</A></B></FONT><FONT  COLOR="#ff0000" BACK="#ffffff"
style="BACKGROUND-COLOR: #ffffff" SIZE=1 PTSIZE=8 FAMILY="SERIF" FACE="Times
New Roman" LANG="0"></B> </FONT><FONT  COLOR="#000000" BACK="#ffffff"
style="BACKGROUND-COLOR: #ffffff" SIZE=1 PTSIZE=8 FAMILY="SERIF" FACE="Times
New Roman" LANG="0">and we will remove you from our subscriber
list.</FONT><FONT  COLOR="#ff0000" BACK="#ffffff" style="BACKGROUND-COLOR:
#ffffff" SIZE=1 PTSIZE=8 FAMILY="SERIF" FACE="Times New Roman" LANG="0"><BR>
<BR>
</P></FONT>
---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </html>

</x-html>
Date: Thu, 14 Jun 2001 02:26:45 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SS7 Links Inservice, and ASP goes INACTIVE/DOWN ....
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

Are you saying that the links will be immediately forced out of service or
will T(r) still be applied?  Can I set T(r) to 0?
To avoid message loss in this event, either SIPO should be sent on the link,
or SIB, acknowledgements withheld, or SIOS sent to the MTP2 peer so that
these messages are not lost forever.

A delay T(r), if T(r) is some integer number of seconds, could result in a
great number of messages being lost to the MTP2 peer which could have been
sent on alternative links.

Of the choices, sending SIPO for the period is most appropriate if the SG
expects another ASP in the AS to pick up the load.
This was well supported on the list last November.

The proscribed procedure (waiting T(r) and discarding) will increase the
message loss and mis-sequencing (from changeover) and require higher
reliability of the SCTP associations to the ASP and higher reliability of
the ASP to meet the same traffic objectives.

Because the choice of this procedure is solely a matter for the SG and it
has no interoperability impacts on the ASP (the SG cannot even communicate
with it at this time), I propose that M2UA leave it as implementation
dependent and give leave to the SG implementor to decide which procedures
will best meet SS7 reliability objectives.

--Brian

Ken Morneault wrote:                            (Wed, 13 Jun 2001 15:07:58)
> 
> 
> Sandeep,
> 
> Yes, there is a discrepancy between these two statements.  Going
> back to some old notes (the San Diego meeting), there was a general
> consensus to take the links out-of-service if the AS transitioned to
> a "Down" state whether due to a SCTP CDI or receipt of an ASP Down.
> 
> Of course, ideally an ASP would take the links out-of-service before
> sending an ASP Down.
> 
> Regards,
> 
> Ken
> 
> 
> At 10:29 AM 6/13/01 -0700, Balani, Sandeep wrote:
> >Hi Ken, 
> >    I was going thru the M2UA draft version 7  and i found the following
text
> >inconsistent.  
> >
> >In section 1.5.4 it says " If the AS moves to the DOWN
> >state while SS7 links are in-service, the SG SHOULD follow the MTP 2 
> >processor outage procedures [2]. " 
> >
> >While in section 4.3.1.2 for describing T(r) timer expiry  in paragraph 4
it
> >states: 
> >  " If T(r) expires before an ASP becomes active, the SG stops queueing
> >messages and discards all previously queued messages.  In addition,
> >the SG SHALL send the Stop primitive to MTP2 to take the link out of 
> >service.  The AS will move to AS-Inactive if at least one ASP is in 
> >ASP-Inactive state, otherwise it will move to AS-DOWN state "
> >
> >In first description it says follow "LPO procedure" for AS state change
from
> >ACTIVE to INACTIVE/DOWN, but in second description it states take the
"SS7
> >links Out Of Service" in same AS state transition. 
> >
> >Ken, if u think that it is an descrepencies in M2UA version 7 draft
> >description, is it possible to change in the next version of M2UA draft. 
> >
> >Thanks
> >Sandeep  
> >
> >
> >
> >
> >
> >---
> >You are currently subscribed to sigtran as: [email-masked]
> >To unsubscribe send a blank email to
[email-masked] 
> 
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 14 Jun 2001 02:32:00 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Reinventing the Wheel
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Verwimp,

In comparison to an OSI NSP, I would not even call TCP or SCTP a transport,
I would call them network services, and that is what RFC 1006 uses TCP as.

Verwimp Gery wrote:                            (Tue, 12 Jun 2001 11:48:30)
> 
>    Brian,
>    
>    When comparing the CCITT stack with the OSI-stack, the layers 4 - 6
>    (transport, session, presentation) are considered "empty" in the CCITT
>    stack. TCAP and the applications are depicted in layer 7.
>    
>    Of course, the MTP/SCCP layers already provide so many features (quasi
>    no message loss, in sequence delivery, notification of undeliverable
>    messages, segmentation/reassembly, ...) that there's hardly anything
>    to do for these layers except for playing go-between.
>    
>    Arguably, TCAP covers a little bit of all these layers (ASN.1 encoding
>    according to BER => layer 6 ? common framework for executing remote
>    operations and Application Context negotiation => layer 5 ? end-to-end
>    transactions => layer 4 ?), but it's hardly a full-fledged transport
>    layer such as TCP or SCTP.

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 14 Jun 2001 03:05:02 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Reinventing the Wheel
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Coene,

Coene Lode wrote:                                           (Wed, 13 Jun
2001 11:47:41)
>
>    Maybe you like describing the original X25 centric way that it was
>    first conceived and described(and subsequentely never removed in the
>    specs) But what you describe is the situation from 15 years back(where
>    x25,it seems, was still king). It evolved and practically junked all
>    the X25 stuff. And sure also ISO stuff was rather popular in those
>    days. A couple a references to ISO wouldn't hurt(even normative) but
>    the specs of TCAP and SCCP are selfcontained, meaning you can
>    implement them without even giving the slightest look to any of those
>    ISO or X25 specs. I did it that way and nobody ever complained.

   "It is noted that the time sequence of primitives in the reset
    procedure may be varied as long as it is consistent with
    Recommendation X.213."

You were obviously not worried about interoperation in this an other
respects with implemenators who had read X.213.

>    
>    By the way how you implement your primitives and their parameters is a
>    implementation dependant issue. The real gut lies in the messages
>    syntax and its semantics and those are a very far cry from OSI. You
>    get that wrong and everybody knows.

The NSD does not define the protocol, it defines the interface.  How you
implement the interface is up to you, but the purpose of the OSI model was
to allow different protocols to be placed under the various layers.  By
following the NSD, this is what IS-41 accomplished with X.25 carrying TCAP
along with SCCP.

>    
>    You have a point for TCAP(yes )..: It has nearly the same syntax(and
>    semantics) for its messages as the ROSE and the ACSE. But that doesn't
>    make it a ISO protocol just we borrowed a few good ideas from them.
>    
>    >
>    > On Mon, 11 Jun 2001, Coene Lode wrote:
>    > >
>    > >    Neither SCCP nor TCAP are ISO network or transport services.
>    > >    Especially SCCP is NOT a ISO network service. I have
>    > never run into a
>    > >    ISO spec specifying anything close to the things SCCP
>    > do. (Oh yes ,
>    > >    apart from doing the Connection oriented service but
>    > that is only one
>    > >    of the SCCP services, big deal)
>    > >
>    >
>    > ANSI T1.112.1 Section 1.1:
>    >
>    >         "The Network Service Part meets the requirements for Layer
>    >          3 services as defined in the CCITT Recommendation X.200,
>    >          Reference Model of Open Systems Interconnect for CCITT
>    >          Applications."
>    >
>    > Q.711 Section 5.1:
>    >
>    >         "The service interfaces to the upper layers and to MTP are
>    >          described by means of primitives and parameters, as
>    > recommended
>    >          in Recommendation X.200."
>    >
>    > Perhaps you didn't know that X.200 was ISO/IEC 7498.
>    >
>    > ANSI T1.112.1 Sction 2.1.1.2.1:
>    >
>    >         "(Refer to CCITT Recommendation X.213, Network Layer Service
>    >          Definition of Openn Systems Interconnect for CCITT
>    > Application.)"
>    >
>    >
>    > An in Q.711, we find X.213 (ISO/IEC 8348) as a "Normative"
>    > reference...
>    >
>    > Perhaps you didn't know that X.213 was ISO/IEC 8348.
>    >
>    > I'm, sorry, but SCCP *is* an OSI/ISO network service provider.
>    
>    Those are references to the primitive interface. And they are only
>    used in the introduction. They then go on specifying their own
>    protocol which can be understood without ever having to read the ISO
>    documents.

But still permits portability of SCTP-Users to other NSPs satisfying the
NSD.

>    
>    Perhaps the SCCP you know run on a ISO network but the girl I know
>    runs on a SS7 network The SCCP i know does not support ISO adresses.
>    Thus if the native ISO addressing is not supported , how the hell can
>    be it be anything ISO. That is just the same as claiming SCCP is a
>    internet protocol while it can not even support internet addressing.
>    Now in due course TI-SCCP and SUA will and they may rightly claim that
>    title and some other people will fight over that.
>    
>    In the 10 years that I have done SS7, ISO has palyed a very small role
>    in SS7. And if it did, then it was in TCAP concering some aligments
>    with updated specs of ASN1. But real important groundbreaking stuff,
>    no.

About 5 years before you started "doing SS7," it was wished that OSI had
been completed before MTP, so that MTP could have followed the ISO model as
well.  OSI was the groundbreaking stuff which permitted SCCP and TCAP.
>    
>    Which sets you apart from the rest because that is simply not the
>    case. Transport layers are supposed to do much more than TCAP does.
>    Gey explains it even better than me, so read his mail.

A null transport is a transport.  Where the network service provider can
provide all the services required of the transport user, a simple mapping of
the TSD to the NSD is possible.  Gey didn't explain it so good, see my
response.

>    
>    It seems all those years I have been wrong. It was just a apperance of
>    connectionless service. That is a very weird concept, because that
>    would imply that MTP lvl 3 would also give the "apperance" of a
>    connectionless service. Maybe try to explain the difference between
>    real connectionless and "fake"(for sake of a better name)
>    connectionless.

MTP is composed of a number of virtual connections which are a full mesh of
connections identified by the vector [PC,PC,SLS].  These connections are
permanent connections which are established when the network is configured
and provide strong assurances on bandwidth and reliability of the virtual
channel.  When you send your "connectionless" message a connection is
selected [PC,PC,SLS] and the message is sent on that connection.  A true
connectionless network would not have to choose an assured virtual
connection upon which to send a message.
>    
>    That doesn't answer the question, and by the way you break the
>    end-to-end principle(no not the internet one, but the SS7 one) if no
>    support for SCCP addressing is provided in this adaptation of yours.
>    
RFC 1006 uses IP addresses to support the NSD.  Performing connections at an
SCCP relay point from NSD to NSD is already defined.  Address mapping is
trivial.

>    
>    Yes, but without congestion control. What you are suggesting here is
>    to do the connectionless stuff over UDP WITHOUT congestion
>    control.(..............................................)

TCAP provides congestion control.  SCCP provides congestion control on Class
3.

>    
>    Congestion occurs in the SS7 network, sometimes a lot more than we
>    would like. SS7 is not some small network(is not longer a little girl)
>    where the linkload never gets over 25%. It is a collection of SS7
>    networks(sometimes very big networks, certainly when looking at the
>    number of people using them) which at this moment has to service 300
>    million people(give or take 100 million). We have a SMS craze over
>    here and would you believe it but those SMS run also over SS7. (SMS
>    stands for Short Message Service)
>    
>    It tooks years in standaadisation to get some solutions for that in
>    MTP lvl 3 and SCCP congestion control and those battles were truly
>    breathtaking at times.

It would be great if SUA addressed congestion controls, but it doesn't.

>    
>    But they are in place in a classic SS7 network. And now should we
>    restart from scratch without congestion control.
>    I gladly leave it to you trying to explain that to both the IETF and
>    the ITU/ETSI/ANSI.

TCAP provides congestion control.  SCCP provides congestion control on Class
3.

If your SMS service does not provide congestion controls at the application
level, you can keep it off of my SS7 network.  I would not permit your SMS
to run with my ISUP with only MTP Level 3 congestion to stop it (and my ISUP
at the same time).

I think that you are confusing forms of congestion.

>    
>    Well good for you, but I am not interested in that. It was and has
>    never been used in GSM that way. (Yes, I have sold my soul to GSM(and
>    UMTS), allright , now we all know it)
>    
It still demonstrates the principle and provides a proof of concept.

As you have not even mentioned SUA, I presume that you know of no reason why
one might want to use it in contrast to the other possible approaches.

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 14 Jun 2001 03:11:03 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Reinventing the Wheel
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-202.dallas.net [209.44.42.202]
List-Unsubscribe: <mailto:[email-masked]>

Verwimp,

Where is SUA more applicable?  The scope of the draft implies that "there
may be some need" or SUA?  What is the need if these other approaches exist?
Does SUA provide something that the others cannot?  Does it provide
something better in some respect?

Verwimp Gery wrote:                          (Tue, 12 Jun 2001 11:09:32)
> 
>    Hello Brian,
>    
>    There are a number of alternatives already to transport SCCP-user
>    messages over an IP-network :
>    
>    - use SCCP over M3UA
>    - use TI-SCCP (Transport Independent-SCCP) over STC (Signalling
>    Transport Converter, as defined in Q.1901) over SCTP
>    - use SUA
>    - use RFC 2126, with adaptation to SCTP as the transport layer.
>    
>    One solution or the other will be easier to implement, depending on
>    what you have already in your boxes. And in my opinion, either one
>    would work fine, at least in small networks.
>    
[snip]

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Reinventing the Wheel
Date: Thu, 14 Jun 2001 11:42:03 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades6.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mailhost2.atea.be [194.78.143.126]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: Reinventing the Wheel</TITLE> </HEAD>
<BODY>

<P><FONT SIZE=2>Brian,</FONT>
</P>

<P><FONT SIZE=2>(BTW : my first name's Gery)</FONT> </P>

<P><FONT SIZE=2>See comments below.</FONT> </P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT> <BR><FONT SIZE=2>From:
Brian F. G. Bidulock [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>Sent: donderdag 14 juni 2001 10:05</FONT> <BR><FONT
SIZE=2>To: sigtran</FONT>
<BR><FONT SIZE=2>Subject: Re: Reinventing the Wheel</FONT> </P>

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; In comparison to an OSI NSP, I would not even call TCP
or SCTP a transport,</FONT> <BR><FONT SIZE=2>&gt; I would call them network
services, and that is what RFC 1006 uses TCP as.</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
</P>

<P><FONT SIZE=2>[GV] : Then we should rename the IETF Area &amp; Working
Group.</FONT> </P>

<P><FONT SIZE=2>[snip, snip]</FONT>
</P>

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; MTP is composed of a number of virtual connections
which are a full</FONT> <BR><FONT SIZE=2>&gt; mesh of connections identified
by the vector [PC,PC,SLS].&nbsp; These</FONT> <BR><FONT SIZE=2>&gt;
connections are permanent connections which are established when the</FONT>
<BR><FONT SIZE=2>&gt; network is configured and provide strong assurances on
bandwidth</FONT> <BR><FONT SIZE=2>&gt; and reliability of the virtual
channel.&nbsp; When you send your</FONT> <BR><FONT SIZE=2>&gt;
&quot;connectionless&quot; message a connection is selected [PC,PC,SLS]
and</FONT> <BR><FONT SIZE=2>&gt; the message is sent on that
connection.&nbsp; A true connectionless network</FONT> <BR><FONT SIZE=2>&gt;
would not have to choose an assured virtual connection upon which to</FONT>
<BR><FONT SIZE=2>&gt; send a message.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
</P>

<P><FONT SIZE=2>[GV] : Well obviously one needs a route to deliver the goods
to the correct address. A network provides routing services, as user you
provide a valid address and some indication of the QoS you want. Just as
sending a letter. MTP provides such services (totally
connectionless).</FONT></P>

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; RFC 1006 uses IP addresses to support the NSD.&nbsp;
Performing connections</FONT> <BR><FONT SIZE=2>&gt; at an SCCP relay point
from NSD to NSD is already defined.&nbsp; Address</FONT> <BR><FONT
SIZE=2>&gt; mapping is trivial.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
</P>

<P><FONT SIZE=2>[GV] : From E.164 to IP-address ? How to select the next NSD
wisely, and how to engineer this in your network, is far from
trivial.</FONT></P>

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; Yes, but without congestion control. What
you are suggesting here is</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; to do the connectionless stuff over UDP
WITHOUT congestion</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
control.(..............................................)</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; TCAP provides congestion control.&nbsp; SCCP provides
congestion control</FONT> <BR><FONT SIZE=2>&gt; on Class 3.</FONT> </P>

<P><FONT SIZE=2>[GV] : ??? Seems I missed something in Q.771-775 or T1.114.
But if you want to run TCAP directly over UDP/IP ...</FONT> <BR><FONT
SIZE=2>SCCP provides flow control on Class 3. For a distinction between flow
control and congestion control, please read the SCTP applicability
statement.</FONT></P>

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; Congestion occurs in the SS7 network,
sometimes a lot more than we</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; would like. SS7 is not some small
network(is not longer a little girl)</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; where the linkload never gets over 25%. It
is a collection of SS7</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
networks(sometimes very big networks, certainly when looking at the</FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; number of people using them)
which at this moment has to service 300</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; million people(give or take 100 million).
We have a SMS craze over</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
here and would you believe it but those SMS run also over SS7. (SMS</FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; stands for Short Message
Service)</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; It tooks years in
standaadisation to get some solutions for that in</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; MTP lvl 3 and SCCP congestion control and
those battles were truly</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
breathtaking at times.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; It would be great if SUA addressed congestion
controls, but it doesn't.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
</P>

<P><FONT SIZE=2>[GV] : We're discussing this right now on the sigtran
mailing list, and we hope to get some feedback !</FONT> </P>

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; If your SMS service does not provide congestion
controls at the</FONT> <BR><FONT SIZE=2>&gt; application level, you can keep
it off of my SS7 network.&nbsp; I would</FONT> <BR><FONT SIZE=2>&gt; not
permit your SMS to run with my ISUP with only MTP Level 3</FONT> <BR><FONT
SIZE=2>&gt; congestion to stop it (and my ISUP at the same time).</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
</P>

<P><FONT SIZE=2>[GV] : SMS's are routed on Global Title. There's no
congestion indication attached to that right now, although there have been
discussions about GT management. Anyway, SCCP maps this on a DPC (next relay
or end node) and will not transfer the message to MTP if the congestion
level of this DPC is &quot;higher&quot; than the message priority (given by
the application).</FONT></P>

<P><FONT SIZE=2>So there's not only MTP-3 to stop it.</FONT> </P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; As you have not even mentioned SUA, I presume that you
know of</FONT> <BR><FONT SIZE=2>&gt; no reason why one might want to use it
in contrast to the other</FONT> <BR><FONT SIZE=2>&gt; possible
approaches.</FONT> <BR><FONT SIZE=2>&gt; </FONT>
</P>

<P><FONT SIZE=2>[GV] : Lode has mentioned it :</FONT> </P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Perhaps the SCCP you know run on a ISO network
but the girl I know</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; runs on a
SS7 network The SCCP i know does not support ISO adresses.</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Thus if the native ISO addressing is not
supported , how the hell can</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
be it be anything ISO. That is just the same as claiming SCCP is a</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; internet protocol while it can not
even support internet addressing.</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Now in due course TI-SCCP and SUA will and
they may rightly claim that</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
title and some other people will fight over that.</FONT> <BR><FONT
SIZE=2>&gt;&nbsp; </FONT>
</P>

<P><FONT SIZE=2>Best regards,</FONT>
<BR><FONT SIZE=2>____________________________</FONT> </P>

<P><FONT SIZE=2>Gery Verwimp</FONT>
<BR><FONT SIZE=2>&gt; SIEMENS ATEA</FONT> <BR><FONT SIZE=2>&gt; ICN D CS
D5</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Tel. : +32 14 25 3424</FONT> <BR><FONT SIZE=2>Fax :
+32 14 25 3212</FONT> <BR><FONT SIZE=2><A
HREF="mailto:[email-masked]">mailto:[email-masked].
be</A></FONT> <BR><FONT SIZE=2>____________________________________</FONT>
</P>

---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY>
</HTML>

</x-html>
From: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Reinventing the Wheel
Date: Thu, 14 Jun 2001 11:55:13 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades6.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mailhost2.atea.be [194.78.143.126]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: Reinventing the Wheel</TITLE> </HEAD>
<BODY>

<P><FONT SIZE=2>Brian,</FONT>
</P>

<P><FONT SIZE=2>You snipped the part where I was trying to explain that ...
I'll repeat it for your convenience :</FONT> </P>

<P><FONT SIZE=2>It is the intention (whenever SUA issue 6 gets out, John ?)
to have the possibility of extensive addressing mechanisms in SUA as well.
As such SUA would allow pointcodes, GTs, IP addresses, hostnames, ... as
valid addresses and make use of an address mapping function (AMF) to resolve
these to the SCTP association ID towards the end-node or a relay-node (where
AMF is repeated).</FONT></P>

<P><FONT SIZE=2>This feature will offer scalability : for larger networks it
would be rather cumbersome to have a fully meshed overlay of SCTP
associations, and an overloaded management system to boot.</FONT></P>

<P><FONT SIZE=2>The AMF would offer the routing functionality like that of
an SS7 STP (I'm not talking about any management procedures), with any kind
of address.</FONT></P>

<P><FONT SIZE=2>Another thing in SUA is to extend the ASP management, which
is just informing the other end of an SCTP association. A proposal was made
to have an SUA relay node inform it's other (concerned) neighbours as well,
by extension of the DUNA, DAVA, SCON messages.</FONT></P> <BR>

<P><FONT SIZE=2>Summary :</FONT>
<BR><FONT SIZE=2>SUA supports both the classic SS7 SCCP users (TCAP or not),
inter-working, as well as new applications to be run in an all-IP
environment. The relay functionality is particularly of interest to the 3GPP
UMTS networks.</FONT></P>

<P><FONT SIZE=2>Best regards,</FONT>
</P>

<P><FONT SIZE=2>____________________________</FONT> </P>

<P><FONT SIZE=2>Gery Verwimp</FONT>
<BR><FONT SIZE=2>&gt; SIEMENS ATEA</FONT> <BR><FONT SIZE=2>&gt; ICN D CS
D5</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Tel. : +32 14 25 3424</FONT> <BR><FONT SIZE=2>Fax :
+32 14 25 3212</FONT> <BR><FONT SIZE=2><A
HREF="mailto:[email-masked]">mailto:[email-masked].
be</A></FONT> <BR><FONT SIZE=2>____________________________________</FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT> <BR><FONT SIZE=2>From:
Brian F. G. Bidulock [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>Sent: donderdag 14 juni 2001 10:11</FONT> <BR><FONT
SIZE=2>To: sigtran</FONT>
<BR><FONT SIZE=2>Subject: Re: Reinventing the Wheel</FONT> </P>
<BR>

<P><FONT SIZE=2>Verwimp,</FONT>
</P>

<P><FONT SIZE=2>Where is SUA more applicable?&nbsp; The scope of the draft
implies</FONT> <BR><FONT SIZE=2>that &quot;there may be some need&quot; or
SUA?&nbsp; What is the need if</FONT> <BR><FONT SIZE=2>these other
approaches exist?&nbsp; Does SUA provide something that</FONT> <BR><FONT
SIZE=2>the others cannot?&nbsp; Does it provide something better in
some</FONT> <BR><FONT SIZE=2>respect?</FONT>
</P>

<P><FONT SIZE=2>Verwimp Gery
wrote:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp; (Tue, 12 Jun 2001 11:09:32)</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Hello Brian,</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; There are a number of alternatives already to
transport SCCP-user</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; messages
over an IP-network :</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; - use SCCP over M3UA</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; - use TI-SCCP (Transport
Independent-SCCP) over STC (Signalling</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Transport Converter, as defined in Q.1901)
over SCTP</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; - use SUA</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; - use RFC 2126, with adaptation to
SCTP as the transport layer.</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; One solution or the other
will be easier to implement, depending on</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; what you have already in your boxes. And in my
opinion, either one</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; would
work fine, at least in small networks.</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT SIZE=2>[snip]</FONT>
</P>

<P><FONT SIZE=2>-- </FONT>
<BR><FONT SIZE=2>Brian F. G. Bidulock</FONT> <BR><FONT
SIZE=2>[email-masked]</FONT> <BR><FONT SIZE=2><A
HREF="http://www.openss7.org/"
TARGET="_blank">http://www.openss7.org/</A></FONT> </P>
<BR>

<P><FONT SIZE=2>---</FONT>
<BR><FONT SIZE=2>You are currently subscribed to sigtran as:
[email-masked]</FONT> <BR><FONT SIZE=2>To unsubscribe send a
blank email to [email-masked]</FONT> </P>

---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY>
</HTML>

</x-html>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sigtran-m2ua-08.txt
Date: Thu, 14 Jun 2001 07:08:56 -0400
Sender: [email-masked]
X-SMTP-HELO: ietf.org
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Signaling Transport Working Group of the
IETF.

	Title		: SS7 MTP2-User Adaptation Layer
	Author(s)	: K. Morneault, R. Dantu, G. Sidebottom, 
                          T. George, B. Bidulock, J. Heitz
	Filename	: draft-ietf-sigtran-m2ua-08.txt
	Pages		: 33
	Date		: 13-Jun-01
	
This Internet Draft defines a protocol for backhauling of SS7 MTP2 User
signaling messages over IP using the Stream Control Transmission Protocol
(SCTP).  This protocol would be used between a Signaling Gateway (SG) and
Media Gateway Controller (MGC).  It is assumed that the SG receives SS7
signaling over a standard SS7 interface using the SS7 Message Transfer Part
(MTP) to provide transport.  The Signaling Gateway would act as a Signaling
Link Terminal.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sigtran-m2ua-08.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in, type
"cd internet-drafts" and then
	"get draft-ietf-sigtran-m2ua-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sigtran-m2ua-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sigtran-m2ua-08.txt

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-sigtran-m2ua-08.txt> ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Thu, 14 Jun 2001 07:34:34 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: SS7 Links Inservice, and ASP goes INACTIVE/DOWN ....
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [161.44.85.169]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

I agree that SIPO was the favored response.  At the San Diego meeting, there
was concern that SIPO was not universal (it is not support in Japanese
variants).  Given that, the best response is described in your last
paragraph below.  Let the SG determine the best response based on following
the appropriate MTP specifications.

To answer your other question:  yes, you can set T(r) to zero.  

Regards,

Ken

At 02:26 AM 6/14/01 -0500, you wrote:
>Ken,
>
>Are you saying that the links will be immediately forced out of
>service or will T(r) still be applied?  Can I set T(r) to 0?
>To avoid message loss in this event, either SIPO should be sent
>on the link, or SIB, acknowledgements withheld, or SIOS sent to
>the MTP2 peer so that these messages are not lost forever.
>
>A delay T(r), if T(r) is some integer number of seconds, could
>result in a great number of messages being lost to the MTP2
>peer which could have been sent on alternative links.
>
>Of the choices, sending SIPO for the period is most appropriate
>if the SG expects another ASP in the AS to pick up the load.
>This was well supported on the list last November.
>
>The proscribed procedure (waiting T(r) and discarding) will
>increase the message loss and mis-sequencing (from changeover)
>and require higher reliability of the SCTP associations to
>the ASP and higher reliability of the ASP to meet the same
>traffic objectives.
>
>Because the choice of this procedure is solely a matter for the
>SG and it has no interoperability impacts on the ASP (the SG
>cannot even communicate with it at this time), I propose that
>M2UA leave it as implementation dependent and give leave to
>the SG implementor to decide which procedures will best meet
>SS7 reliability objectives.
>
>--Brian
>
>
>Ken Morneault wrote:                            (Wed, 13 Jun 2001 15:07:58)
> > 
> > 
> > Sandeep,
> > 
> > Yes, there is a discrepancy between these two statements.  Going
> > back to some old notes (the San Diego meeting), there was a general
> > consensus to take the links out-of-service if the AS transitioned to
> > a "Down" state whether due to a SCTP CDI or receipt of an ASP Down.
> > 
> > Of course, ideally an ASP would take the links out-of-service before
> > sending an ASP Down.
> > 
> > Regards,
> > 
> > Ken
> > 
> > 
> > At 10:29 AM 6/13/01 -0700, Balani, Sandeep wrote:
> > >Hi Ken, 
> > >    I was going thru the M2UA draft version 7  and i found the
following text
> > >inconsistent.  
> > >
> > >In section 1.5.4 it says " If the AS moves to the DOWN
> > >state while SS7 links are in-service, the SG SHOULD follow the MTP 2 
> > >processor outage procedures [2]. " 
> > >
> > >While in section 4.3.1.2 for describing T(r) timer expiry  in paragraph
4 it
> > >states: 
> > >  " If T(r) expires before an ASP becomes active, the SG stops queueing
> > >messages and discards all previously queued messages.  In addition,
> > >the SG SHALL send the Stop primitive to MTP2 to take the link out of 
> > >service.  The AS will move to AS-Inactive if at least one ASP is in 
> > >ASP-Inactive state, otherwise it will move to AS-DOWN state "
> > >
> > >In first description it says follow "LPO procedure" for AS state change
from
> > >ACTIVE to INACTIVE/DOWN, but in second description it states take the
"SS7
> > >links Out Of Service" in same AS state transition. 
> > >
> > >Ken, if u think that it is an descrepencies in M2UA version 7 draft
> > >description, is it possible to change in the next version of M2UA
draft. 
> > >
> > >Thanks
> > >Sandeep  
> > >
> > >
> > >
> > >
> > >
> > >---
> > >You are currently subscribed to sigtran as: [email-masked]
> > >To unsubscribe send a blank email to
[email-masked] 
> > 
> > 
> > 
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to
[email-masked]
>
>-- 
>Brian F. G. Bidulock
>[email-masked]
>http://www.openss7.org/
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA: Changes
Date: Thu, 14 Jun 2001 11:37:43 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.59">
<TITLE>RE: M3UA: Changes</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi Brian,</FONT>
</P>

<P><FONT SIZE=2>Lets see if we can close this off ....</FONT> </P>

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
SIZE=2>From: &nbsp; Brian F. G. Bidulock [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
<BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Monday, June 11, 2001 3:38 PM</FONT>
<BR><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT> <BR><FONT
SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: M3UA:
Changes</FONT> </P>

<P><FONT SIZE=2>Greg,</FONT>
</P>

<P><FONT SIZE=2>Please see additional comments below...</FONT> </P>

<P><FONT SIZE=2>On Mon, 11 Jun 2001, Sidebottom, Greg [BCNR:7M01:EXCH]
wrote:</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Hi Brian,</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; My apologies for the delay
in responding.&nbsp; The last week</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; or so was a write-off.&nbsp; Responses below
...</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; From:&nbsp;&nbsp; Brian F. G.
Bidulock [[1]<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; Sent:&nbsp;&nbsp; Thursday, May
31, 2001 8:04 PM</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: M3UA: Changes</FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; Greg,</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; Please see comments below...</FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; (Pardom me, but I won't be gentle.)</FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; On Thu, 31 May 2001, Sidebottom, Greg
[BCNR:7M01:EXCH] wrote:</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Hi Brian,</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Well, I guess I asked for it
- thanks for the very</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;
detailed rationale ...</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; -----Original
Message-----</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;
From:&nbsp;&nbsp; Brian F. G. Bidulock [[1][2]<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Sent:&nbsp;&nbsp;
Thursday, May 31, 2001 1:12 PM</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; To:&nbsp;&nbsp;&nbsp;&nbsp;
sigtran</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: M3UA: Changes</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&gt;</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Greg,</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; The first paragraph to strike on
Page 17 implies that the</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; NIF should hook into the MTP Level
3 TSFC function for a</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; destination which in the SEP case
is considered local and</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; has no place in the
function.&nbsp; This paragraph recommends</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; alterations to MTP Level 3 state
machines as described in</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Q.704 and other documents.&nbsp;
It is not the place of the M3UA</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; document to recommend changes to
MTP Level 3 standards</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; documents, even in passing, not to
mention that the</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;
operation of the TSFC is *not* considered &quot;implementation</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; dependent&quot;.&nbsp;
It has already been cited that &quot;current MTP3</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; procedures&quot; do not allow the
proscribed action in the SEP</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; case for some variants.&nbsp; It
is certainly not the place of</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; the M3UA document to proscribe an
actions which, with the</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; exception of ANSI, is prohibited
by the SS7 standards.</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; [Greg]&nbsp;&nbsp;&nbsp;
Very colorful!&nbsp; OK - I agree with your point that</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; this paragraph covers only an STP-like
case - it definitely</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;
needs a change to be more general, taking into account the</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; SEP-like case, and mentioning that
appropriate SG behavior</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; needs take into account the different
MTP3 variants and the</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;
architecture.&nbsp; That would improve it as a &quot;blanket</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; statement&quot;.&nbsp; Or I
think there may be some text covering this</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; in other sections, which may be
sufficient to allow removal -</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; I'll take a look.</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; I believe that the text is inappropriate
for the STP case as</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
well.&nbsp; This is because in the STP case, the NIF must interface</FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; with more than just the
&quot;top&quot; of the MTP Level 3.&nbsp; You are</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; reaching into routing functions and other
things.&nbsp; Attempting</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
to discuss the needs and functions of the MTP Level 3 to NIF</FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; interface is taking a step
towards specifying the NIF.&nbsp; The</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; NIF is intentionally scoped out of the
document, so why talk</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
about it?&nbsp; The NIF is the implementor's responsibility.&nbsp;
M3UA</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; should just address
whether the necessary set of syntactic</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; elements exist.</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; [Greg2]&nbsp; I'll agree that the paragraph
probably goes too far</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; into
describing an SG internal function, given the discussion.</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; We tried not to talk about the NIF entity when
it came to</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; management text as
it is obviously a very slippery slope, but</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; readers are &quot;implying&quot; it
anyway.&nbsp; Should we not say something</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; generic here though?&nbsp;&nbsp; I haven't
seen a rush to defend the text</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; but for some MTP3 variants it is possible for
an SS7 node</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; (SEP-like model)
to send an indication of congestion (TFC) into</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; the SS7 network.&nbsp; For the STP-like model
it is possible in all</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
variants.&nbsp;&nbsp; If no-one else cares though I will certainly
delete</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; the paragraph.</FONT>
</P>

<P><FONT SIZE=2>Greg, why do you keep saying TFC?&nbsp; TFC is an MTP3
peer-to-peer</FONT> <BR><FONT SIZE=2>message whose use and procedures are
defined in SS7 specifications.</FONT> <BR><FONT SIZE=2>It implies that an
NIF could be conceived of which does not contain</FONT> <BR><FONT SIZE=2>a
fully functioning MTP Level 3 at the SG, and that some simple</FONT>
<BR><FONT SIZE=2>little protocol conversion box could just sent TFC.</FONT>
</P>

<P><FONT SIZE=2>[Greg3] Brian, you are reading a lot of implementation into
this little paragraph - I have not tried to imply this, or your following
interpretation(s).&nbsp; The current text doesn't even talk about the
NIF.&nbsp; If the paragraph leads to these interpretations then I certainly
agree to delete it!</FONT></P> <BR>

<P><FONT SIZE=2>I believe that what you are trying to indicate is that the
NIF tells</FONT> <BR><FONT SIZE=2>MTP3 in some implementation depedent way
that it has detected an</FONT> <BR><FONT SIZE=2>MSU which was to be routed
on a congested link, or somehow spliced</FONT> <BR><FONT SIZE=2>into the
HMRT functions.&nbsp; Then MTP3 decides, per appropriate</FONT> <BR><FONT
SIZE=2>standards whether and when to launch a TFC.</FONT> </P>

<P><FONT SIZE=2>However, if the SPMC is considered local to the SG, there is
no</FONT> <BR><FONT SIZE=2>HMRT function to &quot;splice into&quot;.&nbsp;
It is only the HMDT function in</FONT> <BR><FONT SIZE=2>MTP3 which provides
access to MTP users.&nbsp; There is no way of</FONT> <BR><FONT
SIZE=2>&quot;splicing into&quot; the HMDT function with a congestion
indication</FONT> <BR><FONT SIZE=2>as MTP3 is defined.</FONT> </P>

<P><FONT SIZE=2>You muddy the picture by making reference to the detection
of an</FONT> <BR><FONT SIZE=2>event in M3UA and them mapping it onto an MTP3
message which is</FONT> <BR><FONT SIZE=2>seen on the other side of
MTP3.&nbsp; You cannot make statements like</FONT> <BR><FONT SIZE=2>this
without placing implicit restrictions on the procedures of</FONT> <BR><FONT
SIZE=2>MTP3.&nbsp; See the following diagram:</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT> </P>

<P><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp; +------------------+</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
NIF&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp; +-------+-+--------+</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp; | MTP3&nbsp; | |&nbsp; M3UA&nbsp; |</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp; +-------+ +--------+&lt;-- (A)</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp; | MTP2&nbsp; | |&nbsp; SCTP&nbsp; |</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp; +-------+ +--------+</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp; | MTP1&nbsp; | |&nbsp;&nbsp; IP&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(B)&nbsp;&nbsp;&nbsp;&nbsp; +-------+ +--------+</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
V&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ----------------+</FONT> </P>

<P><FONT SIZE=2>The language is mapping an event detected at (A)
congestion</FONT> <BR><FONT SIZE=2>in the diagram onto a message sent at
(B).&nbsp; This has the effect</FONT> <BR><FONT SIZE=2>of dictating the
behavior of the NIF and MTP3, and the text uses</FONT> <BR><FONT SIZE=2>the
word &quot;should&quot;.</FONT> </P>

<P><FONT SIZE=2>Furthermore, the text says &quot;parts of an
SPMC&quot;.&nbsp; Why would one ever</FONT> <BR><FONT SIZE=2>want to trigger
transfer-controlled procedures for parts of</FONT> <BR><FONT SIZE=2>an
SPMC?&nbsp; It doesn't make any sense to me.&nbsp; What is this
supposed</FONT> <BR><FONT SIZE=2>to mean in relation to MTP3 procedures at
the SG?</FONT> </P>

<P><FONT SIZE=2>[Greg3]&nbsp; The rationale was that in MTP3 a part of a
routeset (e.g., an active link) becoming congested causes the routeset to
congest.&nbsp; It was left open here that when a &quot;part&quot; of an SPMC
(e.g. a &quot;route&quot; to an active ASP in a loadshare) congests it may
be appropriate to give an indication to the SS7 network wrt the SPMC point
code.&nbsp; In any case, it is removed now.</FONT></P> <BR>

<P><FONT SIZE=2>The text also says &quot;should inform the MTP3 route
management</FONT> <BR><FONT SIZE=2>function (by an implementation dependent
mechanism)&quot;.</FONT> </P>

<P><FONT SIZE=2>Get rid of the &quot;should&quot; and identify the
&quot;implementation dependent</FONT> <BR><FONT SIZE=2>mechanism&quot; which
has already been defined in the reference</FONT> <BR><FONT
SIZE=2>architecture as the NIF.&nbsp; This really translates directly
to</FONT> <BR><FONT SIZE=2>`the NIF SHOULD inform MTP3 route management of
M3UA congestion'</FONT> <BR><FONT SIZE=2>which is why I object to the
text.&nbsp; M3UA SHOULD NOT be specifying</FONT> <BR><FONT SIZE=2>the
behavior of the NIF in this lapsidasical fashion (not giving</FONT>
<BR><FONT SIZE=2>consideration to all the other issues faced by the NIF
implementor).</FONT> </P>

<P><FONT SIZE=2>Quite frankly, the real case is that when the SG M3UA
encounters</FONT> <BR><FONT SIZE=2>congestion, the NIF can do what it likes
and the MTP3 will act</FONT> <BR><FONT SIZE=2>as it will, because it is
outside the scope of the document.</FONT> </P>

<P><FONT SIZE=2>Yes, please strike the paragraph.&nbsp; I have not heard
anyone</FONT> <BR><FONT SIZE=2>defend it either.</FONT> </P>

<P><FONT SIZE=2>[Greg3] Done.</FONT>
</P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; Further, in networks which do not support
multiple congestion</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
levels, TFC is the equivalent of a targetted TFP.&nbsp; The sender</FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; will not send signalling network
or traffic management</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
messages until the congestion clears.&nbsp; This does not properly</FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; reflect the case of the STP SG,
which is still able to process</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; signalling network and traffic management
messages on behalf</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; of the
SPMC.&nbsp; It is, you see, only the user parts which are</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; congested.</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; [Greg2]&nbsp;&nbsp; For this case I don't
believe that reception of a TFC</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; causes the sender to cut back on sending MTP3
management</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; messages, if that
is what you are saying.&nbsp; Per Q.704</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; international method the congestion indication
is simply handed</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; up to the
MTP3-User and no state is retained in the MTP3.&nbsp;&nbsp; We</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; probably agree anyway that the
semantics of any TFC sent from</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; an SG should conform to the MTP3 protocol
variant of the</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; network and
take into account its position architecturally</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; (e.g., SEP-like or STP-like).</FONT> </P>

<P><FONT SIZE=2>See above.&nbsp; By the very nature that the text says
&quot;TFC&quot;, you are</FONT> <BR><FONT SIZE=2>faced with qualifying the
statement based on MTP3 variants and</FONT> <BR><FONT SIZE=2>SS7 network
configuration.&nbsp; It is sufficient that M3UA may tell</FONT> <BR><FONT
SIZE=2>the NIF about the congestion that it has detected and it is
the</FONT> <BR><FONT SIZE=2>NIF's (and NIF implementor's) responsibility for
making whatever</FONT> <BR><FONT SIZE=2>communications needs be made to
MTP3.</FONT> </P>

<P><FONT SIZE=2>[Greg3] OK - lets avoid the rathole then.&nbsp; </FONT> </P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; I disagree that it has any
impact on the MTP3 standards.&nbsp; It</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; is nothing more than what current
distributed MTP3-processor</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; nodes do today.&nbsp; Data on
congested/unavailable</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;
destinations/User Parts or local resources usually needs to</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; be disseminated to all the MTP3
management instance(s).&nbsp; I</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; don't see this as a change to the MTP3
standards, which</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;
really assume a monolithic all-knowing MTP3 layer.&nbsp; A Gateway</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; is under an obligation to
ensure that all the network</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; management instances on both sides are
&quot;synchronized&quot; and</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; &quot;coordinated&quot; (maybe not the
best wording).&nbsp; Both network</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; management sides somehow need to take
into account events on</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; the other side or on other processors
on the same side.&nbsp; How</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; they propagate this is implementation
dependent.</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; It affects standards because in
the STP case it is clear what</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; the triggers are for sending TFC in the
standards documents.</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; M3UA
events are not among them.&nbsp; (Not to mention that, again,</FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; your are starting to specify the
NIF).</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; [Greg2]&nbsp; Agree with your parenthetical
remark.&nbsp; Of course the</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
MTP3 standards do not take into account M3UA events - this was</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; obviously not foreseen.&nbsp; But as
long as an SG vendor ensures</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
that when triggering a TFC based on an M3UA event that the TFC</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; is appropriate, no changes are
needed to the MTP3 standard.</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
The reception of a TFC from an SG should be treated exactly the</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; same way as from any other
node.</FONT> </P>

<P><FONT SIZE=2>By not qualifying the statement, the &quot;should&quot;
makes it appear as</FONT> <BR><FONT SIZE=2>though it is to be generally
applied.</FONT> </P>

<P><FONT SIZE=2>Gee, I don't care of the spec says that &quot;the M3UA at
the SG MUST</FONT> <BR><FONT SIZE=2>inform the NIF at the SG of any
congestion experienced towards an</FONT> <BR><FONT SIZE=2>ASP&quot;.&nbsp;
(It might even be a good idea to say this.) Just don't tell</FONT> <BR><FONT
SIZE=2>the NIF what to do in relation to MTP.</FONT> </P>

<P><FONT SIZE=2>[Greg3] OK</FONT>
</P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; The second paragraph to
strict on Page 17 implies that the</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; NIF should hook into the MTP Level
3 TSFC function for a</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; destination which in the SEP case
is considered local and</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; has no place in the
function.&nbsp; This paragraph also</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; recommends alterations to MTP
Level 3 state machines.</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; &quot;Current MTP3
procedures&quot; do not allow the proscribed action</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; in the SEP case.&nbsp; SEP's do
not send TFP for their point code</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; or alias point codes.</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; [Greg] I agree with your
last statement, but I think the text</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; is pretty clear that the TFP is sent
only for the case of the</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; SG acting &quot;as an
STP&quot;.&nbsp;&nbsp; I can't imagine why MTP3 management</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; at an SEP or STP would internally
maintain routes to itself</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; so I thought it obvious that an SG
wouldn't mark a route</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;
unavailable to an affected destination that includes itself.</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; This could be made clearer
though.</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; No. This is not applicable in the STP case
either.&nbsp; The SG is</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
responsible for the MTP management for the SPMC point code.</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; As a result, the SG is still capable of
processing all</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; signalling
network management messages which are adddressed to</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; the SPMC point code.&nbsp; Sending TFP
will shut these off.&nbsp; The</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; ASP is *not* responsible for SPMC
signalling network</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
management, it only provide an MTP-User part service.</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; Therefore, when all ASPs in the AS are
down, it is merely the</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
case that all user parts of the SPMC are unavailable.&nbsp; The MTP</FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; entity (signalling network and
traffic management) are still</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; alive and kicking.&nbsp; The view that
unavailable user parts</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
equates to and unavailable MTP is false logic.</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; [Greg2] This is not my view.&nbsp; How does
the sending of a TFP</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; shut
down signalling network management messages to the SG?&nbsp; As</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; you say the SG MTP3 is still
available.&nbsp; I have a feeling you</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; will say that the ASPs do not have an MTP3 but
I don't think</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; that is
relevant. The TFP is coming from the SG's Point Code to</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; an adjacent SS7 SP.&nbsp; The SP has no reason
to send MTP3</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; management
messages to any other Point Codes.</FONT> </P>

<P><FONT SIZE=2>Sending TFP will suppress all signalling network
management</FONT> <BR><FONT SIZE=2>messages addressed to the affected point
code, because it is</FONT> <BR><FONT SIZE=2>an SEP.&nbsp; The signalling
points receiving the TFP should not</FONT> <BR><FONT SIZE=2>send any
messages whatsoever to the affected point code, that</FONT> <BR><FONT
SIZE=2>includes SNMM messages.</FONT> </P>

<P><FONT SIZE=2>[Greg3] I'm not sure what you mean by &quot;because it is an
SEP&quot;.&nbsp;&nbsp; In the STP case that we are talking about, the
affected destination in the TFP is not &quot;adjacent&quot; to the node
receiving the TFP so there is generally speaking no SNMM traffic to be sent
to it.&nbsp; Yes there are some exceptions - TFP/A via an indirect route
when the direct route is unavailable, some possible of TFC/SRSCT/UPU
exceptions where I'm not sure why these would be sent to the affected
destination anyway.&nbsp;&nbsp; We could (very enjoyably!) sort this out
over a barley sandwich but these are corner cases and I'd rather defer to
your initial request to delete the paragraph.</FONT></P> <BR>

<P><FONT SIZE=2>Besides the fact that referring to &quot;TFP&quot; is the
same as in the</FONT> <BR><FONT SIZE=2>diagram above for &quot;TFC&quot; (it
spans both the NIF and MTP), it is</FONT> <BR><FONT SIZE=2>not appropriate
in the above regards.</FONT> </P>

<P><FONT SIZE=2>Again, if you say &quot;the M3UA at the SG MUST inform the
NIF at</FONT> <BR><FONT SIZE=2>the SG of any ASP unavailabilty towards an
AS&quot;, then I don't</FONT> <BR><FONT SIZE=2>have a problem; however,
there is already a layer management</FONT> <BR><FONT SIZE=2>for this
purpose.</FONT> </P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Furthermore, the
recommendations of the second paragraph are</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; in error for the case
described.&nbsp; When all of the ASPs in a</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; SPMC are down, there still exists
at the SEP SG the MTP</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Level 3 Signalling Network
Management functions.&nbsp; It is just</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; the MTP-Users which have gone away
when all of the ASPs are</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; down.&nbsp; There is no ASP for
the Signalling Network Management</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; function and as far as the SS7
network is concerned, the</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; signalling point code is still
available.&nbsp; That is, the SG</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; can still receive SNM messages
addressed to the SPMC's point</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; code and process them on its
behalf.&nbsp; Sending TFP in this</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; case is completely inappropriate,
an appropriate action on</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; the part of the SG would be to
send UPU's for all of the</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; unavailable user parts when they
receive messages.</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; [Greg]&nbsp; I think we are
mixing up the cases here - the second</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; paragraph, especially when talking
about TFPs, is covering</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; the STP-like case (i.e., where the SG
is not included in the</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; SPMC). The STP-like case is analogous
to an SS7 STP - when</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;
all of the routes to an affected destination are down, the</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; STP still has its MTP Level 3
management functions.</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;
Actually, sending of either a TFP or UPU does not imply that</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; the MTP3 management is down,
just than an ongoing &quot;route&quot; is</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; unavailable.&nbsp; If the ASPs
are/were handling multiple</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; MTP3-Users (e.g, ISUP and SCP) and all
of them are</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;
unavailable perhaps TFP is better (again assuming the MTP3</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; variant and architecture doesn't
preclude it).&nbsp; I agree with</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; you for the SEP case as I stated
above, but again I'm not</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; sure why the SG MTP3 would be
maintaining the state of a</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; route to itself in any case, so it
would not really be in a</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; position to send a TFP about
itself.</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; No.&nbsp; As described above, the
continued availability of</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
signalling network and traffic management functions at the SG</FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; for the concerned SP indicate
that the SP MTP has not been</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; isolated and TFP is not called for.&nbsp;
The ASPs (user parts)</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
have been isolated and should be reported as unavailable.</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; This is what you get when you place the
MTP on the SG and</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; merely
remote the MTP to MTP-User interface to the ASP,</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; regardless of whether you are talking
about the SEP case or</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; the
STP case (which I would like to discuss alot further</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; anyway ;).</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; [Greg2] See above.&nbsp; Assuming I am
understanding your point, a</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
TFP does not isolate the MTP3.</FONT> </P>

<P><FONT SIZE=2>It isolates affected PC in the TFP, because it is only sent
in</FONT> <BR><FONT SIZE=2>response to isolation.&nbsp; The affected PC will
receive no messages</FONT> <BR><FONT SIZE=2>on the route for which TFP was
signalled until TFA is sent.</FONT> </P>

<P><FONT SIZE=2>[Greg3]&nbsp; Which I argue is fine.&nbsp; We agree that
MSUs to the affected destination should stop.&nbsp; As for MTP3 Signalling
network management messages, in the non-adjacent cases where these might
occur, the SG will see these as messages for an isolated destination and
can't really do much with them (well a &quot;smart&quot; SG might but that
is another story).&nbsp;&nbsp; My point is only that this TFP in the case
mentioned is sometimes appropriate - it is appropriate to say with a TFP
that the affected destination is isolated when it is indeed isolated.&nbsp;
You may not agree but lets move on.&nbsp; The paragraph is gone.</FONT></P>

<P><FONT SIZE=2>&nbsp;</FONT>
</P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; The third paragraph is
just as incorrect because SEPs do not</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; send TFA's and TFA's are only sent
when the SNM at the SPMC</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; becomes available at the SG an not
when user parts become</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; available.</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; [Greg] Same point as
above.</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; Same as above.</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Furthermore, user part
documents are full of descriptions of</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; what actions should be taken with
respect to the SS7 network</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; should the user part become
isolated from the MTP.&nbsp; For</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; ISUP, see GR-317-CORE and
Q.764/767.</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; [Greg] How do these User
Parts determine that they are</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; isolated from the SS7 network?&nbsp;
There is no primitive defined</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; for this - MTP-PAUSE?.&nbsp; Of course
I am only being half</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;
serious - this is something I have really struggled with.</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Vendors have generally implemented
MTP3-to-MTP3_User</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;
interfaces that have something to manage this isolation</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; inside an SS7 SEP, or now in the
ASP.&nbsp; We could add a new</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; primitive but that would be changing
the MTP3 standard.</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; The user parts do not
determine that they are isolated from</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; the SS7 network, they determine that they
are isolated from</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
MTP.&nbsp; I.e, that they are unable to transfer prmitives across</FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; the L4 - L3 interface.&nbsp;
This is implementation dependent of</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; course, but in the M3UA *implementation*
isolation can easily</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; be
determined at the ASP by the state of communications with</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; the SG(s) and the state of other ASPs in
the AS.&nbsp; I don't mind</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; the default ASP approach as long as the
default ASP is</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; coincident
with the SGP.</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; [Greg2] Like you say it is
implementation dependent.&nbsp; The ASP</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; M3UA can now determine that it is isolated but
my point was</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; that the M3UA
still has the same limited primitives to the</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; resident MTP3-User.</FONT> </P>

<P><FONT SIZE=2>The mechanism for detection is implementation dependent, the
actions</FONT> <BR><FONT SIZE=2>to be taken are explicit and MTP-User
specific.</FONT> </P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; If you are talking about isolation from
the SS7 network, the</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
implementation dependent functions MTP-RESTART-BEGINS and</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; MTP-RESTART-ENDS are a good start.&nbsp;
These are not primitives</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
per se (although MTP-RESTART-ENDS is alluded to in the SS7</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; specs), but M3UA already has the DUNA and
DAVA with an mask of</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; 24
to cover both these cases.</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; [Greg2] Agree - this was the
intent.&nbsp; The ASP still has the</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; MTP3-to-MTP3-User interface and this is not
changed.</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; It is very important to understand that an
AS being separated</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; from
an SG, in either the SEP or STP case, is an MTP User Part</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; being separated from MTP and *not* MTP
being separated from</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; the
SS7 network.&nbsp; The point being that your Signalling Point</FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; Management Cluster concept must
also include the SG.</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; [Greg2] I understand you - I think
we only differ</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
philosophically in the internal model within the SG.&nbsp; In my</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; model not all SPMCs have to include
the SG.&nbsp; An SPMC not</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
including the SG does not imply that the ASPs making it up are</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; (virtually) running an MTP3.&nbsp;
I'm not sure if it is worth</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
debating these models as I think we end up with the same</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; result.</FONT> </P>

<P><FONT SIZE=2>I think that it is not worth specifying the internal model
in</FONT> <BR><FONT SIZE=2>the SG in the M3UA spec, because its
specification must include</FONT> <BR><FONT SIZE=2>a discussion on the
NIF.&nbsp; By implying an SG model in more than</FONT> <BR><FONT SIZE=2>just
example (by saying what the NIF &quot;should&quot; do) brings this</FONT>
<BR><FONT SIZE=2>matter up.</FONT>
</P>

<P><FONT SIZE=2>[Greg3]&nbsp; Fair enough.</FONT> </P>

<P><FONT SIZE=2>Why not just say &quot;when the M3UA detects ___(this)___
that it</FONT> <BR><FONT SIZE=2>SHOULD (or MUST) inform Layer
Management&quot;????&nbsp; Gee, isn't</FONT> <BR><FONT SIZE=2>that already
said somewhere for ASPs going up and down and</FONT> <BR><FONT
SIZE=2>congestion being experienced?</FONT> </P>

<P><FONT SIZE=2>Striking these paragraphs permits the NIF implementor access
to the</FONT> <BR><FONT SIZE=2>set of events necessary to achieve the
implementation of the NIF,</FONT> <BR><FONT SIZE=2>without the constraint of
the draft making such assumptions about</FONT> <BR><FONT SIZE=2>what the NIF
should or should not do with those events.</FONT> </P>

<P><FONT SIZE=2>[Greg3] Consider them now stricken.&nbsp; I really don't
think that all implementers consider these sections so constraining but
that's life!</FONT></P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; The last sentences in
the forth paragraph attempt to place a</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; requirement on the semantics of
the MTP to MTP-User</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; interface by requiring that
MTP-PAUSE and MTP-RESUME change</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; only when status changes.&nbsp; It
is not the place of the M3UA</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; document to place requirements on
an interface standardized</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; by other documents and where the
semantics are adequately</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; explained.</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; [Greg]&nbsp;&nbsp; OK - I
agree the word &quot;only&quot; is too restrictive -</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; there are also cases where PAUSE is
sent upon reception of a</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; messages from the upper layer.&nbsp;
This text was added because</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; some people originally thought that
TFPs or TFRs or TFAs from</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; the MTP3 network were received by the
MTP3 management and</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;
simply encapsulated and passed on to the ASPs.&nbsp; This would be</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; bad.&nbsp; These sentences
tried to make it explicit that these</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; messages were processed by MTP3
management.</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; My point: there is no place in
an M3UA document to outline the</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; responsibilities of MTP Level 3 as they
are adequately</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; explained
in the standards documents.&nbsp; Rather than attempting</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; to &quot;teach&quot; readers about MTP
Level 3, citing the appropriate</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; standards should be sufficient.</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; [Greg2] OK, the text was just trying to help
with</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; interoperability.&nbsp;
Do you still propose to delete or should the</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; clarification now point to an MTP3
reference?</FONT> </P>

<P><FONT SIZE=2>Strike them.&nbsp; The MTP3 documents are already referenced
with regard</FONT> <BR><FONT SIZE=2>to the primitive interface between MTP
and its Users.</FONT> </P>

<P><FONT SIZE=2>[Greg3] Done.</FONT>
</P>

<P><FONT SIZE=2>Thanks Brian,</FONT>
</P>
<BR>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Greg Sidebottom</FONT> </P>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Cheers,</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Greg Sidebottom</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; So, I suppose it is not
the specificity of the statements</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; which make me call to have them
struck, but that they are</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; erroneous, misrepresentative, and
inappropriate.</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;&gt;</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; --Brian</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; [Greg] Well I guess a little
hyperbole never hurt anyone.</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Please Brian, don't hold back - please
tell us all what you</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;
really think!&nbsp; 2;^)</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; With appropriate changes to
take into account Brian's</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; technical comments, and covering the
SEP case more</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;
explicitly, would the paragraphs be useful or would people</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; prefer them struck?</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Cheers,</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Greg</FONT> <BR><FONT SIZE=2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; Let me dig into this a little bit
further...&nbsp; Let's attempt to</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; rewrite one of the paragraphs so that they
make sense.&nbsp; Let's</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
take the TFP paragraph.&nbsp; Here is my rewriting:</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; When the SG determines that the transport and</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; processing SS7 signalling network management,</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; signalling traffic management and signalling test</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; management messages for a particular signalling point</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; are interrupted, if the SG is equipped with the</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; transfer function, the SG SHOULD mark the signalling</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; point as unavailable via the pseudo- M3UA route set</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; per local MTP procedures.&nbsp; If the SG offers route sets</FONT>
<BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; to the affected signalling point, and if the affected</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; signalling point is not itself a signalling point</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; which contains the transfer function, and if the SG</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; has no other route to the affected signalling point</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; (i.e, over C-links) and if the signalling point(s) to</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; which the SG offers signalling route(s) to the</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; affected signalling point are not themselves</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; unavailable then the SG MAY send a tranfer prohibited</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; message to the available signalling points to which it</FONT>
<BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; offers route(s) to the affected signalling point.&nbsp; If</FONT>
<BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; the SG has another route to the affected signalling</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; point via a signalling route with a lower priority</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; than the newly affected route set, the SG MAY send a</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; transfer prohibited message on this route set and MAY</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; (if the MTP is equipped with the optional</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; transfer-restricted option) send a transfer restricted</FONT>
<BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; message to the available adjacent signalling points to</FONT>
<BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; which the SG offers a route to the affected signalling</FONT>
<BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; point.</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; To be accurate I would literally
have to quote a significant</FONT> <BR><FONT
SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; portion of the Q.704 and other MTP
standards, including most</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
of the definitions.</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp;
</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; I suggest you leave it
alone.</FONT> <BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp;&nbsp; </FONT> </P>

<P><FONT SIZE=2>-- </FONT>
<BR><FONT SIZE=2>Brian F. G. Bidulock</FONT> <BR><FONT
SIZE=2>[email-masked]</FONT> <BR><FONT SIZE=2><A
HREF="http://www.openss7.org/"
TARGET="_blank">http://www.openss7.org/</A></FONT> </P>
<BR>

---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY>
</HTML>

</x-html>
From: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Thu, 14 Jun 2001 17:43:44 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades6.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mailhost2.atea.be [194.78.143.126]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: SUA5: Address Mapping text</TITLE> </HEAD>
<BODY>

<P><FONT SIZE=2>Hello John,</FONT>
</P>

<P><FONT SIZE=2>Good proposal. However, this address parameter should only
contain :</FONT> </P>

<P><FONT SIZE=2>- point code + SSN (optional) : existing case for
interworking with SS7, with already defined actions for the SG</FONT>
<BR><FONT SIZE=2>- IP address + SSN (optional) : all-IP environment.</FONT>
</P>

<P><FONT SIZE=2>if we want to avoid GT and/or hostname management in SUA.
The same applies to DAVA and SCON messages.</FONT> </P>

<P><FONT SIZE=2>The management procedures (for (un)availability and
congestion) in an all-IP environment could look something like this
:</FONT></P>

<P><FONT SIZE=2>&quot;If an SUA node receives an ASP_DOWN, ASP_INACTIVE or
SCTP_CDI indication it should inform it's concerned neighbours with a DUNA
message, including the primary IP-address of the SCTP association where
these indications are received from.</FONT></P>

<P><FONT SIZE=2>If an SUA node receives an ASP_ACTIVE indication it should
inform it's concerned neighbours with a DAVA message, including the primary
IP-address of the SCTP association on which the indication was
received.</FONT></P>

<P><FONT SIZE=2>If an SUA node receives a DUNA, DAVA or SCON message, and
the IP-address of the address parameter is equal to the primary IP-address
of the SCTP association it was received on, the SUA node should inform it's
concerned neighbours by sending on the received message unchanged towards
them. In case of a DUNA or DAVA message, the SSN should be included in the
address parameter as well.</FONT></P>

<P><FONT SIZE=2>In this way, neighbouring nodes have the opportunity to
select alternative routes or destinations, when communication via a certain
node (the one sending the DUNA, DAVA, SCON messages) is impossible or
congested.&quot;</FONT></P>

<P><FONT SIZE=2>Any comments ?</FONT>
</P>

<P><FONT SIZE=2>____________________________</FONT> </P>

<P><FONT SIZE=2>Gery Verwimp</FONT>
<BR><FONT SIZE=2>&gt; SIEMENS ATEA</FONT> <BR><FONT SIZE=2>&gt; ICN D CS
D5</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Tel. : +32 14 25 3424</FONT> <BR><FONT SIZE=2>Fax :
+32 14 25 3212</FONT> <BR><FONT SIZE=2><A
HREF="mailto:[email-masked]">mailto:[email-masked].
be</A></FONT> <BR><FONT SIZE=2>____________________________________</FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT> <BR><FONT SIZE=2>From:
[email-masked] [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</F
ONT> <BR><FONT SIZE=2>Sent: donderdag 14 juni 2001 10:35</FONT> <BR><FONT
SIZE=2>To: [email-masked]</FONT> <BR><FONT SIZE=2>Subject: RE:
SUA5: Address Mapping text</FONT> <BR><FONT SIZE=2>Importance: High</FONT>
</P>
<BR>

<P><FONT SIZE=2>Gery,</FONT>
</P>

<P><FONT SIZE=2>&gt; Yes, that's my proposition. We already extended DUNA,
DAVA, SCON for</FONT> <BR><FONT SIZE=2>&gt; subsystem manegement and this
could apply for the all-IP case </FONT> <BR><FONT SIZE=2>&gt; as well ! The
users expect the same service from SUA than from SCCP, so </FONT> <BR><FONT
SIZE=2>&gt; where would this subsystem management otherwise be realized
?</FONT> </P>

<P><FONT SIZE=2>Right now, the format for DUNA Message parameters is as
follows:</FONT> </P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp; 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</FONT> <BR><FONT SIZE=2>&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tag =
0x0001&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</FONT> <BR><FONT SIZE=2>&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Network
Appearance&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tag =
0x0005&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</FONT> <BR><FONT SIZE=2>&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;
/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Affected Point
Code&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;
\&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
\</FONT> <BR><FONT SIZE=2>&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tag =
0x010C&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</FONT> <BR><FONT SIZE=2>&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SMI/Subsystem&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp; |</FONT> <BR><FONT SIZE=2>&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tag =
0x0004&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</FONT> <BR><FONT SIZE=2>&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;
/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Info
String&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp; /</FONT> <BR><FONT SIZE=2>&nbsp;&nbsp;
\&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
\</FONT> <BR><FONT SIZE=2>&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</FONT>
</P>

<P><FONT SIZE=2>This won't be sufficient.&nbsp; Should we get rid of Affect
Point Code &amp;</FONT> <BR><FONT SIZE=2>SMI/Subsystem &amp; replace both
with destination address (destination</FONT> <BR><FONT SIZE=2>= affected
address)?&nbsp; Also, we should then talk about SG and/or </FONT> <BR><FONT
SIZE=2>RN (relay node), correct?</FONT> </P>

<P><FONT SIZE=2>John</FONT>
</P>

---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY>
</HTML>

</x-html>
Date: Thu, 14 Jun 2001 11:44:23 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SS7 Links Inservice, and ASP goes INACTIVE/DOWN ....
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

Can we tone down the "SHALL send the Stop primitive" to a "MAY" or refer to
the actions taken with regard to MTP2 as implementation dependent in this
situation?

--Brian

Ken Morneault wrote:                   (Thu, 14 Jun 2001 07:34:34)
> 
> 
> Brian,
> 
> I agree that SIPO was the favored response.  At the San Diego
> meeting, there was concern that SIPO was not universal (it
> is not support in Japanese variants).  Given that, the best
> response is described in your last paragraph below.  Let the
> SG determine the best response based on following the
> appropriate MTP specifications.
> 
> To answer your other question:  yes, you can set T(r) to
> zero.  
> 
> Regards,
> 
> Ken
> 

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 14 Jun 2001 12:33:11 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Reinventing the Wheel
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Gery,

Verwimp Gery wrote:                        (Thu, 14 Jun 2001 11:42:03)
> 
>    Brian,
>    
>    (BTW : my first name's Gery)

Sorry, Mutt did that automatically :O
>    
>    [GV] : Then we should rename the IETF Area & Working Group.

Why would you do that?  The IETF does not use OSI terminology.

[snip]
>    
>    [GV] : Well obviously one needs a route to deliver the goods to the
>    correct address. A network provides routing services, as user you
>    provide a valid address and some indication of the QoS you want. Just
>    as sending a letter. MTP provides such services (totally
>    connectionless).

Many IP networks do not require routers.

>    
>    [GV] : From E.164 to IP-address ? How to select the next NSD wisely,
>    and how to engineer this in your network, is far from trivial.

Map E.164 by TT to PC SSN (as today).  Map PC SSN to SCTP endpoint (ASP).
It is a very simple table.

>    
>    >
>    >>
>    >>    Yes, but without congestion control. What you are suggesting
>    here is
>    >>    to do the connectionless stuff over UDP WITHOUT congestion
>    >>    control.(..............................................)
>    >
>    > TCAP provides congestion control.  SCCP provides congestion control
>    > on Class 3.
>    
>    [GV] : ??? Seems I missed something in Q.771-775 or T1.114. But if you
>    want to run TCAP directly over UDP/IP ...

Code gapping is an example.  There is more to protect from congestion than
just the intervening network.

>    SCCP provides flow control on Class 3. For a distinction between flow
>    control and congestion control, please read the SCTP applicability
>    statement.

I think you are comparing ITU "flow control" to IETF "flow control".  They
are not the same thing.

>    
>    >
>    >>
>    >>    Congestion occurs in the SS7 network, sometimes a lot more than
>    we
>    >>    would like. SS7 is not some small network(is not longer a little
>    girl)
>    >>    where the linkload never gets over 25%. It is a collection of
>    SS7
>    >>    networks(sometimes very big networks, certainly when looking at
>    the
>    >>    number of people using them) which at this moment has to service
>    300
>    >>    million people(give or take 100 million). We have a SMS craze
>    over
>    >>    here and would you believe it but those SMS run also over SS7.
>    (SMS
>    >>    stands for Short Message Service)
>    >>
>    >>    It tooks years in standaadisation to get some solutions for that
>    in
>    >>    MTP lvl 3 and SCCP congestion control and those battles were
>    truly
>    >>    breathtaking at times.
>    >
>    > It would be great if SUA addressed congestion controls, but it
>    doesn't.
>    >
>    
>    [GV] : We're discussing this right now on the sigtran mailing list,
>    and we hope to get some feedback !

My application is LNP.  It's fairly big here in North America.  It uses big
hunkin SCPs which handling an ever-increasing and significant percentage of
all the local telephone calls.  It will not run over today's Internet and
doesn't need SCTP's or the IETF's myopic view of Internet- Friendly
congestion control.

I'll provide some feedback on that topic, however, I would like to see the
relay problems (Class 0 and Class 2) and decoupling at the relay point
addressed in the spec first.  As SUA-05 stands, it cannot handle classes 0
and 2 where the SG does not provide Final GTT.  (Which is rather
restrictive, because Final GTT is almost never performed at the terminating
node.)

>    
>    >
>    > If your SMS service does not provide congestion controls at the
>    > application level, you can keep it off of my SS7 network.  I would
>    > not permit your SMS to run with my ISUP with only MTP Level 3
>    > congestion to stop it (and my ISUP at the same time).
>    >
>    
>    [GV] : SMS's are routed on Global Title. There's no congestion
>    indication attached to that right now, although there have been
>    discussions about GT management. Anyway, SCCP maps this on a DPC (next
>    relay or end node) and will not transfer the message to MTP if the
>    congestion level of this DPC is "higher" than the message priority
>    (given by the application).
>    
>    So there's not only MTP-3 to stop it.

Does SMS do successive global title withing the same administrative domain?
Are your operators ok with that?

Also, if you are only using MTP destination congestion, there is only MTP-3
to stop it.  What I mean by that is that an SMS overload will consume all
MTP3 capacity to the destinations to be usurped from other MTP3 users.  That
is why I would not like your SMS application running along side my revenue
generating ISUP calls.

[snip]

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: Re: m2ua last call
X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001
Date: Thu, 14 Jun 2001 14:51:12 -0400
X-MIMETrack: Serialize by Router on HQ_ACS_1/Radisys_Corporation/US(Release 
             5.0.6a |January 17, 2001) at 06/14/2001 11:52:54 AM, Serialize 
             complete at 06/14/2001 11:52:54 AM
X-SMTP-HELO: radisys.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mail-gw.radisys.com [206.102.10.35]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Lyndon,

I think that Last Call is premature prior to at least 1 "bay-cough".

Barry Nagelberg
Software Engineer
RadiSys, Corp.
Signaling Products Design Center
[email-masked]
+1-856-642-9229 x237

Lyndon Ong <[email-masked]>
06/14/01 02:41 PM
Please respond to sigtran

        To:     "sigtran" <[email-masked]>
        cc: 
        Subject:        m2ua last call

Folks,

Now that the new version of M2UA is available, I'd like to ask if there is
any objection to moving this to Working Group Last Call.

If not, I will officially start Last Call on Monday, lasting until Friday
the 29th.

Cheers,

L. Ong

Join 18 million Eudora users by signing up for a free Eudora Web-Mail
account at http://www.eudoramail.com

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to 
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 14 Jun 2001 13:55:23 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: m2ua last call
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Lyndon,

Is it normal practice to move a draft to last call which has issues
outstanding at the time that it was issued?  There are still the outstanding
issues of:

        o   Handling of SGP Id's and SGP management.
        o   Correlation Id and Acking for buffer management.
        o   Vetting and review of changes made to the 07 draft.

Shouldn't we have a chance to comment on the 08 draft before moving to last
call?

--Brian

Lyndon Ong wrote:                     (Thu, 14 Jun 2001 11:41:31)
>
> Folks,
> 
> Now that the new version of M2UA is available, I'd like to ask
> if there is any objection to moving this to Working Group Last
> Call.
> 
> If not, I will officially start Last Call on Monday, lasting
> until Friday the 29th.
> 
> Cheers,
> 
> L. Ong
> 
-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Thu, 14 Jun 2001 15:33:00 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: m2ua last call
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

I asked Lyndon to poll for last call because it stimulates discussion on the
open issues.  Thus, we should be able to bring them to closure more quickly
(I hope).  Otherwise, (besides your input) there is not much email traffic
on M2UA issues.

So, everyone please take a look at the draft and summary email.

Regards,

Ken

At 12:15 PM 6/14/01 -0700, you wrote:
>Brian,
>
>It basically depends on the nature of the issues.  If some have not been
addressed by v07, and still need resolution, then you can certainly request
that we have these addressed in a v08 before going to Last Call.
>
>If the issue is the v07 text itself, I think that's the type of thing that
Last Call is for, you can use the Last Call period to review the text and
propose changes where you think the text needs correction.
>
>Do you think that we still need some work on addressing some open issues?
That's why I was asking the group rather than just saying "Last Call!" :o)
>
>Cheers,
>
>Lyndon
>
>--
>
>On Thu, 14 Jun 2001 13:55:23   Brian F. G. Bidulock wrote:
> >Lyndon,
> >
> >Is it normal practice to move a draft to last call which has
> >issues outstanding at the time that it was issued?  There are
> >still the outstanding issues of:
> >
> >        o   Handling of SGP Id's and SGP management.
> >        o   Correlation Id and Acking for buffer management.
> >        o   Vetting and review of changes made to the 07 draft.
> >
> >Shouldn't we have a chance to comment on the 08 draft before
> >moving to last call?
> >
> >--Brian
> >
> >Lyndon Ong wrote:                     (Thu, 14 Jun 2001 11:41:31)
> >>
> >> Folks,
> >> 
> >> Now that the new version of M2UA is available, I'd like to ask
> >> if there is any objection to moving this to Working Group Last
> >> Call.
> >> 
> >> If not, I will officially start Last Call on Monday, lasting
> >> until Friday the 29th.
> >> 
> >> Cheers,
> >> 
> >> L. Ong
> >> 
> >-- 
> >Brian F. G. Bidulock
> >[email-masked]
> >http://www.openss7.org/
> >
> >
> >---
> >You are currently subscribed to sigtran as: [email-masked]
> >To unsubscribe send a blank email to
[email-masked]
> >
>
>
>Join 18 million Eudora users by signing up for a free Eudora Web-Mail
account at http://www.eudoramail.com
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 14 Jun 2001 14:24:45 -0700 (PDT)
From: Zhifeng Tao <[email-masked]>
Subject: SS7 congestion control
To: "sigtran" <[email-masked]>
X-SMTP-HELO: web12402.mail.yahoo.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: web12402.mail.yahoo.com [216.136.173.129]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi, all

I¡¯ve got a question about SS7 congestion control mechanism.

¡°The senario is:¡±
1) The network configuration is the regular STP quad. 

2) STP_A/STP_B are on the right hand side and STP_C/STP_D on the left hand
side.  
3) And all STPs have connection with emulated SSPs by using A links.  
4) STP_A/STP_B connect to emulated SSP1, SSP2, etc.
5) STP_C/STP_D connect to emulated SSP31, SSP32, etc.
6) SSP1, SSP2, etc initiate UDM (user defined message) traffic all toward
SSP31.  those traffic requires GTT at STP_A/STP_B.
7) STP_C/STP_D detect congestion on the link toward SSP31 and send TFC back
to STP_A/STP_B.  And then STP_A/STP_B send UDTS messages to SSP1,SSP2,etc. 
Since SSP1, SSP2, etc are emulated, they will not stop sending out traffic.
Therefore, STP_A/STP_B begin to discard traffic.  

¡°Question:¡±
According to GR246, only after the discard level within STP is exceeded,
will STP start to drop traffic.  Meanwhile, STP_A/STP_B only change its
congestion level according to the congestion status contained in the
incoming TFC from STP_C/STP_D.  
Then, how can STP_A/STP_B change the discard level regarding the traffic for
remote SSP31 and begin to drop traffic?

Thanks!

Jeff

__________________________________________________ Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 14 Jun 2001 17:56:58 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SS7 congestion control
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      RAA29338
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Jeff,

The procedure from GR246 is an MTP procedure which is applicable at
STP_C/STP_D in your example.  STP_A/STP_B is performing the SCCP procedure
to return a UDTS in response to UDT which translate to a congested
destination.

--Brian

Zhifeng Tao wrote:            (Thu, 14 Jun 2001 14:24:45)
> Hi, all
> 
> I¡¯ve got a question about SS7 congestion control
> mechanism.
> 
> ¡°The senario is:¡±
> 1) The network configuration is the regular STP quad. 
> 
> 2) STP_A/STP_B are on the right hand side and
> STP_C/STP_D on the left hand side.  
> 3) And all STPs have connection with emulated SSPs by
> using A links.  
> 4) STP_A/STP_B connect to emulated SSP1, SSP2, etc.
> 5) STP_C/STP_D connect to emulated SSP31, SSP32, etc.
> 6) SSP1, SSP2, etc initiate UDM (user defined message)
> traffic all toward SSP31.  those traffic requires GTT
> at STP_A/STP_B.
> 7) STP_C/STP_D detect congestion on the link toward
> SSP31 and send TFC back to STP_A/STP_B.  And then
> STP_A/STP_B send UDTS messages to SSP1,SSP2,etc. 
> Since SSP1, SSP2, etc are emulated, they will not stop
> sending out traffic.  Therefore, STP_A/STP_B begin to
> discard traffic.  
> 
> 
> ¡°Question:¡±
> According to GR246, only after the discard level
> within STP is exceeded, will STP start to drop
> traffic.  Meanwhile, STP_A/STP_B only change its
> congestion level according to the congestion status
> contained in the incoming TFC from STP_C/STP_D.  
> Then, how can STP_A/STP_B change the discard level
> regarding the traffic for remote SSP31 and begin to
> drop traffic?
> 
> Thanks!
> 
> Jeff
> 

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 14 Jun 2001 20:04:33 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2UA 08: Flush Buffers
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

Although ITU only defines a Flush Buffers primitive, ANSI also defines a
Clear RTB primitive which is independent from the Clear Buffers primitive.
This is used
to clear the RTB yet still permit retrieval of the TB for emergency
changeover.

Flush Buffers in ITU only clears the TB and RTB.  Clear Buffers in ANSI
clears the TB, RTB and RB.  Clear RTB in ANSI only clears the RTB.

Therefore, in Section 3.3.1.4 and 3.3.1.5 you need the additional state
value of

STATUS_CLEAR_RTB    "Clear Retransmit Buffer"

and the description for STATUS_FLUSH_BUFFERS which was changed in 08 to
include the receive buffer is only applicable to ANSI (and others?) but not
ITU.  Perhaps it would be more accurate to describe it as "Clear Buffers" or
"Flush Buffers" and not make reference to which buffers need flushing for
this state value.

--Brian

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 14 Jun 2001 20:08:32 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2UA 08: Reference 12
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

Reference [12] should be referred to as a "Work In Progress" and not
identified by it's draft name.

--Brian

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 14 Jun 2001 21:03:05 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2UA 08: Congestion Indication
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: piglet.pigworks.dallas.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-224.dallas.net [209.44.42.224]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Section 3.3.1.7 has a congestion status and discard value in the list named
LEVEL_4.  The text refers to a LEVEL_DISCARDING which is not in the list.
The text indicates that a variant not supporting multiple congestion levels
(or states) "will" use LEVEL_NONE and LEVEL_3.  The text requires that the
SG "shall" send LEVEL_DISCARDING when it runs out of buffers and begins
discarding MSUs, even though it seems that the SG will have already sent
"LEVEL_3" congestion status and "LEVEL_3" discard status which indicates the
same thing.  It is not clear to me what the ASP M2UA is supposed to do with
the LEVEL_DISCARDING indication.  What is it supposed to do?  (Its response
to the other levels are clear from the MTP specs, but what about
LEVEL_DISCARDING?  And what is LEVEL_4?  How are they different from
congestion status LEVEL_3 and discard status LEVEL_3?

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 14 Jun 2001 21:21:23 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2UA 08: Retrieval Request
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: piglet.pigworks.dallas.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-224.dallas.net [209.44.42.224]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Section 3.3.1.8

The changes which were made to retrieval request are not consistent with the
common descriptions of M2UA from Q.703 and Q.2140/Q.2110.  These specs do
not provide a mechanism for retrieving as described in ACTION_RTRV_MSGS and
ACTION_RTRV_TRANS.  Both Q.703 and Q.2140/2110 described signalling links
only support the retrieval of BOTH the messages in the retransmit and
transmit buffers.

If CLEAR_RTB is added to the states (as per previous mail) consistent with
the flush_buffers primitive, these three can be reduced to a set which is
consistent with the cited and referenced recommendations.

Remove ACTION_DROP_MSGS and ACTION_RTRV_TRANS, describe ACTION_RTRV_MSGS as
retrieving both RTB and TB contents, and add STATUS_CLEAR_RTB to the status
messages.  This will make M2UA consistent with Q.703/Q.2140/Q.2110 as well
as T1.111.3.

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 14 Jun 2001 21:25:42 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2UA 08: Retrieval Request
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: piglet.pigworks.dallas.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-224.dallas.net [209.44.42.224]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Section 3.3.1.9

I have no idea what Sequence Number is for (Optional or not).  Q.2140 does
not return sequence numbers in retrieved messages.
What was the ASP at M2UA going to do with it if it is included?  (I can see
using the Correlation Id here, but what use is the sequence number which was
assigned by the MTP2 at the SG?  Aside from the FSNC, the MTP3 and ASP know
nothing about MTP2 sequence numbers.)

If it doesn't have a use, the Sequence Number should be struck.

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 14 Jun 2001 21:32:07 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA 08: Retrieval Request
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-224.dallas.net [209.44.42.224]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Oooops.  Skip that: I keep forgetting that it is only used for BSNT
retrieval.

Brian F. G. Bidulock wrote:     (Thu, 14 Jun 2001 21:25:42)
> Section 3.3.1.9
> 
> I have no idea what Sequence Number is for
> (Optional or not).  Q.2140 does not return
> sequence numbers in retrieved messages.
> What was the ASP at M2UA going to do with
> it if it is included?  (I can see using the
> Correlation Id here, but what use is the
> sequence number which was assigned by the
> MTP2 at the SG?  Aside from the FSNC, the
> MTP3 and ASP know nothing about MTP2 sequence
> numbers.)
> 
> If it doesn't have a use, the Sequence Number
> should be struck.
> 

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 14 Jun 2001 21:37:49 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2UA 08: Retrieval Confirm
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by 
                      piglet.pigworks.dallas.net id f5F2bnV25039
X-SMTP-HELO: piglet.pigworks.dallas.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-224.dallas.net [209.44.42.224]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Section 3.3.1.9

Per Q.703 and Q.2140/2110 there is no way to distinguish between messages
retrieved from the TB and messages retrieved from the RTB.  The distinction
should not be made in M2UA because SGs exist which will lack support for the
distinction.

There is no reason to distinguish between TTC retrieved messages here.
Whether the retrieved message is TTC or not is implicit in the interface
identifier from which the messages are being retrieved.  The distinction is
only necessary over channels which may mix both TTC and non-TTC messages.

(Actually, I don't see what you need a TTC type for in the first place.)

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 14 Jun 2001 21:51:51 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2UA 08: Notify
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: piglet.pigworks.dallas.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-224.dallas.net [209.44.42.224]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Section 3.3.3.2

Add the status information value

	"Insufficient ASP resources pending in AS"

per previous proposal to indicate to the AS that the number of active ASPs
in an n+k arrangement has fallen to n from n+1.  Providing notification when
falling from n to n-1 is a little late for the Broadcast case, particularly
should ASPs become partitioned.

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 14 Jun 2001 03:05:02 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Reinventing the Wheel
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Coene,

Coene Lode wrote:                                           (Wed, 13 Jun
2001 11:47:41)
>
>    Maybe you like describing the original X25 centric way that it was
>    first conceived and described(and subsequentely never removed in the
>    specs) But what you describe is the situation from 15 years back(where
>    x25,it seems, was still king). It evolved and practically junked all
>    the X25 stuff. And sure also ISO stuff was rather popular in those
>    days. A couple a references to ISO wouldn't hurt(even normative) but
>    the specs of TCAP and SCCP are selfcontained, meaning you can
>    implement them without even giving the slightest look to any of those
>    ISO or X25 specs. I did it that way and nobody ever complained.

   "It is noted that the time sequence of primitives in the reset
    procedure may be varied as long as it is consistent with
    Recommendation X.213."

You were obviously not worried about interoperation in this an other
respects with implemenators who had read X.213.

>    
>    By the way how you implement your primitives and their parameters is a
>    implementation dependant issue. The real gut lies in the messages
>    syntax and its semantics and those are a very far cry from OSI. You
>    get that wrong and everybody knows.

The NSD does not define the protocol, it defines the interface.  How you
implement the interface is up to you, but the purpose of the OSI model was
to allow different protocols to be placed under the various layers.  By
following the NSD, this is what IS-41 accomplished with X.25 carrying TCAP
along with SCCP.

>    
>    You have a point for TCAP(yes )..: It has nearly the same syntax(and
>    semantics) for its messages as the ROSE and the ACSE. But that doesn't
>    make it a ISO protocol just we borrowed a few good ideas from them.
>    
>    >
>    > On Mon, 11 Jun 2001, Coene Lode wrote:
>    > >
>    > >    Neither SCCP nor TCAP are ISO network or transport services.
>    > >    Especially SCCP is NOT a ISO network service. I have
>    > never run into a
>    > >    ISO spec specifying anything close to the things SCCP
>    > do. (Oh yes ,
>    > >    apart from doing the Connection oriented service but
>    > that is only one
>    > >    of the SCCP services, big deal)
>    > >
>    >
>    > ANSI T1.112.1 Section 1.1:
>    >
>    >         "The Network Service Part meets the requirements for Layer
>    >          3 services as defined in the CCITT Recommendation X.200,
>    >          Reference Model of Open Systems Interconnect for CCITT
>    >          Applications."
>    >
>    > Q.711 Section 5.1:
>    >
>    >         "The service interfaces to the upper layers and to MTP are
>    >          described by means of primitives and parameters, as
>    > recommended
>    >          in Recommendation X.200."
>    >
>    > Perhaps you didn't know that X.200 was ISO/IEC 7498.
>    >
>    > ANSI T1.112.1 Sction 2.1.1.2.1:
>    >
>    >         "(Refer to CCITT Recommendation X.213, Network Layer Service
>    >          Definition of Openn Systems Interconnect for CCITT
>    > Application.)"
>    >
>    >
>    > An in Q.711, we find X.213 (ISO/IEC 8348) as a "Normative"
>    > reference...
>    >
>    > Perhaps you didn't know that X.213 was ISO/IEC 8348.
>    >
>    > I'm, sorry, but SCCP *is* an OSI/ISO network service provider.
>    
>    Those are references to the primitive interface. And they are only
>    used in the introduction. They then go on specifying their own
>    protocol which can be understood without ever having to read the ISO
>    documents.

But still permits portability of SCTP-Users to other NSPs satisfying the
NSD.

>    
>    Perhaps the SCCP you know run on a ISO network but the girl I know
>    runs on a SS7 network The SCCP i know does not support ISO adresses.
>    Thus if the native ISO addressing is not supported , how the hell can
>    be it be anything ISO. That is just the same as claiming SCCP is a
>    internet protocol while it can not even support internet addressing.
>    Now in due course TI-SCCP and SUA will and they may rightly claim that
>    title and some other people will fight over that.
>    
>    In the 10 years that I have done SS7, ISO has palyed a very small role
>    in SS7. And if it did, then it was in TCAP concering some aligments
>    with updated specs of ASN1. But real important groundbreaking stuff,
>    no.

About 5 years before you started "doing SS7," it was wished that OSI had
been completed before MTP, so that MTP could have followed the ISO model as
well.  OSI was the groundbreaking stuff which permitted SCCP and TCAP.
>    
>    Which sets you apart from the rest because that is simply not the
>    case. Transport layers are supposed to do much more than TCAP does.
>    Gey explains it even better than me, so read his mail.

A null transport is a transport.  Where the network service provider can
provide all the services required of the transport user, a simple mapping of
the TSD to the NSD is possible.  Gey didn't explain it so good, see my
response.

>    
>    It seems all those years I have been wrong. It was just a apperance of
>    connectionless service. That is a very weird concept, because that
>    would imply that MTP lvl 3 would also give the "apperance" of a
>    connectionless service. Maybe try to explain the difference between
>    real connectionless and "fake"(for sake of a better name)
>    connectionless.

MTP is composed of a number of virtual connections which are a full mesh of
connections identified by the vector [PC,PC,SLS].  These connections are
permanent connections which are established when the network is configured
and provide strong assurances on bandwidth and reliability of the virtual
channel.  When you send your "connectionless" message a connection is
selected [PC,PC,SLS] and the message is sent on that connection.  A true
connectionless network would not have to choose an assured virtual
connection upon which to send a message.
>    
>    That doesn't answer the question, and by the way you break the
>    end-to-end principle(no not the internet one, but the SS7 one) if no
>    support for SCCP addressing is provided in this adaptation of yours.
>    
RFC 1006 uses IP addresses to support the NSD.  Performing connections at an
SCCP relay point from NSD to NSD is already defined.  Address mapping is
trivial.

>    
>    Yes, but without congestion control. What you are suggesting here is
>    to do the connectionless stuff over UDP WITHOUT congestion
>    control.(..............................................)

TCAP provides congestion control.  SCCP provides congestion control on Class
3.

>    
>    Congestion occurs in the SS7 network, sometimes a lot more than we
>    would like. SS7 is not some small network(is not longer a little girl)
>    where the linkload never gets over 25%. It is a collection of SS7
>    networks(sometimes very big networks, certainly when looking at the
>    number of people using them) which at this moment has to service 300
>    million people(give or take 100 million). We have a SMS craze over
>    here and would you believe it but those SMS run also over SS7. (SMS
>    stands for Short Message Service)
>    
>    It tooks years in standaadisation to get some solutions for that in
>    MTP lvl 3 and SCCP congestion control and those battles were truly
>    breathtaking at times.

It would be great if SUA addressed congestion controls, but it doesn't.

>    
>    But they are in place in a classic SS7 network. And now should we
>    restart from scratch without congestion control.
>    I gladly leave it to you trying to explain that to both the IETF and
>    the ITU/ETSI/ANSI.

TCAP provides congestion control.  SCCP provides congestion control on Class
3.

If your SMS service does not provide congestion controls at the application
level, you can keep it off of my SS7 network.  I would not permit your SMS
to run with my ISUP with only MTP Level 3 congestion to stop it (and my ISUP
at the same time).

I think that you are confusing forms of congestion.

>    
>    Well good for you, but I am not interested in that. It was and has
>    never been used in GSM that way. (Yes, I have sold my soul to GSM(and
>    UMTS), allright , now we all know it)
>    
It still demonstrates the principle and provides a proof of concept.

As you have not even mentioned SUA, I presume that you know of no reason why
one might want to use it in contrast to the other possible approaches.

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 14 Jun 2001 22:00:19 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2UA 08: ASPM procedures
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: piglet.pigworks.dallas.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.224]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Section 4.3.2

	"... Athe [sic] ASP, M2UA shall either cause
	other ASPs to become active or send link-out-
	of-service primitives to MTP3."

Just how was M2UA at the ASP going to cause other ASPs to become active?
Also, what indications are sent to MTP3 is certainly up to the ASP
implementor and does not impact interoperability with any SG implementation,
per previous discussion pertaining to SG actions towards MTP2.

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 14 Jun 2001 20:06:58 -0700
From: Jacob Heitz <[email-masked]>
Organization: Lucent Technologies, Internetworking Systems, Software 
              Engineering, Alameda
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M2UA 08: Congestion Indication
X-SMTP-HELO: drawbridge.ascend.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: drawbridge.ascend.com [198.4.92.1]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

I think LEVEL_DISCARDING should be the same as LEVEL_4.
At LEVEL_3, it is not discarding, just indicating the highest level of
congestion consistent with the MTP specs.
The MTP specs have no value for indicating that MTP2 is discarding MSUs from
MTP3, because when MTP3 and MTP2 are colocated, it shouldn't happen. If M2UA
runs out of memory to store received MSUs received from the ASP, an option
might be to simply stop reading them from the SCTP stream. Then SCTP would
eventually close the window and the ASP would stop sending. This has two
disadvantages. One, it will stop all other streams in the same association
from flowing and two, it will prevent the SG from receiving possibly
important M2UA control messages, such as STATUS_FLUSH_BUFFERS. An
alternative is to send LEVEL_4. Response of ASP is implementation dependent.
It could be processor outage or whatever you choose. 

Another way to solve the same problem might be with your correlation ID:
don't ack it. We don't have your text for this yet though. Let's see it: you
never know, we might finally be able to agree on something.

"Brian F. G. Bidulock" wrote:
> 
> Section 3.3.1.7 has a congestion status and discard value
> in the list named LEVEL_4.  The text refers to a LEVEL_DISCARDING
> which is not in the list.  The text indicates that a variant
> not supporting multiple congestion levels (or states) "will"
> use LEVEL_NONE and LEVEL_3.  The text requires that the SG "shall"
> send LEVEL_DISCARDING when it runs out of buffers and begins
> discarding MSUs, even though it seems that the SG will have
> already sent "LEVEL_3" congestion status and "LEVEL_3" discard
> status which indicates the same thing.  It is not clear to me
> what the ASP M2UA is supposed to do with the LEVEL_DISCARDING
> indication.  What is it supposed to do?  (Its response to
> the other levels are clear from the MTP specs, but what about
> LEVEL_DISCARDING?  And what is LEVEL_4?  How are they different
> from congestion status LEVEL_3 and discard status LEVEL_3?

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 14 Jun 2001 22:59:57 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA 08: Congestion Indication
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-224.dallas.net [209.44.42.224]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Jacob,

The only problem I have with that is that there exists MTP2 implementations
and SG implementations which cannot generate the indication, so the "shall"
is not called for in the text.

If the ASP M2UA is to convert this into some indication that MTP3
understands, it is also possible for the SG M2UA to do so as well and there
is no need to transfer this indication across the M2UA.

It is possible (and advisable) to design an MTP2 implementation so that it
never encounters this situation.

Level 1 2 and 3 congestion is not signalled by MTP2 because it is running
out of buffers.  They are signalled because the link is becoming congested.
Once level 3 discard has been indicated by MTP2, MTP3 should only be
delivering MTP/SCCP management messages which should not in themselves push
an MTP2 implementation out of buffer space even once level 3 link congestion
has been experienced.

Because the ASP M2UA cannot know all of the specifics about buffer space on
an MTP2 implementation, it is also not in a good position to determine the
MTP3 primitive onto which to map this indication.  The SG implementation is
in a far better position to make this determination and has all of the M2UA
messages necessary at its disposal without this indication.

It don't believe that it is necessary to have an ASP M2UA implementation
attempt to compensate for the design deficiencies of an SG or even the
design deficiencies of an MTP2 implementation.

I have absolutely no use for it.  Please at least remove the "shall".

Jacob Heitz wrote:               (Thu, 14 Jun 2001 20:06:58)
>
> I think LEVEL_DISCARDING should be the same as LEVEL_4.
> At LEVEL_3, it is not discarding, just indicating the
> highest level of congestion consistent with the MTP specs.
> The MTP specs have no value for indicating that MTP2
> is discarding MSUs from MTP3, because when MTP3 and
> MTP2 are colocated, it shouldn't happen. If M2UA runs
> out of memory to store received MSUs received from the
> ASP, an option might be to simply stop reading them
> from the SCTP stream. Then SCTP would eventually close
> the window and the ASP would stop sending. This has two
> disadvantages. One, it will stop all other streams in
> the same association from flowing and two, it will prevent
> the SG from receiving possibly important M2UA control
> messages, such as STATUS_FLUSH_BUFFERS. An alternative
> is to send LEVEL_4. Response of ASP is implementation
> dependent. It could be processor outage or whatever
> you choose. 
> 
> Another way to solve the same problem might
> be with your correlation ID: don't ack it. We don't
> have your text for this yet though. Let's see it:
> you never know, we might finally be able to agree on 
> something.
> 
> 
> "Brian F. G. Bidulock" wrote:
> > 
> > Section 3.3.1.7 has a congestion status and discard value
> > in the list named LEVEL_4.  The text refers to a LEVEL_DISCARDING
> > which is not in the list.  The text indicates that a variant
> > not supporting multiple congestion levels (or states) "will"
> > use LEVEL_NONE and LEVEL_3.  The text requires that the SG "shall"
> > send LEVEL_DISCARDING when it runs out of buffers and begins
> > discarding MSUs, even though it seems that the SG will have
> > already sent "LEVEL_3" congestion status and "LEVEL_3" discard
> > status which indicates the same thing.  It is not clear to me
> > what the ASP M2UA is supposed to do with the LEVEL_DISCARDING
> > indication.  What is it supposed to do?  (Its response to
> > the other levels are clear from the MTP specs, but what about
> > LEVEL_DISCARDING?  And what is LEVEL_4?  How are they different
> > from congestion status LEVEL_3 and discard status LEVEL_3?
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: Reinventing the Wheel
Date: Fri, 15 Jun 2001 10:14:38 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x3.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x3.nokia.com [131.228.20.26]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

> My application is LNP.  It's fairly big here in North 
> America.  It uses big hunkin SCPs which handling an ever-increasing 
> and significant percentage of all the local telephone calls.  It 
> will not run over today's Internet and doesn't need SCTP's or 
> the IETF's myopic view of Internet-Friendly congestion control.

Then don't use IP.  It is quite simple then.  The protocols being developed
here are not required to use.

> I'll provide some feedback on that topic, however, I would like to see
> the relay problems (Class 0 and Class 2) and decoupling at the relay
> point addressed in the spec first.  As SUA-05 stands, it cannot handle
> classes 0 and 2 where the SG does not provide Final GTT.  (Which is
> rather restrictive, because Final GTT is almost never performed at
> the terminating node.)

I will send a copy of the draft to the editor today.  I'd appreciate
comments.

> Also, if you are only using MTP destination congestion, there is only
> MTP-3 to stop it.  What I mean by that is that an SMS overload will
> consume all MTP3 capacity to the destinations to be usurped from other
> MTP3 users.  That is why I would not like your SMS application running
> along side my revenue generating ISUP calls.

As I understand it, SMS generates more revenues than calls for many
operators here in Europe.

br,
John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: Reinventing the Wheel
Date: Fri, 15 Jun 2001 10:18:40 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x3.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x3.nokia.com [131.228.20.26]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

> Are you saying that the AMF and ASP management are the only
> reasons for using SUA?  I was looking a SUA-05 where there
> is no AMF and ASP management is inadequate to the task.

That has been pointed out, and we've been working on this.

> Given that Class 0 and 2 are quite popular in this arrangement,
> I doubt that the claim that SUA-05 provides "seamless"
> support for existing SCCP-Users holds all that much water.

That is the goal, however.
 
> I will attempt to provide enough comments to at least get
> SUA into a state which is useable for Class 0 operation.

All constructive comments are appreciated.

> Could you please respond to my note on "SUA5: SG Relay Problems"?

Most of what you were questioning has been deleted and replaced with
different text, in different sections.  Please see the latest version, which
should come out soon.

br,
John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Fri, 15 Jun 2001 10:38:45 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x4.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x4.nokia.com [131.228.20.27]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Gery,
 
Thanks for the comments. I have updated the text accordingly, one final pass
through the document, then it is off to the IETF editors we go.

Hello John, 

Good proposal. However, this address parameter should only contain : 

- point code + SSN (optional) : existing case for interworking with SS7,
with already defined actions for the SG - IP address + SSN (optional) :
all-IP environment. 

if we want to avoid GT and/or hostname management in SUA. The same applies
to DAVA and SCON messages. 

The management procedures (for (un)availability and congestion) in an all-IP
environment could look something like this :

"If an SUA node receives an ASP_DOWN, ASP_INACTIVE or SCTP_CDI indication it
should inform it's concerned neighbours with a DUNA message, including the
primary IP-address of the SCTP association where these indications are
received from.

If an SUA node receives an ASP_ACTIVE indication it should inform it's
concerned neighbours with a DAVA message, including the primary IP-address
of the SCTP association on which the indication was received.

If an SUA node receives a DUNA, DAVA or SCON message, and the IP-address of
the address parameter is equal to the primary IP-address of the SCTP
association it was received on, the SUA node should inform it's concerned
neighbours by sending on the received message unchanged towards them. In
case of a DUNA or DAVA message, the SSN should be included in the address
parameter as well.

In this way, neighbouring nodes have the opportunity to select alternative
routes or destinations, when communication via a certain node (the one
sending the DUNA, DAVA, SCON messages) is impossible or congested."

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: RE: SUA5: SG Relay Problems
Date: Fri, 15 Jun 2001 11:14:09 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x2.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x2.nokia.com [131.228.20.22]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

> In Section 6.2 and 6.3 of v5 of the draft, some statements are made
> which have some problems with them with regard to the SS7 network.

This section has been removed.  Some of the text has been incorporated
elsewhere, other text has ceased to exist.  I think your comments are very
good, I think we need to capture this kind of text in the applicability
statement. 

I hope that the SUA document can serve as a protocol document, mostly bits
and bytes.  When we need to discuss how the protocol is used, the AS is the
place for this (I think that M3UA, M2UA/M2PA and IUA MUST have usage
sections in the AS).

Some questions: 

> In the replicated end-point case no consideration has been 
> given for the nature of the signalling links between the STPs 
> and the SGs.  I take it that these are B/D-links, and that the SG 
> are equipped with the transfer function (i.e, they are perceived 
> by the SS7 network to be STPs): any other assumption would present 
> a whole range of other difficulties.

Will this require any protocol support?

> Given that proper SLS selection, loadsharing, and SG 
> selection based on point code availability must be performed at 
> the ASP, it will be necessary for the ASP to maintain the status 
> of each distant signalling point to which it communicates on the 
> basis of the SG through which it may route, similar to M3UA's 
> management of multiple SGs and multiple routes via multiple SGs.

Thanks for the suggest, I will add this to the text.

> Does the new draft provide any procedural enhancements to support
> transparent operation with the SS7 network?

Yes it does.  

thanks,
John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: A Srivastav <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA : SG Load Sharing
Date: Fri, 15 Jun 2001 20:27:43 +0800
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-SMTP-HELO: myrealbox.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [192.108.102.201]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,
    In your text below you say that each SG has its own signalling point
code. In my opinion, ASP should be perfectly game for the situation when two
SGs have the same point code..  Or alternately do you term such
configuration as two SGPs rather than 2 SGs?

I am talking about the point code that a SG is assumed to have when you
provision SG information at the ASP..

Anubhav

----- Original Message -----
From: Brian F. G. Bidulock <[email-masked]> To: sigtran
<[email-masked]> Sent: Thursday, June 14, 2001 2:43 PM
Subject: Re: M3UA : SG Load Sharing

Mukesh,

Let me venture an answer:

In the multiple SG arrangement, each SG has its own signalling point code
and is acting as an STP in the network.  Selection of SG is implementation
dependent but could be performed on a similar basis as A-link selection at
an SEP in the SS7 network.  Should an SG fail, it is similar to an STP
failing in the SS7 network today.
Messages will be lost and the sending SEP will be faced with discarding all
messages which were already transmitted to the other end (whether
acknowledged or not).

STP's are engineered to fail for less than about 1 minute per year or to
about .999998 reliability, to avoid this situation.

In general, an SEP cannot distinguish between STP failure and the failure of
all signalling links to an STP, except that a transfer prohibited message
might be received on the alternate link in the case of STP failure.

Because M3UA has no changeover procedures from ASP to SG, it is likely that
messages will be mis-sequenced if traffic is not withheld for some period
before sending SLSs which were previouly sent via the failed SG to the
alternate SG.  I would recommend procedures similar to time-controlled
changeover.

To meet reliablity requirements, however, SCTP associations between an ASP
and an SG, by analogy might have to be engineered to the reliablity of an
entire SS7 linkset.  This would be particularly challenging.

So, it is not specified in the M3UA, but of your two choices, I would pick
(b), i.e, withhold traffic for a short period before restarting the SLSs on
the alternate SG.

Should the failed SG recover, it will be necessary to perform some sort of
changeback as well.  Here it might be quite possible for the ASP to slip a
changeback message into the data stream for the SLSs to be changed back and
if the SG will transfer the changeback acks, changeover the traffic in a
coordinated fashion instead of performing time-controlled rerouting.  I
suppose that is up to you.

It does bring up the question as to whether M3UA at the SG should rather
*not* terminal *all* MTP MGMT messages, but should allow changeback acks
through.

Certainly, if an Correlation Id and Acknowledgement were provided on MSUs
transfered between SG and ASP, normal or emergency changeover could be
performed in the event of a failed SCTP association, however, a
time-controlled changeover would still apply in the case of SG failure.

Withough some sort of sequence numbering, normal changeover is impossible,
resulting in an increase in discarded messages resulting from changeover.
Withough passing changeback messages, coordinated changeback is impossible,
resulting in increased delay and possibility of missequencing resulting from
changeback.

With this consideration, to meet the capabilities of a combined A-link set,
M3UA might need to required even more that A-link set reliability from the
SCTP association from ASP to SG.  This should be quite challenging for
implementors and operators.

A proposal for changeover and changeback procedures would alleviate some of
this requirement on SCTP reliability, but previous proposals for changeover
and changeback in M3UA have not been well received.

--Brian

[email-masked] wrote:                     (Tue, 12 Jun 2001 16:30:57)
>
>
>
>
> Hi,
>
> This is regarding SG Load Sharing from ASP side.
>
> As draft says the loadsharing can be done on the basis of SLS:
> "In order to direct messages to the SS7 network, the ASP must also perform
a
> message distribution function in order to choose the proper
> SG or SGP for a given message.
>
> This is accomplished by observing the
> Destination Point Code (and possibly other elements of the outgoing
> message such as the SLS value), together with the SS7 destination
> availability/restricted/congestion status via the SG(s) and the
availability of
> the SG and SGPs themselves."
>
> Suppose there are two SGs active in load shared mode and traffic is being
load
> shared on the basis of SLS value. Both SGs give identical DPC rechability
to
> SS7 network. Now if one SG goes down(or association to that SG fails) then
how
> should SLS values assigned to failed SG be handled in order to avoid
> mis-sequencing.
> a) Have a pre-defined set of SLS values for each SG. In this case if one
SG
> failes its's assigned SLS values won't have a route.
> OR
> b) Using time controlled changeover i.e. retrieving messages from failed
> association, wait for a timer period and then resent retrieved messages on
> alternate association.
>
> Or is there any other option.
>
>
> Thanks and Regards
> -Mukesh
>
>

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Reinventing the Wheel
Date: Fri, 15 Jun 2001 14:55:56 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades6.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [194.78.143.126]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: Reinventing the Wheel</TITLE> </HEAD>
<BODY>

<P><FONT SIZE=2>Brian,</FONT>
</P>

<P><FONT SIZE=2>See below !</FONT>
</P>

<P><FONT SIZE=2>____________________________</FONT> </P>

<P><FONT SIZE=2>Gery Verwimp</FONT>
<BR><FONT SIZE=2>&gt; SIEMENS ATEA</FONT> <BR><FONT SIZE=2>&gt; ICN D CS
D5</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Tel. : +32 14 25 3424</FONT> <BR><FONT SIZE=2>Fax :
+32 14 25 3212</FONT> <BR><FONT SIZE=2><A
HREF="mailto:[email-masked]">mailto:[email-masked].
be</A></FONT> <BR><FONT SIZE=2>____________________________________</FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT> <BR><FONT SIZE=2>From:
Brian F. G. Bidulock [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>Sent: donderdag 14 juni 2001 19:33</FONT> <BR><FONT
SIZE=2>To: sigtran</FONT>
<BR><FONT SIZE=2>Subject: Re: Reinventing the Wheel</FONT> </P>
<BR>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; [GV] : Then we should rename the IETF Area
&amp; Working Group.</FONT> </P>

<P><FONT SIZE=2>Why would you do that?&nbsp; The IETF does not use OSI
terminology.</FONT> </P>

<P><FONT SIZE=2>=&gt; Just kidding ;)</FONT> <BR><FONT SIZE=2>&lt;=</FONT>
</P>

<P><FONT SIZE=2>[snip]</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; [GV] : Well obviously one needs a route to
deliver the goods to the</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
correct address. A network provides routing services, as user you</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; provide a valid address and some
indication of the QoS you want. Just</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; as sending a letter. MTP provides such
services (totally</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
connectionless).</FONT> </P>

<P><FONT SIZE=2>Many IP networks do not require routers.</FONT> </P>

<P><FONT SIZE=2>=&gt; [GV2] Ok, but bridges/switches/... also maintain some
kind of connections (&quot;incoming port, label, outgoing port&quot;
vector).</FONT></P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; [GV] : From E.164 to IP-address ? How to
select the next NSD wisely,</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
and how to engineer this in your network, is far from trivial.</FONT> </P>

<P><FONT SIZE=2>Map E.164 by TT to PC SSN (as today).&nbsp; Map PC SSN to
SCTP endpoint (ASP).</FONT> <BR><FONT SIZE=2>It is a very simple
table.</FONT> </P>

<P><FONT SIZE=2>=&gt; [GV2] Yes, that process is simple enough. And more
than that can be supported as well. I was referring to network planning, and
keeping your address mapping tables from exploding.</FONT></P>

<P><FONT SIZE=2>&lt;=</FONT>
</P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &gt;</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &gt;&gt;</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &gt;&gt;&nbsp;&nbsp;&nbsp; Yes, but without
congestion control. What you are suggesting</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; here is</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &gt;&gt;&nbsp;&nbsp;&nbsp; to do the
connectionless stuff over UDP WITHOUT congestion</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &gt;&gt;&nbsp;&nbsp;&nbsp;
control.(..............................................)</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &gt;</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &gt; TCAP provides congestion control.&nbsp;
SCCP provides congestion control</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &gt; on Class 3.</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; [GV] : ??? Seems I missed something in
Q.771-775 or T1.114. But if you</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; want to run TCAP directly over UDP/IP
...</FONT> </P>

<P><FONT SIZE=2>Code gapping is an example.&nbsp; There is more to protect
from congestion</FONT> <BR><FONT SIZE=2>than just the intervening
network.</FONT> </P>

<P><FONT SIZE=2>=&gt; [GV2] : Ah, but ACG is an (A)IN procedure to signal an
overloaded service (e.g. 800 number). From pure TCAP point of view, there's
nothing in the specs that requires this. Each application is responsible for
itself to provide such measures. TCAP provides a common framework to do this
(remote operations), but TCAP couldn't care less what each of these
operations actually stand for. At least from the TCAP model point of
view.</FONT></P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; SCCP provides flow control on Class
3. For a distinction between flow</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; control and congestion control, please read
the SCTP applicability</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
statement.</FONT> </P>

<P><FONT SIZE=2>I think you are comparing ITU &quot;flow control&quot; to
IETF &quot;flow control&quot;.&nbsp; They</FONT> <BR><FONT SIZE=2>are not
the same thing.</FONT> </P>

<P><FONT SIZE=2>=&gt; [GV2] : Still, with flow control the receiver can
limit what he gets, even if there is no sign of congestion, just to
guarantee that one &quot;flow&quot; does not use up more
bandwidth/processing time than it's supposed to. Call it congestion
prevention if you want. I tend to think congestion control kicks in
&quot;after the fact&quot;. Can you give me an example of where the ITU and
IETF definitions differ ?</FONT></P>

<P><FONT SIZE=2>&lt;=</FONT>
</P>

<P><FONT SIZE=2>My application is LNP.&nbsp; It's fairly big here in North
America.&nbsp; It uses</FONT> <BR><FONT SIZE=2>big hunkin SCPs which
handling an ever-increasing and significant</FONT> <BR><FONT
SIZE=2>percentage of all the local telephone calls.&nbsp; It will not run
over today's</FONT> <BR><FONT SIZE=2>Internet and doesn't need SCTP's or the
IETF's myopic view of Internet-</FONT> <BR><FONT SIZE=2>Friendly congestion
control.</FONT> </P>

<P><FONT SIZE=2>I'll provide some feedback on that topic, however, I would
like to see</FONT> <BR><FONT SIZE=2>the relay problems (Class 0 and Class 2)
and decoupling at the relay</FONT> <BR><FONT SIZE=2>point addressed in the
spec first.&nbsp; As SUA-05 stands, it cannot handle</FONT> <BR><FONT
SIZE=2>classes 0 and 2 where the SG does not provide Final GTT.&nbsp; (Which
is</FONT> <BR><FONT SIZE=2>rather restrictive, because Final GTT is almost
never performed at</FONT> <BR><FONT SIZE=2>the terminating node.)</FONT>
</P>

<P><FONT SIZE=2>=&gt; [GV2] : SUA-05 contains a limited view on the relay
functionality (restricted to SG, where it of course bases on the SCCP
already present). We hope to have it extended in SUA-06 !</FONT></P>

<P><FONT SIZE=2>&lt;=</FONT>
</P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &gt;</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &gt; If your SMS service does not provide
congestion controls at the</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
&gt; application level, you can keep it off of my SS7 network.&nbsp; I
would</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &gt; not permit your
SMS to run with my ISUP with only MTP Level 3</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &gt; congestion to stop it (and my ISUP at the
same time).</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &gt;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; [GV] : SMS's are routed on Global Title.
There's no congestion</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
indication attached to that right now, although there have been</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; discussions about GT management.
Anyway, SCCP maps this on a DPC (next</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; relay or end node) and will not transfer the
message to MTP if the</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
congestion level of this DPC is &quot;higher&quot; than the message
priority</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; (given by the
application).</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; So there's not only MTP-3 to stop
it.</FONT> </P>

<P><FONT SIZE=2>Does SMS do successive global title withing the same
administrative</FONT> <BR><FONT SIZE=2>domain?&nbsp; Are your operators ok
with that?</FONT> </P>

<P><FONT SIZE=2>Also, if you are only using MTP destination congestion,
there is only</FONT> <BR><FONT SIZE=2>MTP-3 to stop it.&nbsp; What I mean by
that is that an SMS overload will</FONT> <BR><FONT SIZE=2>consume all MTP3
capacity to the destinations to be usurped from other</FONT> <BR><FONT
SIZE=2>MTP3 users.&nbsp; That is why I would not like your SMS application
running</FONT> <BR><FONT SIZE=2>along side my revenue generating ISUP
calls.</FONT> </P>

<P><FONT SIZE=2>=&gt; [GV] : Due to roaming, the SMS traffic might traverse
several intermediate networks (other PLMNs, or PSTN networks) before
reaching the SMS-service center of the roaming subscriber, or the
destination (also roaming ?) mobile subscriber. And indeed, in each gateway
(where network borders are crossed) a global title translation is necessary.
I have seen figures that SMS traffic can be up to 10% (or more ?) of all
signalling traffic that is going around in the network. But SMS also
generates revenue (at least for the mobile operators and service center
providers, it is a money-printing machine).</FONT></P>

<P><FONT SIZE=2>As far as congestion is concerned, either the radio access
is congested first, or the service center, before the network would break
down ...</FONT></P>

<P><FONT SIZE=2>It might be interesting for you to know that, due to the
boom of SMS traffic these last few months in Europe, several (fixed network)
operators have requested special SCCP accounting for SMS related traffic ! I
think the same might become true for Number Portability. Yes, we have
already received an accounting request for this too : when using the SRF
method our SCCP is involved (e.g. non-call related traffic like CCBS, or
ported services).</FONT></P>

<P><FONT SIZE=2>&lt;=</FONT>
</P>

<P><FONT SIZE=2>[snip]</FONT>
</P>

<P><FONT SIZE=2>-- </FONT>
<BR><FONT SIZE=2>Brian F. G. Bidulock</FONT> <BR><FONT
SIZE=2>[email-masked]</FONT> <BR><FONT SIZE=2><A
HREF="http://www.openss7.org/"
TARGET="_blank">http://www.openss7.org/</A></FONT> </P>
<BR>

<P><FONT SIZE=2>---</FONT>
<BR><FONT SIZE=2>You are currently subscribed to sigtran as:
[email-masked]</FONT> <BR><FONT SIZE=2>To unsubscribe send a
blank email to [email-masked]</FONT> </P>

---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY>
</HTML>

</x-html>
From: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Reinventing the Wheel
Date: Fri, 15 Jun 2001 15:07:49 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades6.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mailhost2.atea.be [194.78.143.126]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: Reinventing the Wheel</TITLE> </HEAD>
<BODY>

<P><FONT SIZE=2>Brian,</FONT>
</P>

<P><FONT SIZE=2>I agree SUA-05 is still basic (we wanted to get all the
parameters right first), and we are only recently doing work on getting more
interesting features into SUA. A few pointers :</FONT></P>

<P><FONT SIZE=2>- the AMF will be the base of the SUA-relay functionality.
The SUA draft should provide all possible valid input-output values and the
minimum of required procedures (e.g. hop counter for loop prevention). How
the AMF is provisioned (address mapping tables) or what methods one uses to
provide it (proprietary database, existing DNS, ...) is out of scope; as
long as the performance requirements of Q.716 are met.</FONT></P>

<P><FONT SIZE=2>- ASP management on it's own is not enough in this respect.
The functionality of DUNA, DAVA and SCON messages is being extended to
provide a &quot;real&quot; SUA management (Notify and Error won't do the
trick).</FONT></P>

<P><FONT SIZE=2>BTW : we want to avoid to already very complex routing key
exchanges (REG, DEREG, overlapping keys) in M3UA and leave these issues for
a network management protocol or other means of provisioning.</FONT></P>

<P><FONT SIZE=2>regards,</FONT>
</P>

<P><FONT SIZE=2>____________________________</FONT> </P>

<P><FONT SIZE=2>Gery Verwimp</FONT>
<BR><FONT SIZE=2>&gt; SIEMENS ATEA</FONT> <BR><FONT SIZE=2>&gt; ICN D CS
D5</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Tel. : +32 14 25 3424</FONT> <BR><FONT SIZE=2>Fax :
+32 14 25 3212</FONT> <BR><FONT SIZE=2><A
HREF="mailto:[email-masked]">mailto:[email-masked].
be</A></FONT> <BR><FONT SIZE=2>____________________________________</FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT> <BR><FONT SIZE=2>From:
Brian F. G. Bidulock [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>Sent: donderdag 14 juni 2001 19:43</FONT> <BR><FONT
SIZE=2>To: sigtran</FONT>
<BR><FONT SIZE=2>Subject: Re: Reinventing the Wheel</FONT> </P>
<BR>

<P><FONT SIZE=2>Verwimp,</FONT>
</P>

<P><FONT SIZE=2>Are you saying that the AMF and ASP management are the
only</FONT> <BR><FONT SIZE=2>reasons for using SUA?&nbsp; I was looking a
SUA-05 where there</FONT> <BR><FONT SIZE=2>is no AMF and ASP management is
inadequate to the task.</FONT> </P>

<P><FONT SIZE=2>Also, SUA-05 does not provide adequate support for Class
0</FONT> <BR><FONT SIZE=2>and 2 operation in a network with multiple SGs
where the SG</FONT> <BR><FONT SIZE=2>is not in control of the placement of
Final GTT.</FONT> </P>

<P><FONT SIZE=2>Given that Class 0 and 2 are quite popular in this
arrangement,</FONT> <BR><FONT SIZE=2>I doubt that the claim that SUA-05
provides &quot;seamless&quot;</FONT> <BR><FONT SIZE=2>support for existing
SCCP-Users holds all that much water.</FONT> </P>

<P><FONT SIZE=2>I agree that the ASP management has some value, but it
is</FONT> <BR><FONT SIZE=2>quite easy to borrow from the other UAs and
another approach</FONT> <BR><FONT SIZE=2>does not preclude using the same
ASP management techniques</FONT> <BR><FONT SIZE=2>because other specs do not
specify management to the extent</FONT> <BR><FONT SIZE=2>that SIGTRAN
protocols are attempting to do.</FONT> </P>

<P><FONT SIZE=2>I will attempt to provide enough comments to at least
get</FONT> <BR><FONT SIZE=2>SUA into a state which is useable for Class 0
operation.</FONT> <BR><FONT SIZE=2>Could you please respond to my note on
&quot;SUA5: SG Relay Problems&quot;?</FONT> </P>

<P><FONT SIZE=2>--Brian</FONT>
</P>
<BR>

<P><FONT SIZE=2>Verwimp Gery
wrote:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp; (Thu, 14 Jun 2001 11:55:13)</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Brian,</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; You snipped the part where I was trying to
explain that ... I'll</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; repeat
it for your convenience :</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; It is the intention
(whenever SUA issue 6 gets out, John ?) to have</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; the possibility of extensive addressing
mechanisms in SUA as well. As</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
such SUA would allow pointcodes, GTs, IP addresses, hostnames, ... as</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; valid addresses and make use of an
address mapping function (AMF) to</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; resolve these to the SCTP association ID
towards the end-node or a</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
relay-node (where AMF is repeated).</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; This feature will offer scalability : for
larger networks it would be</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
rather cumbersome to have a fully meshed overlay of SCTP
associations,</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; and an
overloaded management system to boot.</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; The AMF would offer the routing functionality
like that of an SS7 STP</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; (I'm
not talking about any management procedures), with any kind of</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; address.</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Another thing in SUA is to extend the ASP
management, which is just</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
informing the other end of an SCTP association. A proposal was made
to</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; have an SUA relay node
inform it's other (concerned) neighbours as</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; well, by extension of the DUNA, DAVA, SCON
messages.</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Summary :</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; SUA supports both the classic SS7 SCCP users
(TCAP or not),</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; inter-working,
as well as new applications to be run in an all-IP</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; environment. The relay functionality is
particularly of interest to</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
the 3GPP UMTS networks.</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Best regards,</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; ____________________________</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Gery Verwimp</FONT> </P>

<P><FONT SIZE=2>-- </FONT>
<BR><FONT SIZE=2>Brian F. G. Bidulock</FONT> <BR><FONT
SIZE=2>[email-masked]</FONT> <BR><FONT SIZE=2><A
HREF="http://www.openss7.org/"
TARGET="_blank">http://www.openss7.org/</A></FONT> </P>
<BR>

<P><FONT SIZE=2>---</FONT>
<BR><FONT SIZE=2>You are currently subscribed to sigtran as:
[email-masked]</FONT> <BR><FONT SIZE=2>To unsubscribe send a
blank email to [email-masked]</FONT> </P>

---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY>
</HTML>

</x-html>
From: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: SG Relay Problems
Date: Fri, 15 Jun 2001 16:27:43 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades6.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [194.78.143.126]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: SUA5: SG Relay Problems</TITLE> </HEAD>
<BODY>

<P><FONT SIZE=2>Hi John, Brian,</FONT>
</P>

<P><FONT SIZE=2>The type of linkset between SS7 STP and SG would have no
further consequences for the SCCP/SUA functions on the SG I think, but I
could be missing something (unless you want to support traffic mix
procedures, no, even that would be terminated at the SG).</FONT></P>

<P><FONT SIZE=2>Let's see :</FONT>
</P>

<P><FONT SIZE=2>- the SS7 procedures terminate at the SG. In this respect
the ASPs have to be viewed as SCCP-users, who might receive (if they are
interested, that is) status notifications. These are made via the DUNA, DAVA
and SCON messages, who might contain an affected point code (point code
status management) or an affected point code + SSN (subsystem management).
The ASP receiving such messages MUST take appropriate action and
stop/resume/reduce traffic towards the affected destination (PC and/or SSN)
or reroute via another SG. This is indeed a minimum requirement for an
SUA-end-node !</FONT></P>

<P><FONT SIZE=2>But, as you might know, when routing is on GT and GT
translation is performed on the SG, it's the SG who has to take these
actions (the ASP has then no idea of affected point codes). This is also a
restriction in SCCP management ...</FONT></P>

<P><FONT SIZE=2>Following this reasoning, the SG should always be considered
as SEP from SS7 point of view, even if it is able to perform GTT. In case of
SUA, there's no MTP transfer possible towards the IP-domain anyway. It is an
end node.</FONT></P>

<P><FONT SIZE=2>- of course, the SG could act as SS7 STP as well : combined
STP/SG (combined STP/SEP). This configuration might occur in ITU-networks,
but in ANSI these are always strictly separated functions. ITU doesn't know
about linkset types, for ANSI such configurations would give headaches and a
lot of trouble :-(( Perhaps we should add some text to clarify this :
instead of STP we should use the term SRP (Signalling Relay Point) to avoid
confusion with the &quot;loaded&quot; STP term.</FONT></P>

<P><FONT SIZE=2>- I haven't seen anything like a C-link between a mated pair
of SGs, not even in M3UA ?</FONT> </P>

<P><FONT SIZE=2>Brian : for SLS selection :</FONT> </P>

<P><FONT SIZE=2>- SUA at the ASP selects an appropriate SCTP stream ID
(possibly based on information given by the SUA-user),</FONT> <BR><FONT
SIZE=2>- the SG (let's say the NIF) maps the received stream ID onto an SLS.
To assure an even distribution other information can be taken into account
as well : network appearance, DPC, ... whatever does not compromise
in-sequence-delivery.</FONT></P>

<P><FONT SIZE=2>Regards,</FONT>
</P>

<P><FONT SIZE=2>____________________________</FONT> </P>

<P><FONT SIZE=2>Gery Verwimp</FONT>
<BR><FONT SIZE=2>&gt; SIEMENS ATEA</FONT> <BR><FONT SIZE=2>&gt; ICN D CS
D5</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Tel. : +32 14 25 3424</FONT> <BR><FONT SIZE=2>Fax :
+32 14 25 3212</FONT> <BR><FONT SIZE=2><A
HREF="mailto:[email-masked]">mailto:[email-masked].
be</A></FONT> <BR><FONT SIZE=2>____________________________________</FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT> <BR><FONT SIZE=2>From:
[email-masked] [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</F
ONT> <BR><FONT SIZE=2>Sent: vrijdag 15 juni 2001 10:14</FONT> <BR><FONT
SIZE=2>To: sigtran</FONT>
<BR><FONT SIZE=2>Cc: [email-masked]</FONT>
<BR><FONT SIZE=2>Subject: RE: SUA5: SG Relay Problems</FONT> </P>
<BR>

<P><FONT SIZE=2>Hi Brian,</FONT>
</P>

<P><FONT SIZE=2>&gt; In Section 6.2 and 6.3 of v5 of the draft, some
statements are made</FONT> <BR><FONT SIZE=2>&gt; which have some problems
with them with regard to the SS7 network.</FONT> </P>

<P><FONT SIZE=2>This section has been removed.&nbsp; Some of the text has
been incorporated</FONT> <BR><FONT SIZE=2>elsewhere, other text has ceased
to exist.&nbsp; I think your comments </FONT> <BR><FONT SIZE=2>are very
good, I think we need to capture this kind of text in the</FONT> <BR><FONT
SIZE=2>applicability statement. </FONT> </P>

<P><FONT SIZE=2>I hope that the SUA document can serve as a protocol
document, mostly</FONT> <BR><FONT SIZE=2>bits and bytes.&nbsp; When we need
to discuss how the protocol is used,</FONT> <BR><FONT SIZE=2>the AS is the
place for this (I think that M3UA, M2UA/M2PA and IUA</FONT> <BR><FONT
SIZE=2>MUST have usage sections in the AS).</FONT> </P>

<P><FONT SIZE=2>Some questions: </FONT> </P>

<P><FONT SIZE=2>&gt; In the replicated end-point case no consideration has
been </FONT> <BR><FONT SIZE=2>&gt; given for the nature of the signalling
links between the STPs </FONT> <BR><FONT SIZE=2>&gt; and the SGs.&nbsp; I
take it that these are B/D-links, and that the SG </FONT> <BR><FONT
SIZE=2>&gt; are equipped with the transfer function (i.e, they are perceived
</FONT> <BR><FONT SIZE=2>&gt; by the SS7 network to be STPs): any other
assumption would present </FONT> <BR><FONT SIZE=2>&gt; a whole range of
other difficulties.</FONT> </P>

<P><FONT SIZE=2>Will this require any protocol support?</FONT> </P>

<P><FONT SIZE=2>&gt; Given that proper SLS selection, loadsharing, and SG
</FONT> <BR><FONT SIZE=2>&gt; selection based on point code availability
must be performed at </FONT> <BR><FONT SIZE=2>&gt; the ASP, it will be
necessary for the ASP to maintain the status </FONT> <BR><FONT SIZE=2>&gt;
of each distant signalling point to which it communicates on the </FONT>
<BR><FONT SIZE=2>&gt; basis of the SG through which it may route, similar to
M3UA's </FONT> <BR><FONT SIZE=2>&gt; management of multiple SGs and multiple
routes via multiple SGs.</FONT> </P>
<BR>

<P><FONT SIZE=2>Thanks for the suggest, I will add this to the text.</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; Does the new draft provide any procedural enhancements
to support</FONT> <BR><FONT SIZE=2>&gt; transparent operation with the SS7
network?</FONT> </P>

<P><FONT SIZE=2>Yes it does.&nbsp; </FONT> </P>

<P><FONT SIZE=2>thanks,</FONT>
<BR><FONT SIZE=2>John</FONT>
</P>
<BR>

<P><FONT SIZE=2>---</FONT>
<BR><FONT SIZE=2>You are currently subscribed to sigtran as:
[email-masked]</FONT> <BR><FONT SIZE=2>To unsubscribe send a
blank email to [email-masked]</FONT> </P>

---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY>
</HTML>

</x-html>
From: "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA : SG Load Sharing
Date: Fri, 15 Jun 2001 11:14:57 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.59">
<TITLE>RE: M3UA : SG Load Sharing</TITLE> </HEAD>
<BODY>

<P><FONT SIZE=2>Greetings,</FONT>
</P>

<P><FONT SIZE=2>Currently we would, as you suggest, term such a
configuration as two SGPs.&nbsp; For the SGP failure cases, Brian's traffic
issues (and reliability challenges) still apply.&nbsp; </FONT></P>

<P><FONT SIZE=2>Cheers,</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; Greg</FONT> </P>

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
SIZE=2>From: &nbsp; A Srivastav [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>
] </FONT> <BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Friday, June 15, 2001 8:28
AM</FONT> <BR><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT>
<BR><FONT SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: M3UA
: SG Load Sharing</FONT> </P>

<P><FONT SIZE=2>Hi Brian,</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; In your text below you say that each SG
has its own signalling point</FONT> <BR><FONT SIZE=2>code. In my opinion,
ASP should be perfectly game for the situation when two</FONT> <BR><FONT
SIZE=2>SGs have the same point code..&nbsp; Or alternately do you term
such</FONT> <BR><FONT SIZE=2>configuration as two SGPs rather than 2
SGs?</FONT> </P>

<P><FONT SIZE=2>I am talking about the point code that a SG is assumed to
have when you</FONT> <BR><FONT SIZE=2>provision SG information at the
ASP..</FONT> </P>

<P><FONT SIZE=2>Anubhav</FONT>
</P>

<P><FONT SIZE=2>----- Original Message -----</FONT> <BR><FONT SIZE=2>From:
Brian F. G. Bidulock &lt;[email-masked]&gt;</FONT> <BR><FONT
SIZE=2>To: sigtran &lt;[email-masked]&gt;</FONT> <BR><FONT
SIZE=2>Sent: Thursday, June 14, 2001 2:43 PM</FONT> <BR><FONT
SIZE=2>Subject: Re: M3UA : SG Load Sharing</FONT> </P>
<BR>

<P><FONT SIZE=2>Mukesh,</FONT>
</P>

<P><FONT SIZE=2>Let me venture an answer:</FONT> </P>

<P><FONT SIZE=2>In the multiple SG arrangement, each SG has its own
signalling point</FONT> <BR><FONT SIZE=2>code and is acting as an STP in the
network.&nbsp; Selection of SG is</FONT> <BR><FONT SIZE=2>implementation
dependent but could be performed on a similar basis</FONT> <BR><FONT
SIZE=2>as A-link selection at an SEP in the SS7 network.&nbsp; Should an
SG</FONT> <BR><FONT SIZE=2>fail, it is similar to an STP failing in the SS7
network today.</FONT> <BR><FONT SIZE=2>Messages will be lost and the sending
SEP will be faced with</FONT> <BR><FONT SIZE=2>discarding all messages which
were already transmitted to the other</FONT> <BR><FONT SIZE=2>end (whether
acknowledged or not).</FONT> </P>

<P><FONT SIZE=2>STP's are engineered to fail for less than about 1 minute
per year</FONT> <BR><FONT SIZE=2>or to about .999998 reliability, to avoid
this situation.</FONT> </P>

<P><FONT SIZE=2>In general, an SEP cannot distinguish between STP failure
and the</FONT> <BR><FONT SIZE=2>failure of all signalling links to an STP,
except that a transfer</FONT> <BR><FONT SIZE=2>prohibited message might be
received on the alternate link in the</FONT> <BR><FONT SIZE=2>case of STP
failure.</FONT> </P>

<P><FONT SIZE=2>Because M3UA has no changeover procedures from ASP to SG, it
is</FONT> <BR><FONT SIZE=2>likely that messages will be mis-sequenced if
traffic is not</FONT> <BR><FONT SIZE=2>withheld for some period before
sending SLSs which were previouly</FONT> <BR><FONT SIZE=2>sent via the
failed SG to the alternate SG.&nbsp; I would recommend</FONT> <BR><FONT
SIZE=2>procedures similar to time-controlled changeover.</FONT> </P>

<P><FONT SIZE=2>To meet reliablity requirements, however, SCTP associations
between</FONT> <BR><FONT SIZE=2>an ASP and an SG, by analogy might have to
be engineered to the</FONT> <BR><FONT SIZE=2>reliablity of an entire SS7
linkset.&nbsp; This would be particularly</FONT> <BR><FONT
SIZE=2>challenging.</FONT>
</P>

<P><FONT SIZE=2>So, it is not specified in the M3UA, but of your two
choices, I</FONT> <BR><FONT SIZE=2>would pick (b), i.e, withhold traffic for
a short period before</FONT> <BR><FONT SIZE=2>restarting the SLSs on the
alternate SG.</FONT> </P>

<P><FONT SIZE=2>Should the failed SG recover, it will be necessary to
perform some</FONT> <BR><FONT SIZE=2>sort of changeback as well.&nbsp; Here
it might be quite possible for the</FONT> <BR><FONT SIZE=2>ASP to slip a
changeback message into the data stream for the SLSs</FONT> <BR><FONT
SIZE=2>to be changed back and if the SG will transfer the changeback
acks,</FONT> <BR><FONT SIZE=2>changeover the traffic in a coordinated
fashion instead of</FONT> <BR><FONT SIZE=2>performing time-controlled
rerouting.&nbsp; I suppose that is up to you.</FONT> </P>

<P><FONT SIZE=2>It does bring up the question as to whether M3UA at the SG
should</FONT> <BR><FONT SIZE=2>rather *not* terminal *all* MTP MGMT
messages, but should allow</FONT> <BR><FONT SIZE=2>changeback acks
through.</FONT> </P>

<P><FONT SIZE=2>Certainly, if an Correlation Id and Acknowledgement were
provided on</FONT> <BR><FONT SIZE=2>MSUs transfered between SG and ASP,
normal or emergency changeover</FONT> <BR><FONT SIZE=2>could be performed in
the event of a failed SCTP association,</FONT> <BR><FONT SIZE=2>however, a
time-controlled changeover would still apply in the case</FONT> <BR><FONT
SIZE=2>of SG failure.</FONT>
</P>

<P><FONT SIZE=2>Withough some sort of sequence numbering, normal changeover
is</FONT> <BR><FONT SIZE=2>impossible, resulting in an increase in discarded
messages resulting</FONT> <BR><FONT SIZE=2>from changeover.&nbsp; Withough
passing changeback messages, coordinated</FONT> <BR><FONT SIZE=2>changeback
is impossible, resulting in increased delay and</FONT> <BR><FONT
SIZE=2>possibility of missequencing resulting from changeback.</FONT> </P>

<P><FONT SIZE=2>With this consideration, to meet the capabilities of a
combined</FONT> <BR><FONT SIZE=2>A-link set, M3UA might need to required
even more that A-link set</FONT> <BR><FONT SIZE=2>reliability from the SCTP
association from ASP to SG.&nbsp; This should</FONT> <BR><FONT SIZE=2>be
quite challenging for implementors and operators.</FONT> </P>

<P><FONT SIZE=2>A proposal for changeover and changeback procedures would
alleviate</FONT> <BR><FONT SIZE=2>some of this requirement on SCTP
reliability, but previous proposals</FONT> <BR><FONT SIZE=2>for changeover
and changeback in M3UA have not been well received.</FONT> </P>

<P><FONT SIZE=2>--Brian</FONT>
</P>
<BR>

<P><FONT SIZE=2>[email-masked]
wrote:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (Tue, 12 Jun 2001
16:30:57)</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Hi,</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; This is regarding SG Load Sharing from ASP
side.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; As draft says the loadsharing can be done on the basis
of SLS:</FONT> <BR><FONT SIZE=2>&gt; &quot;In order to direct messages to
the SS7 network, the ASP must also perform</FONT> <BR><FONT SIZE=2>a</FONT>
<BR><FONT SIZE=2>&gt; message distribution function in order to choose the
proper</FONT> <BR><FONT SIZE=2>&gt; SG or SGP for a given message.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; This is accomplished by observing the</FONT> <BR><FONT
SIZE=2>&gt; Destination Point Code (and possibly other elements of the
outgoing</FONT> <BR><FONT SIZE=2>&gt; message such as the SLS value),
together with the SS7 destination</FONT> <BR><FONT SIZE=2>&gt;
availability/restricted/congestion status via the SG(s) and the</FONT>
<BR><FONT SIZE=2>availability of</FONT> <BR><FONT SIZE=2>&gt; the SG and
SGPs themselves.&quot;</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Suppose there are two SGs active in load shared mode
and traffic is being</FONT> <BR><FONT SIZE=2>load</FONT>
<BR><FONT SIZE=2>&gt; shared on the basis of SLS value. Both SGs give
identical DPC rechability</FONT> <BR><FONT SIZE=2>to</FONT>
<BR><FONT SIZE=2>&gt; SS7 network. Now if one SG goes down(or association to
that SG fails) then</FONT> <BR><FONT SIZE=2>how</FONT>
<BR><FONT SIZE=2>&gt; should SLS values assigned to failed SG be handled in
order to avoid</FONT> <BR><FONT SIZE=2>&gt; mis-sequencing.</FONT> <BR><FONT
SIZE=2>&gt; a) Have a pre-defined set of SLS values for each SG. In this
case if one</FONT> <BR><FONT SIZE=2>SG</FONT>
<BR><FONT SIZE=2>&gt; failes its's assigned SLS values won't have a
route.</FONT> <BR><FONT SIZE=2>&gt; OR</FONT>
<BR><FONT SIZE=2>&gt; b) Using time controlled changeover i.e. retrieving
messages from failed</FONT> <BR><FONT SIZE=2>&gt; association, wait for a
timer period and then resent retrieved messages on</FONT> <BR><FONT
SIZE=2>&gt; alternate association.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Or is there any other option.</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Thanks and Regards</FONT> <BR><FONT SIZE=2>&gt;
-Mukesh</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
</P>

<P><FONT SIZE=2>--</FONT>
<BR><FONT SIZE=2>Brian F. G. Bidulock</FONT> <BR><FONT
SIZE=2>[email-masked]</FONT> <BR><FONT SIZE=2><A
HREF="http://www.openss7.org/"
TARGET="_blank">http://www.openss7.org/</A></FONT> </P>
<BR>

<P><FONT SIZE=2>---</FONT>
<BR><FONT SIZE=2>You are currently subscribed to sigtran as:
[email-masked]</FONT> <BR><FONT SIZE=2>To unsubscribe send a
blank email to</FONT> <BR><FONT
SIZE=2>[email-masked]</FONT> </P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>---</FONT>
<BR><FONT SIZE=2>You are currently subscribed to sigtran as:
[email-masked]</FONT> <BR><FONT SIZE=2>To unsubscribe send a
blank email to [email-masked]</FONT> </P>

---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY>
</HTML>

</x-html>
Date: Fri, 15 Jun 2001 11:23:04 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA : SG Load Sharing
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.224]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Anubhav,

I think that the situation is quite different where two SGs (not SGPs) were
to have the same point code.  Look at the following diagram:

          +-------+         +-------+
          |       |         |       |
          |  STP  +---------+  SG   |
         /|       |\       /|       |\
        / +---+---+ \     / +-------+ \
       /      |      \   /      |      \ /-------\
              |       \ /               \|       |
              |        X        |        |  ASP  |
              |       / \               /|       |
       \      |      /   \      |      / \-------/
        \ +---+---+ /     \ +-------+ /
         \|       |/       \|       |/
          |  STP  +---------+  SG   |
          |       |         |       |
          +-------+         +-------+

If the SG's have the same point code, the links between the STPs and the SG
must be a split combined A-link set.  Without some sort of tightly coupled
communication between the SG, the ASP must make its selection of SG when
sending on the basis of SLS.  Only one SG will receive TFPs and other
management messages.  This is not a workable scenario unless the SGs
communicate state information between them in some tightly coupled manner.

I believe that is why Greg indicates that if they have the same point code,
they are two SGPs in one SG.

If they have different point codes, then the links to the STP can be
separate combined A-link sets just as if they are two independent SEPs, or
if the SG is equipped with the transfer function, they could be two STPs.

One of my points is that if they are two STPs, network operators will
require C-links between them (dashed line).
M3UA requires that an ASP serve no more than one SPMC, so if they are
separate SEPs, then there must be two ASPs at the host on the right (one for
each SG).

Therefore, the only rational explaination for this diagram is that the SGs
are STPs, they have C-links between them and are connected to the STPs with
B/D Links.
The ASP serving a signle SPMC has its own point code which is separate from
that of the SGs and the M2UA assocations between the SG and the ASP need be
treated in a similar fasion to a combined A-link set.

Or, they are two SGPs in one SG attached to the network by A-links and there
is a closely coupled communication between them where the C-links would have
been as follows:

                       +------------+
          +-------+    |    +-------+
          |       |    |    |       |
          |  STP  +    |    |  SGP  |
         /|       |\   |    |       |\
        / +---+---+ \  |    +-------+ \
       /      |      \ |        |   |  \ /-------\
              |       \|            |   \|       |
              |        |   SG   |   |    |  ASP  |
              |       /|            |   /|       |
       \      |      / |        |   |  / \-------/
        \ +---+---+ /  |    +-------+ /
         \|       |/   |    |       |/
          |  STP  +    |    |  SGP  |
          |       |    |    |       |
          +-------+    |    +-------+
                       +------------+

--Brian

A Srivastav wrote:                      (Fri, 15 Jun 2001 20:27:43)
> Hi Brian,
>     In your text below you say that each SG has its own signalling point
> code. In my opinion, ASP should be perfectly game for the situation when
two
> SGs have the same point code..  Or alternately do you term such
> configuration as two SGPs rather than 2 SGs?
> 
> I am talking about the point code that a SG is assumed to have when you
> provision SG information at the ASP..
> 
> Anubhav
> 
[snip]

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 15 Jun 2001 11:24:42 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: SUA5: SG Relay Problems
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-224.dallas.net [209.44.42.224]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

As it appears that a number of significant changes have been made to the new
draft, I eagerly await the opportunity to review it.

When can we expect to see it?

--Brian

On Fri, 15 Jun 2001, [email-masked] wrote:

> Hi Brian,
> 
> > In Section 6.2 and 6.3 of v5 of the draft, some statements are made
> > which have some problems with them with regard to the SS7 network.
> 
> This section has been removed.  Some of the text has been incorporated
> elsewhere, other text has ceased to exist.  I think your comments 
> are very good, I think we need to capture this kind of text in the
> applicability statement. 
> 
> I hope that the SUA document can serve as a protocol document, mostly
> bits and bytes.  When we need to discuss how the protocol is used,
> the AS is the place for this (I think that M3UA, M2UA/M2PA and IUA
> MUST have usage sections in the AS).
> 
> Some questions: 
> 
> > In the replicated end-point case no consideration has been 
> > given for the nature of the signalling links between the STPs 
> > and the SGs.  I take it that these are B/D-links, and that the SG 
> > are equipped with the transfer function (i.e, they are perceived 
> > by the SS7 network to be STPs): any other assumption would present 
> > a whole range of other difficulties.
> 
> Will this require any protocol support?
> 
> > Given that proper SLS selection, loadsharing, and SG 
> > selection based on point code availability must be performed at 
> > the ASP, it will be necessary for the ASP to maintain the status 
> > of each distant signalling point to which it communicates on the 
> > basis of the SG through which it may route, similar to M3UA's 
> > management of multiple SGs and multiple routes via multiple SGs.
> 
> 
> Thanks for the suggest, I will add this to the text.
> 
> 
> > Does the new draft provide any procedural enhancements to support
> > transparent operation with the SS7 network?
> 
> Yes it does.  
> 
> thanks,
> John

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 15 Jun 2001 11:46:13 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUA5: SG Relay Problems
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-224.dallas.net [209.44.42.224]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Verwimp,

Please see comments below...

Verwimp Gery wrote:                 (Fri, 15 Jun 2001 16:27:43)
> 
>    Hi John, Brian,
>    
>    The type of linkset between SS7 STP and SG would have no further
>    consequences for the SCCP/SUA functions on the SG I think, but I could
>    be missing something (unless you want to support traffic mix
>    procedures, no, even that would be terminated at the SG).

Oh, boy.  Here we go again.  See the current thread on M3UA about STP vs SEP
SGs.

>    
>    Let's see :
>    
>    - the SS7 procedures terminate at the SG. In this respect the ASPs
>    have to be viewed as SCCP-users, who might receive (if they are
>    interested, that is) status notifications. These are made via the
>    DUNA, DAVA and SCON messages, who might contain an affected point code
>    (point code status management) or an affected point code + SSN
>    (subsystem management). The ASP receiving such messages MUST take
>    appropriate action and stop/resume/reduce traffic towards the affected
>    destination (PC and/or SSN) or reroute via another SG. This is indeed
>    a minimum requirement for an SUA-end-node !

Although it might appear from the specifications that TFP/TFA is broadcast
to the world and that SSA/SSP is also broadcast to the world, in practice
STPs are provisioned in such as fashion that they only provide TFP/TFA to
signalling points to which they offer a route to the affected destination.
Also, SSA/SSP is only sent to concerned point codes which consist of point
codes to which the STP offers translations services resolving to the PC/SSN
of the subsystem in question.  These are not "discovery" protocols.

>    
>    But, as you might know, when routing is on GT and GT translation is
>    performed on the SG, it's the SG who has to take these actions (the
>    ASP has then no idea of affected point codes). This is also a
>    restriction in SCCP management ...

Which direction are you talking about?  Translation towards or away from the
ASP?  It matters.

>    
>    Following this reasoning, the SG should always be considered as SEP
>    from SS7 point of view, even if it is able to perform GTT. In case of
>    SUA, there's no MTP transfer possible towards the IP-domain anyway. It
>    is an end node.

I believe that would be too restrictive and completely rules out a group of
intereresting applications of SUA.

>    
>    - of course, the SG could act as SS7 STP as well : combined STP/SG
>    (combined STP/SEP). This configuration might occur in ITU-networks,
>    but in ANSI these are always strictly separated functions. ITU doesn't
>    know about linkset types, for ANSI such configurations would give
>    headaches and a lot of trouble :-(( Perhaps we should add some text to
>    clarify this : instead of STP we should use the term SRP (Signalling
>    Relay Point) to avoid confusion with the "loaded" STP term.

Combined SSP/STPs have been used in ANSI networks.  ANSI make no
restrictions on the combination or separation of functions in the network
above or beyond those of ITU.  ANSI does not define link set types either.
It is a common practice to refer to the functional set of messages which
must be supported by a linkset within a reference network architecture.

Because a SRP must be able to relay on the equivalent of PC/SSN (which is an
SCCP SAP Id) it must also be able to transfer to a PC other than its own
which, by definition means that it has the transfer function and is an STP.
Also, to perform the relay function requires that the relay point be
equipped with an MTP transfer function to permit both coupled and decoupled
operation in connection oriented and connectionless classes.

>    
>    - I haven't seen anything like a C-link between a mated pair of SGs,
>    not even in M3UA ?

It is an oversight in their diagram which I have brought to Greg's
attention.

>    
>    Brian : for SLS selection :
>    
>    - SUA at the ASP selects an appropriate SCTP stream ID (possibly based
>    on information given by the SUA-user),
>    - the SG (let's say the NIF) maps the received stream ID onto an SLS.
>    To assure an even distribution other information can be taken into
>    account as well : network appearance, DPC, ... whatever does not
>    compromise in-sequence-delivery.

And must also know the availability of routes at MTP3 via each SG to be able
to determine where to send the message.  The SLS value itself (and the rules
for generating it) also determine the SG which must be used for routing.  It
cannot be constrained in class 0 an 2 operation to the SG through which the
initial transaction or CR came.

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SS7 congestion control
Date: Fri, 15 Jun 2001 12:18:51 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.59">
<TITLE>RE: SS7 congestion control</TITLE> </HEAD>
<BODY>

<P><FONT SIZE=2>Greetings Jeff,</FONT>
</P>

<P><FONT SIZE=2>Responses below ...</FONT> </P>

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
SIZE=2>From: &nbsp; Zhifeng Tao [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]
</FONT> <BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Thursday, June 14, 2001 5:25
PM</FONT> <BR><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT>
<BR><FONT SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SS7
congestion control</FONT> </P>

<P><FONT SIZE=2>Hi, all</FONT>
</P>

<P><FONT SIZE=2>I¡¯ve got a question about SS7 congestion control</FONT>
<BR><FONT SIZE=2>mechanism.</FONT>
</P>

<P><FONT SIZE=2>¡°The senario is:¡±</FONT> <BR><FONT SIZE=2>1) The network
configuration is the regular STP quad. </FONT> </P>

<P><FONT SIZE=2>2) STP_A/STP_B are on the right hand side and</FONT>
<BR><FONT SIZE=2>STP_C/STP_D on the left hand side.&nbsp; </FONT> <BR><FONT
SIZE=2>3) And all STPs have connection with emulated SSPs by</FONT>
<BR><FONT SIZE=2>using A links.&nbsp; </FONT> <BR><FONT SIZE=2>4)
STP_A/STP_B connect to emulated SSP1, SSP2, etc.</FONT> <BR><FONT SIZE=2>5)
STP_C/STP_D connect to emulated SSP31, SSP32, etc.</FONT> <BR><FONT
SIZE=2>6) SSP1, SSP2, etc initiate UDM (user defined message)</FONT>
<BR><FONT SIZE=2>traffic all toward SSP31.&nbsp; those traffic requires
GTT</FONT> <BR><FONT SIZE=2>at STP_A/STP_B.</FONT> <BR><FONT SIZE=2>7)
STP_C/STP_D detect congestion on the link toward</FONT> <BR><FONT
SIZE=2>SSP31 and send TFC back to STP_A/STP_B.&nbsp; And then</FONT>
<BR><FONT SIZE=2>STP_A/STP_B send UDTS messages to SSP1,SSP2,etc. </FONT>
</P>

<P><FONT SIZE=2>[Greg] Note that UDTSs are only sent if SSP 1,2, .. set the
return on error bit in the original UDT messages.&nbsp; </FONT> </P>

<P><FONT SIZE=2>Since SSP1, SSP2, etc are emulated, they will not
stop</FONT> <BR><FONT SIZE=2>sending out traffic.&nbsp; Therefore,
STP_A/STP_B begin to</FONT> <BR><FONT SIZE=2>discard traffic. </FONT> </P>

<P><FONT SIZE=2>[Greg] STP_A/B MAY begin to discard traffic.&nbsp; It
depends on the message priority of the messages and the congestion level in
the received TFCs.</FONT></P>

<P><FONT SIZE=2>¡°Question:¡±</FONT>
<BR><FONT SIZE=2>According to GR246, only after the discard level</FONT>
<BR><FONT SIZE=2>within STP is exceeded, will STP start to drop</FONT>
<BR><FONT SIZE=2>traffic.&nbsp; </FONT> </P>

<P><FONT SIZE=2>[Greg] There is a difference between what is going on in
STP_A/B and in STP_C/D.&nbsp; At STP_C/D there is output link buffer
congestion to the SSPs (with separate onset/discard levels).&nbsp; STP_C/D
signal TFCs on buffer congestion onset and do not discard right away.&nbsp;
The TFC is to get the sources to control the traffic (Note: with GTT
happening at STP_A/B, the STPs are considered the sources).&nbsp;&nbsp; If
they do not (or cannot) control traffic AND buffer occupancy at STP_C/D
continues to rise then the STPs take matters into their own hands and start
to discard themselves.&nbsp; So you can view the TFC as a warning of
impending discard if no action is taken.</FONT></P>

<P><FONT SIZE=2>Meanwhile, STP_A/STP_B only change its</FONT> <BR><FONT
SIZE=2>congestion level according to the congestion status</FONT> <BR><FONT
SIZE=2>contained in the incoming TFC from STP_C/STP_D.&nbsp; \</FONT> </P>

<P><FONT SIZE=2>[Greg] At STP_A/B there is route/routeset congestion based
on the level from the TFCs.&nbsp; Discard (or SCCP rerouting in some cases)
of lower priority messages starts right away.&nbsp; There is no separate
onset/discard level.</FONT></P>

<P><FONT SIZE=2>Then, how can STP_A/STP_B change the discard level</FONT>
<BR><FONT SIZE=2>regarding the traffic for remote SSP31 and begin to</FONT>
<BR><FONT SIZE=2>drop traffic?</FONT>
</P>

<P><FONT SIZE=2>[Greg] From the TFC congestion level they can start
discarding lower priority traffic right away.</FONT> </P>

<P><FONT SIZE=2>Cheers,</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; Greg Sidebottom</FONT> </P>

<P><FONT SIZE=2>Thanks!</FONT>
</P>

<P><FONT SIZE=2>Jeff</FONT>
</P>
<BR>

<P><FONT SIZE=2>__________________________________________________</FONT>
<BR><FONT SIZE=2>Do You Yahoo!?</FONT>
<BR><FONT SIZE=2>Spot the hottest trends in music, movies, and more.</FONT>
<BR><FONT SIZE=2><A HREF="http://buzz.yahoo.com/"
TARGET="_blank">http://buzz.yahoo.com/</A></FONT> </P>
<BR>

<P><FONT SIZE=2>---</FONT>
<BR><FONT SIZE=2>You are currently subscribed to sigtran as:
[email-masked]</FONT> <BR><FONT SIZE=2>To unsubscribe send a
blank email to [email-masked]</FONT> </P>

---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY>
</HTML>

</x-html>
Date: Sat, 16 Jun 2001 16:27:33 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2UA: Registration messages and procedures
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by 
                      piglet.pigworks.dallas.net id f5GLRXL04365
X-SMTP-HELO: piglet.pigworks.dallas.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-224.dallas.net [209.44.42.224]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

sigtran,

I would like to propose the attached text to be included in the M2UA
specification.  The text is consistent (stolen) from the M3UA specification
and provides the ASP with the ability to control the dynamic registration of
Interface Identifiers in support of the Automatic Allocation of Signalling
Data Terminals and Signalling Data Links as provided for in the Q.704 and
other specifications.

--Brian

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

x.x.x Registration Request (REG REQ)

The REG REQ message is sent by an ASP to indicate to a remote M2UA peer that
it wishes to register one or more given Link Keys with the remote peer.
Typically, an ASP would send this message to an SGP, and expectes to receive
a REG RSP in return with an associated Interface Identifier value.

The REG REQ message contains the following parameters:

     Link Key                Mandatory

The format for the REG REQ message is as follows:

    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 = ??           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                           Link Key 1                          /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                              ...                              /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Tag = ??           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                           Link Key n                          /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Link Key: fixed length

   The Link Key parameter is mandatory.  The sender of this message
   expects the receiver of this message will create a Link Key entry
   and assign a unique Interface Identifier value to it, if the Link
   Key entry does not yet exist.

   The Link Key parameter may be present multiple times in the same
   message.  This is used to allow the registration of multiple Link
   Keys in a single message.

The format of the Link Key  parameter is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Local-LK-Identifier                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Signalling Data Terminal Identifier           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Signalling Data Link Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Local-LK-Identifier: 32-bit integer

   The mandatory Local-LK-Identifier field is used to uniquely
   identify the registration request.  The Identifier value is
   assigned by the ASP, and is used to correlate the response in a
   REG RSP message with the original registration request.  The
   Identifier value must remain unique until the REG RSP is
   received.

   The format of the Local-LK-Identifier field is as follows:

    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 = ??            |         Length = 8            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Local-LK-Identifier value                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Signalling Data Terminal Identifier:

   The Signalling Data Terminal Identifier parameter is mandatory,
   and identifies the Signalling Data Terminal associated with the
   SS7 link for which the ASP is registering.  The format is as
   follows:

    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 = ??            |         Length = 8            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Reserved             |        SDT Identifier         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The SDT Identifier is a 32-bit unsigned value which may only be
   significant to 12 or 14 bits depending on the SS7 variant which
   is supported by the MTP Level 3 at the ASP.  Insignificant SDTI
   bits are coded 0.

Signalling Data Link Identifier:

   The Signalling Data Link Identifier parameter is mandatory, and
   identifies the Siganlling Data Link Identifier associated with
   the SS7 link for which the ASP is registering.  The format is as
   follows:

    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 = ??            |         Length = 8            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Reserved             |        SDL Identifier         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The SDL Identifier is a 32-bit unsigned value which may only be
   significant to 12 or 14 bits depending on the SS7 variant which
   is supported by the MTP Level 3 at the ASP.  Insignificant SDLI
   bits are coded 0.

x.x.x Registration Response (REG RSP)

The REG RSP message is used as a response to the REG REQ message from a
remote M2UA peer.  It contains indications of success/failure for
registration requests and returns a unique Interface Identifier value for
successful registration requests, to be used in subsequent M2UA Traffic
Management protocol.

The REG RSP message contains the following parameters:

     Registration Results   Mandatory

The format for the REG RSP message is as follows:

    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 = ??           |         Length = var.         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Registration Result 1                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                              ...                              /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Registration Result n                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Registration Results:

   The Registration Results parameter contains one or more results,
   each containing the registration status for a single Link Key in
   the REG REQ message.  The number of results in a single REG RSP
   message MAY match the number of Link Key parameters found in the
   corresponding REG REQ message.  The format of each result is as
   follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Local-LK-Identifier value                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Registration Status                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Interface Identifier                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Local-LK-Identifier: 32-bit integer

   The Local-LK-Identifier contains the same value as found in the
   matching Link Key parameter found in the REG Req message.

Registration Status: 32-bit integer

   The Registration Result Status field indicates the success or the
   reason for failure of a registration request.

   Its values may be:

        0           Successfully Registered
	1           Error - Unknown
	2           Error - Invalid SDLI
	3           Error - Invalid SDTI
	4           Error - Invalid Link Key
	5           Error - Permission Denied
	6           Error - Overlapping (Non-unique) Link Key
	7           Error - Link Key not Provisioned
	8           Error - Insufficient Resources

Interface Identifier: 32-bit integer

   The Interface Identifier field contains the Interface Identifier
   for the associated Link Key if the registration is successful.
   It is set to "0" if the registration was not successful.

x.x.x De-Registration Request (DEREG REQ)

The DEREG REQ message is sent by an ASP to indicate to a remote M2UA peer
that it wishes to de-register a given Link Key.  Typically, an ASP would
send this message to an SGP, and expects to receive a DEREG RSP in return
with the associated Interface Identifier value.

The DEREG REQ message contains the following parameters:

     Interface Identifier  Mandatory

The format for the DEREG REQ message is as follows:

    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 = ??           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               /
   \                    Interface Identifier                       \
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Interface Identifier: n X 32-bit integers

   The Interface Identifier parameter contains (a list of) integer
   indexing the Application Server traffic that the sending ASP is
   currently registered to receive from the SG but now wishes to
   deregister.

x.x.x De-Registration Response (DEREG RSP)

The DEREG RSP message is used as a response to the DEREG REQ message from a
remote M2UA peer.

The DEREG RSP message contains the following parameters:

     De-registration Results    Mandatory

The format for the DEREG RSP message is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Interface Identifier                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     De-Registration Status                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Interface Identifier: 32-bit integer

   The Interface Identifier field contains the Interface Identifier
   value of the matching Link Key to deregister, as found in the
   DEREG Req.

De-Registration Status: 32-bit integer

   The De-Registration Result Status field indicates the success or
   the reason for failure of the de-registration.

   Its values may be:
        0           Successfully De-registered
	1           Error - Unknown
	2           Error - Invalid Interface Identifier
	3           Error - Permission Denied
	4           Error - Not Registered

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

x.x.x Link Key Management Procedures

x.x.x.1 Registration

An ASP MAY dynamically register with an SG as an ASP within an Application
Server using the REG REQ message.  A Link Key parameter in the REG REQ
specifies the parameters associated with the Link Key.

The SG examines the contents of the received Link Key parameter and compares
it with the currently provisioned Link Keys.  If the received Link Key
matches an existing SG Link Key entry, and the ASP is not currently included
in the list of ASPs for the related Application Server, the ASP MAY
authorize the ASP to be added to the AS.  Or, if the Link Key does not
currently exist and the received Link Key data is valid and unique, an SG
supporting dynamic configuration MAY authorize the creation of a new Link
Key and related Application Server and add the ASP to the new AS.  In either
case, the SG returns a Registration Response message to the ASP, containing
the same Local-LK-Identifier as provided in the initial request, and a
Registration Result "Successfully Registered".  A unique method of Interface
Identifier valud assignment at the SG/SGP is implementation dependent but
must be guaranteed to be unique across all SGPs in an SG.

If the SG determins that the received Link Key data is invalid, or contains
invalid parameter values, the SG returns a Registration Response message to
the ASP, containing a Registration Result "Error - Invalid Link Key", "Error
- Invalid SDTI", "Error - Invalid SDLI" as appropriate.

If the SG determins that the Link Key parameter overlaps with an existing
Link Key entry, the SG returns a Registration Response message to the ASP,
with a Registration Status of "Error - Overlapping (Non-Unique) Link Key".
An incoming signalling message received at an SG cannot match against more
than one Link Key.

If the SG does not authorize the registration request, the SG returns a REG
RSP message to the ASP containing the Registration Result "Error -
Permission Denied".

If an SG determines that a received Link Key does not currently exist and
the SG does not support dynamic configuration, the SG returns a Registration
Response message to the ASP, containing a Registration Result "Error - Link
Key not Provisioned".

If an SG determines that a received Link Key does not currently exist and
the SG supports dynamic reconfiguration but does not have the capacity to
add new Link Key and Application Server entries, the SG returns a
Registration Response message to the ASP, containing a Registration Result
"Error - Insufficient Resources".

An ASP MAY register multiple Link Keys at once by including a number of Link
Key parameters in a single REG REQ message.  The SG MAY response to each
registration request in a single REG RSP message, indicating the success or
failure result for each Link Key in a separate Registration Result
parameter.  Alternatively the SG MAY response with multiple REG RSP
messages, each with one or more Registration Result parameters.  The ASP
uses the Local-LK-Identifier parameter to correlate the requests with the
responses.

Upon successful registration of an ASP in an AS, the SG can now send related
messaging, if this did not previsouly start upon the ASP transitioning to
"Inactive".

x.x.x.2 Deregistration

An ASP MAY dynamically deregister with an SG as an ASP within an Application
Server using the DEREG REQ message.  A Interface Identifier parameter in the
DEREG REQ specifies which Link Key to de-register.

The SG examines the contents of the received Interface Identifier parameter
and validates that the ASP is currently registered in the Application
Server(s) related to the included Interface Identifier(s).  If validated,
the ASP is de-registered as an ASP in the related Application Server.

The deregistration procedure does not necessarily imply the deletion of Link
Key and Application Server configuration data at the SG.
Other ASPs may continue to be associated with the Application Server, in
which case the Link Key data CANNOT be deleted.  If a Deregistration results
in no more ASPs in an Application Server, an SG MAY delte the Link Key data.

The SG acknowledges the de-registration requres by returning a DEREG RSP to
the requesting ASP.  The result of the de-registration is found in the
Deregistration Result paraemeter, indicating success or faliure with cause.

An ASP MAY deregister multiple Interface Identifiers at once by including a
number of Interface Identifiers in a single DEREG REQ message.  The SG MUST
response to each deregistration request in a single DEREG RSP message,
indicating the success or failure result for each Interface Identifier in a
separate Deregistration Result parameter.

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

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Sun, 17 Jun 2001 13:55:54 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2UA: Missing Primitives
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: piglet.pigworks.dallas.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-244.dallas.net [209.44.42.244]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

I have three primitives from ANSI/ITU specs that are sent between L2 and L3
that I am having a problem finding an M2UA equivalent:

	RB_CLEARED
	RTB_CLEARED
	CLEAR_RTB

RB_CLEARED is an independent indication that is sent whenever the Receive
Buffer is cleared at L2.  RTB_CLEARED is an independent indication that is
sent whenever the Retransmission Buffer is cleared.  CLEAR_RTB is a request
which is sent from L3 to L2 to independently clear only the Retransmission
Buffer.

Can we add a CLEAR_RTB to the Status Request and a RB_CLEARED and
RTB_CLEARED to the Status Indication?

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Sun, 17 Jun 2001 14:09:54 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: Missing Primitives
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-244.dallas.net [209.44.42.244]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

sigtran,

Can I use Retrieve Request ACTION_DROP_MSGS for CLEAR_RTB?  Retrieve Confirm
ACTION_DROP_MSGS for RTB_CLEARED?

But should I use Status Confirm FLUSH_BUFFERS for RB_CLEARED?  The L2 hasn't
necessarily cleared TB or RTB yet...

On Sun, 17 Jun 2001, Brian F. G. Bidulock wrote:

> I have three primitives from ANSI/ITU specs that are sent between
> L2 and L3 that I am having a problem finding an M2UA equivalent:
> 
> 	RB_CLEARED
> 	RTB_CLEARED
> 	CLEAR_RTB
> 
> RB_CLEARED is an independent indication that is sent whenever
> the Receive Buffer is cleared at L2.  RTB_CLEARED is an independent
> indication that is sent whenever the Retransmission Buffer is
> cleared.  CLEAR_RTB is a request which is sent from L3 to L2 to
> independently clear only the Retransmission Buffer.
> 
> Can we add a CLEAR_RTB to the Status Request and a RB_CLEARED
> and RTB_CLEARED to the Status Indication?
> 

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: RE: SUA5: SG Relay Problems
Date: Mon, 18 Jun 2001 10:29:07 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x2.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x2.nokia.com [131.228.20.22]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

> As it appears that a number of significant changes
> have been made to the new draft, I eagerly await
> the opportunity to review it.
> 
> When can we expect to see it?

I sent it out on Friday, so hopefully it should come out today.
I will try to send a note later about the changes.

thanks,
John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Mon, 18 Jun 2001 07:01:52 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA 08: redundancy
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Done.

At 06:32 PM 6/14/01 -0500, you wrote:
>Section 1.3.4
>
>"where 1 ASP is the minimum number of redundant ASPs"
>
>should read
>
>"where n is the minimum number of redundant ASPs"
>
>-- 
>Brian F. G. Bidulock
>[email-masked]
>http://www.openss7.org/
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
To: "sigtran" <[email-masked]>
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sigtran-sua-06.txt
Date: Mon, 18 Jun 2001 07:16:11 -0400
Sender: [email-masked]
X-SMTP-HELO: ietf.org
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [132.151.1.176]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Signaling Transport Working Group of the
IETF.

	Title		: SS7 SCCP-User Adaptation Layer (SUA)
	Author(s)	: J. Loughney, G. Sidebottom, G. Mousseau,
                          S. Lorusso, L. Coede, G. Verwimp, 
                          J. Keller, F. Escobar, W. Sully, S. Furniss
	Filename	: draft-ietf-sigtran-sua-06.txt
	Pages		: 81
	Date		: 15-Jun-01
	
This Internet Draft defines a protocol for the transport of any SS7
SCCP-User signaling (e.g., TCAP, RANAP, etc.) over IP using the Stream
Control Transport Protocol.  The protocol should be modular and symmetric,
to allow it to work in diverse architectures, such as a Signaling Gateway to
IP Signaling Endpoint architecture as well as a peer-to-peer IP Signaling
Endpoint architecture.  Protocol elements are added to allow seamless
operation between peers in the SS7 and IP domains.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sua-06.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in, type
"cd internet-drafts" and then
	"get draft-ietf-sigtran-sua-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sigtran-sua-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sigtran-sua-06.txt

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-sigtran-sua-06.txt> ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Mon, 18 Jun 2001 07:18:37 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA 08: Congestion Indication
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Done.

At 10:59 PM 6/14/01 -0500, you wrote:
>Jacob,
>
>The only problem I have with that is that there exists
>MTP2 implementations and SG implementations which
>cannot generate the indication, so the "shall" is
>not called for in the text.
>
>If the ASP M2UA is to convert this into some
>indication that MTP3 understands, it is also possible
>for the SG M2UA to do so as well and there is no need
>to transfer this indication across the M2UA.
>
>It is possible (and advisable) to design an MTP2
>implementation so that it never encounters this
>situation.
>
>Level 1 2 and 3 congestion is not signalled by MTP2
>because it is running out of buffers.  They are signalled
>because the link is becoming congested.  Once level 3
>discard has been indicated by MTP2, MTP3 should only
>be delivering MTP/SCCP management messages which should
>not in themselves push an MTP2 implementation out of
>buffer space even once level 3 link congestion has
>been experienced.
>
>Because the ASP M2UA cannot know all of the specifics
>about buffer space on an MTP2 implementation, it is
>also not in a good position to determine the MTP3
>primitive onto which to map this indication.  The
>SG implementation is in a far better position to
>make this determination and has all of the M2UA
>messages necessary at its disposal without this
>indication.
>
>It don't believe that it is necessary to have an
>ASP M2UA implementation attempt to compensate for
>the design deficiencies of an SG or even the design
>deficiencies of an MTP2 implementation.
>
>I have absolutely no use for it.  Please at least
>remove the "shall".
>
>
>Jacob Heitz wrote:               (Thu, 14 Jun 2001 20:06:58)
> >
> > I think LEVEL_DISCARDING should be the same as LEVEL_4.
> > At LEVEL_3, it is not discarding, just indicating the
> > highest level of congestion consistent with the MTP specs.
> > The MTP specs have no value for indicating that MTP2
> > is discarding MSUs from MTP3, because when MTP3 and
> > MTP2 are colocated, it shouldn't happen. If M2UA runs
> > out of memory to store received MSUs received from the
> > ASP, an option might be to simply stop reading them
> > from the SCTP stream. Then SCTP would eventually close
> > the window and the ASP would stop sending. This has two
> > disadvantages. One, it will stop all other streams in
> > the same association from flowing and two, it will prevent
> > the SG from receiving possibly important M2UA control
> > messages, such as STATUS_FLUSH_BUFFERS. An alternative
> > is to send LEVEL_4. Response of ASP is implementation
> > dependent. It could be processor outage or whatever
> > you choose. 
> > 
> > Another way to solve the same problem might
> > be with your correlation ID: don't ack it. We don't
> > have your text for this yet though. Let's see it:
> > you never know, we might finally be able to agree on 
> > something.
> > 
> > 
> > "Brian F. G. Bidulock" wrote:
> > > 
> > > Section 3.3.1.7 has a congestion status and discard value
> > > in the list named LEVEL_4.  The text refers to a LEVEL_DISCARDING
> > > which is not in the list.  The text indicates that a variant
> > > not supporting multiple congestion levels (or states) "will"
> > > use LEVEL_NONE and LEVEL_3.  The text requires that the SG "shall"
> > > send LEVEL_DISCARDING when it runs out of buffers and begins
> > > discarding MSUs, even though it seems that the SG will have
> > > already sent "LEVEL_3" congestion status and "LEVEL_3" discard
> > > status which indicates the same thing.  It is not clear to me
> > > what the ASP M2UA is supposed to do with the LEVEL_DISCARDING
> > > indication.  What is it supposed to do?  (Its response to
> > > the other levels are clear from the MTP specs, but what about
> > > LEVEL_DISCARDING?  And what is LEVEL_4?  How are they different
> > > from congestion status LEVEL_3 and discard status LEVEL_3?
> > 
> > 
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to
[email-masked]
>
>-- 
>Brian F. G. Bidulock
>[email-masked]
>http://www.openss7.org/
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Mon, 18 Jun 2001 07:49:00 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA 08: Notify
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [161.44.85.169]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

Unfortunately, no one has responded to the previous email you posted
regarding this change to M2UA and M3UA.  It would be ideal to have some
discussion before making this change.

All - Please review Brian's suggestion and send in comments.

Regards,

Ken

At 09:51 PM 6/14/01 -0500, you wrote:
>Section 3.3.3.2
>
>Add the status information value
>
>         "Insufficient ASP resources pending in AS"
>
>per previous proposal to indicate to the AS that
>the number of active ASPs in an n+k arrangement
>has fallen to n from n+1.  Providing notification
>when falling from n to n-1 is a little late for
>the Broadcast case, particularly should ASPs become
>partitioned.
>
>
>-- 
>Brian F. G. Bidulock
>[email-masked]
>http://www.openss7.org/
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Mon, 18 Jun 2001 08:00:40 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA 08: Retrieval Request
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

This Status Req and Retrieval Req text is cleaned up per your
recommendations.

Ken

At 09:21 PM 6/14/01 -0500, you wrote:
>Section 3.3.1.8
>
>The changes which were made to retrieval request are not
>consistent with the common descriptions of M2UA from Q.703
>and Q.2140/Q.2110.  These specs do not provide a mechanism
>for retrieving as described in ACTION_RTRV_MSGS and
>ACTION_RTRV_TRANS.  Both Q.703 and Q.2140/2110 described
>signalling links only support the retrieval of BOTH the
>messages in the retransmit and transmit buffers.
>
>If CLEAR_RTB is added to the states (as per previous mail)
>consistent with the flush_buffers primitive, these three
>can be reduced to a set which is consistent with the cited
>and referenced recommendations.
>
>Remove ACTION_DROP_MSGS and ACTION_RTRV_TRANS, describe
>ACTION_RTRV_MSGS as retrieving both RTB and TB contents,
>and add STATUS_CLEAR_RTB to the status messages.  This
>will make M2UA consistent with Q.703/Q.2140/Q.2110 as
>well as T1.111.3.
>
>-- 
>Brian F. G. Bidulock
>[email-masked]
>http://www.openss7.org/
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Mon, 18 Jun 2001 08:09:13 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA 08: Retrieval Confirm
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

See comments below.

Regards,

Ken

At 09:37 PM 6/14/01 -0500, you wrote:
>Section 3.3.1.9
>
>Per Q.703 and Q.2140/2110 there is no way to
>distinguish between messages retrieved from the
>TB and messages retrieved from the RTB.  The
>distinction should not be made in M2UA because
>SGs exist which will lack support for the
>distinction.

there was no intent to imply that M2UA "knows" retransmit versus transmit
queue.  I will remove the "from retransmit or transmit queue" text.

>There is no reason to distinguish between
>TTC retrieved messages here.  Whether the
>retrieved message is TTC or not is implicit
>in the interface identifier from which the
>messages are being retrieved.  The distinction
>is only necessary over channels which may mix
>both TTC and non-TTC messages.
>
>(Actually, I don't see what you need a TTC
>type for in the first place.)

After much discussion on the list and at the San Diego meeting, there was
agreement to create a separate TTC type for M2UA and M3UA.  

>-- 
>Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
>[email-masked]    ¦ world; the unreasonable one persists in  ¦
>http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Mon, 18 Jun 2001 08:51:11 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA: Missing Primitives
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

Per your previous suggestion, ACTION_DROP_MSGS was removed and CLEAR_RTB
added.  I've only looked at the ITU specs so far, but I cannot find the
RB_CLEARED and RTB_CLEARED indications.  Can you provide a reference.
Further, what does MTP3 do with these indications?

Regards,

Ken

At 02:09 PM 6/17/01 -0500, you wrote:
>sigtran,
>
>Can I use Retrieve Request ACTION_DROP_MSGS for CLEAR_RTB?  Retrieve
>Confirm ACTION_DROP_MSGS for RTB_CLEARED?
>
>But should I use Status Confirm FLUSH_BUFFERS for RB_CLEARED?  The
>L2 hasn't necessarily cleared TB or RTB yet...
>
>
>On Sun, 17 Jun 2001, Brian F. G. Bidulock wrote:
>
> > I have three primitives from ANSI/ITU specs that are sent between
> > L2 and L3 that I am having a problem finding an M2UA equivalent:
> > 
> >       RB_CLEARED
> >       RTB_CLEARED
> >       CLEAR_RTB
> > 
> > RB_CLEARED is an independent indication that is sent whenever
> > the Receive Buffer is cleared at L2.  RTB_CLEARED is an independent
> > indication that is sent whenever the Retransmission Buffer is
> > cleared.  CLEAR_RTB is a request which is sent from L3 to L2 to
> > independently clear only the Retransmission Buffer.
> > 
> > Can we add a CLEAR_RTB to the Status Request and a RB_CLEARED
> > and RTB_CLEARED to the Status Indication?
> > 
>
>-- 
>Brian F. G. Bidulock
>[email-masked]
>http://www.openss7.org/
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Mon, 18 Jun 2001 08:59:18 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA: Registration messages and procedures
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

I don't see a need for dynamic provisioning of this type for M2UA.  An
network or element management system would suffice.

Regards,

Ken

At 04:27 PM 6/16/01 -0500, you wrote:
>sigtran,
>
>I would like to propose the attached text to be included
>in the M2UA specification.  The text is consistent (stolen)
>from the M3UA specification and provides the ASP with the
>ability to control the dynamic registration of Interface
>Identifiers in support of the Automatic Allocation of
>Signalling Data Terminals and Signalling Data Links as
>provided for in the Q.704 and other specifications.
>
>--Brian
>
>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
>x.x.x Registration Request (REG REQ)
>
>The REG REQ message is sent by an ASP to indicate to a remote M2UA
>peer that it wishes to register one or more given Link Keys with the
>remote peer.  Typically, an ASP would send this message to an SGP,
>and expectes to receive a REG RSP in return with an associated
>Interface Identifier value.
>
>The REG REQ message contains the following parameters:
>
>      Link Key                Mandatory
>
>The format for the REG REQ message is as follows:
>
>     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 = ??           |            Length             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    \                                                               \
>    /                           Link Key 1                          /
>    \                                                               \
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    \                                                               \
>    /                              ...                              /
>    \                                                               \
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |            Tag = ??           |            Length             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    \                                                               \
>    /                           Link Key n                          /
>    \                                                               \
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>Link Key: fixed length
>
>    The Link Key parameter is mandatory.  The sender of this message
>    expects the receiver of this message will create a Link Key entry
>    and assign a unique Interface Identifier value to it, if the Link
>    Key entry does not yet exist.
>
>    The Link Key parameter may be present multiple times in the same
>    message.  This is used to allow the registration of multiple Link
>    Keys in a single message.
>
>The format of the Link Key  parameter is as follows:
>
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                       Local-LK-Identifier                     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                 Signalling Data Terminal Identifier           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                   Signalling Data Link Identifier             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>Local-LK-Identifier: 32-bit integer
>
>    The mandatory Local-LK-Identifier field is used to uniquely
>    identify the registration request.  The Identifier value is
>    assigned by the ASP, and is used to correlate the response in a
>    REG RSP message with the original registration request.  The
>    Identifier value must remain unique until the REG RSP is
>    received.
>
>    The format of the Local-LK-Identifier field is as follows:
>
>     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 = ??            |         Length = 8            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                    Local-LK-Identifier value                  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>Signalling Data Terminal Identifier:
>
>    The Signalling Data Terminal Identifier parameter is mandatory,
>    and identifies the Signalling Data Terminal associated with the
>    SS7 link for which the ASP is registering.  The format is as
>    follows:
>
>     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 = ??            |         Length = 8            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          Reserved             |        SDT Identifier         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    The SDT Identifier is a 32-bit unsigned value which may only be
>    significant to 12 or 14 bits depending on the SS7 variant which
>    is supported by the MTP Level 3 at the ASP.  Insignificant SDTI
>    bits are coded 0.
>
>Signalling Data Link Identifier:
>
>    The Signalling Data Link Identifier parameter is mandatory, and
>    identifies the Siganlling Data Link Identifier associated with
>    the SS7 link for which the ASP is registering.  The format is as
>    follows:
>
>     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 = ??            |         Length = 8            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          Reserved             |        SDL Identifier         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    The SDL Identifier is a 32-bit unsigned value which may only be
>    significant to 12 or 14 bits depending on the SS7 variant which
>    is supported by the MTP Level 3 at the ASP.  Insignificant SDLI
>    bits are coded 0.
>
>x.x.x Registration Response (REG RSP)
>
>The REG RSP message is used as a response to the REG REQ message
>from a remote M2UA peer.  It contains indications of success/failure
>for registration requests and returns a unique Interface Identifier
>value for successful registration requests, to be used in subsequent
>M2UA Traffic Management protocol.
>
>The REG RSP message contains the following parameters:
>
>      Registration Results   Mandatory
>
>The format for the REG RSP message is as follows:
>
>     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 = ??           |         Length = var.         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                    Registration Result 1                      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    /                              ...                              /
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                    Registration Result n                      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>Registration Results:
>
>    The Registration Results parameter contains one or more results,
>    each containing the registration status for a single Link Key in
>    the REG REQ message.  The number of results in a single REG RSP
>    message MAY match the number of Link Key parameters found in the
>    corresponding REG REQ message.  The format of each result is as
>    follows:
>
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                  Local-LK-Identifier value                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                      Registration Status                      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                      Interface Identifier                     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>Local-LK-Identifier: 32-bit integer
>
>    The Local-LK-Identifier contains the same value as found in the
>    matching Link Key parameter found in the REG Req message.
>
>Registration Status: 32-bit integer
>
>    The Registration Result Status field indicates the success or the
>    reason for failure of a registration request.
>
>    Its values may be:
>
>         0           Successfully Registered
>         1           Error - Unknown
>         2           Error - Invalid SDLI
>         3           Error - Invalid SDTI
>         4           Error - Invalid Link Key
>         5           Error - Permission Denied
>         6           Error - Overlapping (Non-unique) Link Key
>         7           Error - Link Key not Provisioned
>         8           Error - Insufficient Resources
>
>Interface Identifier: 32-bit integer
>
>    The Interface Identifier field contains the Interface Identifier
>    for the associated Link Key if the registration is successful.
>    It is set to "0" if the registration was not successful.
>
>x.x.x De-Registration Request (DEREG REQ)
>
>The DEREG REQ message is sent by an ASP to indicate to a remote M2UA
>peer that it wishes to de-register a given Link Key.  Typically, an
>ASP would send this message to an SGP, and expects to receive a
>DEREG RSP in return with the associated Interface Identifier value.
>
>The DEREG REQ message contains the following parameters:
>
>      Interface Identifier  Mandatory
>
>The format for the DEREG REQ message is as follows:
>
>     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 = ??           |            Length             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    /                                                               /
>    \                    Interface Identifier                       \
>    /                                                               /
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>Interface Identifier: n X 32-bit integers
>
>    The Interface Identifier parameter contains (a list of) integer
>    indexing the Application Server traffic that the sending ASP is
>    currently registered to receive from the SG but now wishes to
>    deregister.
>
>x.x.x De-Registration Response (DEREG RSP)
>
>The DEREG RSP message is used as a response to the DEREG REQ message
>from a remote M2UA peer.
>
>The DEREG RSP message contains the following parameters:
>
>      De-registration Results    Mandatory
>
>The format for the DEREG RSP message is as follows:
>
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                      Interface Identifier                     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                     De-Registration Status                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>Interface Identifier: 32-bit integer
>
>    The Interface Identifier field contains the Interface Identifier
>    value of the matching Link Key to deregister, as found in the
>    DEREG Req.
>
>De-Registration Status: 32-bit integer
>
>    The De-Registration Result Status field indicates the success or
>    the reason for failure of the de-registration.
>
>    Its values may be:
>         0           Successfully De-registered
>         1           Error - Unknown
>         2           Error - Invalid Interface Identifier
>         3           Error - Permission Denied
>         4           Error - Not Registered
>
>
>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
>x.x.x Link Key Management Procedures
>
>x.x.x.1 Registration
>
>An ASP MAY dynamically register with an SG as an ASP within an
>Application Server using the REG REQ message.  A Link Key parameter
>in the REG REQ specifies the parameters associated with the Link
>Key.
>
>The SG examines the contents of the received Link Key parameter and
>compares it with the currently provisioned Link Keys.  If the
>received Link Key matches an existing SG Link Key entry, and the ASP
>is not currently included in the list of ASPs for the related
>Application Server, the ASP MAY authorize the ASP to be added to the
>AS.  Or, if the Link Key does not currently exist and the received
>Link Key data is valid and unique, an SG supporting dynamic
>configuration MAY authorize the creation of a new Link Key and
>related Application Server and add the ASP to the new AS.  In either
>case, the SG returns a Registration Response message to the ASP,
>containing the same Local-LK-Identifier as provided in the initial
>request, and a Registration Result "Successfully Registered".  A
>unique method of Interface Identifier valud assignment at the SG/SGP
>is implementation dependent but must be guaranteed to be unique
>across all SGPs in an SG.
>
>If the SG determins that the received Link Key data is invalid, or
>contains invalid parameter values, the SG returns a Registration
>Response message to the ASP, containing a Registration Result "Error
>- Invalid Link Key", "Error - Invalid SDTI", "Error - Invalid SDLI"
>as appropriate.
>
>If the SG determins that the Link Key parameter overlaps with an
>existing Link Key entry, the SG returns a Registration Response
>message to the ASP, with a Registration Status of "Error -
>Overlapping (Non-Unique) Link Key".  An incoming signalling message
>received at an SG cannot match against more than one Link Key.
>
>If the SG does not authorize the registration request, the SG
>returns a REG RSP message to the ASP containing the Registration
>Result "Error - Permission Denied".
>
>If an SG determines that a received Link Key does not currently
>exist and the SG does not support dynamic configuration, the SG
>returns a Registration Response message to the ASP, containing a
>Registration Result "Error - Link Key not Provisioned".
>
>If an SG determines that a received Link Key does not currently
>exist and the SG supports dynamic reconfiguration but does not have
>the capacity to add new Link Key and Application Server entries, the
>SG returns a Registration Response message to the ASP, containing a
>Registration Result "Error - Insufficient Resources".
>
>An ASP MAY register multiple Link Keys at once by including a number
>of Link Key parameters in a single REG REQ message.  The SG MAY
>response to each registration request in a single REG RSP message,
>indicating the success or failure result for each Link Key in a
>separate Registration Result parameter.  Alternatively the SG MAY
>response with multiple REG RSP messages, each with one or more
>Registration Result parameters.  The ASP uses the Local-LK-Identifier
>parameter to correlate the requests with the responses.
>
>Upon successful registration of an ASP in an AS, the SG can now send
>related messaging, if this did not previsouly start upon the ASP
>transitioning to "Inactive".
>
>x.x.x.2 Deregistration
>
>An ASP MAY dynamically deregister with an SG as an ASP within an
>Application Server using the DEREG REQ message.  A Interface
>Identifier parameter in the DEREG REQ specifies which Link Key to
>de-register.
>
>The SG examines the contents of the received Interface Identifier
>parameter and validates that the ASP is currently registered in the
>Application Server(s) related to the included Interface
>Identifier(s).  If validated, the ASP is de-registered as an ASP in
>the related Application Server.
>
>The deregistration procedure does not necessarily imply the deletion
>of Link Key and Application Server configuration data at the SG.
>Other ASPs may continue to be associated with the Application
>Server, in which case the Link Key data CANNOT be deleted.  If a
>Deregistration results in no more ASPs in an Application Server, an
>SG MAY delte the Link Key data.
>
>The SG acknowledges the de-registration requres by returning a DEREG
>RSP to the requesting ASP.  The result of the de-registration is
>found in the Deregistration Result paraemeter, indicating success or
>faliure with cause.
>
>An ASP MAY deregister multiple Interface Identifiers at once by
>including a number of Interface Identifiers in a single DEREG REQ
>message.  The SG MUST response to each deregistration request in a
>single DEREG RSP message, indicating the success or failure result
>for each Interface Identifier in a separate Deregistration Result
>parameter.
>
>
>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
>
>
>-- 
>Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
>[email-masked]    ¦ world; the unreasonable one persists in  ¦
>http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Gradischnig, Klaus" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M2UA 08: Retrieval Request
Date: Mon, 18 Jun 2001 09:00:17 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: chi02.npac.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: inetgw.il.neustar.com [209.173.57.225]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Just a small clarification:

MTP does provide the ability to only retrieve the transmission buffer:

Q.704, 5.6.1 states:
"...Instead, it directly starts sending the signalling traffic not yet
transmitted
                       ^^^^^^^^^^^^^^^^^^^ on the unavailable link on the
alternative signalling link(s)"

Q.2240, 6.1.2, is even more explicit:

"For cases in which an FSNC value is not obtained from MTP-3, the RN
parameter can convey a value of "unknown", and SSCOP returns only those
message units that have not yet been transmitted."

Klaus

> -----Original Message-----
> From: Ken Morneault [mailto:[email-masked]]
> Sent: June 18, 2001 8:01 AM
> To: sigtran
> Subject: Re: M2UA 08: Retrieval Request
> 
> 
> 
> 
> Brian,
> 
> This Status Req and Retrieval Req text is cleaned up per
> your recommendations.
> 
> Ken
> 
> At 09:21 PM 6/14/01 -0500, you wrote:
> >Section 3.3.1.8
> >
> >The changes which were made to retrieval request are not
> >consistent with the common descriptions of M2UA from Q.703
> >and Q.2140/Q.2110.  These specs do not provide a mechanism
> >for retrieving as described in ACTION_RTRV_MSGS and
> >ACTION_RTRV_TRANS.  Both Q.703 and Q.2140/2110 described
> >signalling links only support the retrieval of BOTH the
> >messages in the retransmit and transmit buffers.
> >
> >If CLEAR_RTB is added to the states (as per previous mail)
> >consistent with the flush_buffers primitive, these three
> >can be reduced to a set which is consistent with the cited
> >and referenced recommendations.
> >
> >Remove ACTION_DROP_MSGS and ACTION_RTRV_TRANS, describe
> >ACTION_RTRV_MSGS as retrieving both RTB and TB contents,
> >and add STATUS_CLEAR_RTB to the status messages.  This
> >will make M2UA consistent with Q.703/Q.2140/Q.2110 as
> >well as T1.111.3.
> >
> >-- 
> >Brian F. G. Bidulock
> >[email-masked]
> >http://www.openss7.org/
> >
> >
> >---
> >You are currently subscribed to sigtran as: [email-masked]
> >To unsubscribe send a blank email to 
> [email-masked] 
> 
> 
> 
> ---
> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Mon, 18 Jun 2001 10:09:28 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA 08: ASPM procedures
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

Yes, this text needs to be changed.  How about:

"At the ASP, the M2UA layer will take action based on the appropriate MTP
specification.  The ASP may indicate to another ASP that it should become
active.  However, the ASP to ASP communication is out of the scope of this
document."

Ken

At 10:00 PM 6/14/01 -0500, you wrote:
>Section 4.3.2
>
>         "... Athe [sic] ASP, M2UA shall either cause
>         other ASPs to become active or send link-out-
>         of-service primitives to MTP3."
>
>Just how was M2UA at the ASP going to cause other ASPs
>to become active?  Also, what indications are sent to
>MTP3 is certainly up to the ASP implementor and does
>not impact interoperability with any SG implementation,
>per previous discussion pertaining to SG actions towards
>MTP2.
>
>-- 
>Brian F. G. Bidulock
>[email-masked]
>http://www.openss7.org/
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 18 Jun 2001 16:23:28 +0200
From: Maria_Cruz_Bartolome_Rodrigo +34913393208 
      <[email-masked]>
Subject: M3UA: DRST message
Sender: [email-masked]
To: "sigtran" <[email-masked]>
Organization: EEM/TD/LNA
X-Mailer: Mozilla 4.73C-EEM/TD [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
X-SMTP-HELO: penguin-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: penguin-ext.wise.edt.ericsson.se [194.237.142.110]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi all,

There is something unclear in the 3.4.6 chapter (Destination Restricted -
DRST), see in caps:

------------------------------------------------------------------------
"The DRST message is optionally sent from the SG to all concerned ASPs 
to indicate that the SG has determined that one or more SS7 destinations are
now restricted, or in response to a DAUD message if 
appropriate. The M3UA at the ASP is expected to send traffic to the 
affected destination via an alternate SG of equal priority, but only if 
such an alternate route exists and is available. IF THE AFFECTED DESTINATION
IS CURRENTLY CONSIDERED UNAVAILABLE BY THE ASP, TRAFFIC TO 
THE AFFECTED DESTINATION THROUGH THE SG INITIATING THE DRST SHOULD BE
RESUMED.
THIS MESSAGE IS OPTIONAL FOR THE SG TO SEND AND OPTIONAL FOR THE ASP TO
PROCESS. It is for use in the "STP" case described in Section 1.4.2."
------------------------------------------------------------------------

If the affected destinations (those restricted, I presumed) are considered
unavailable by the ASP, then traffic can't be resumed neither
through the SG initiating the DRST nor the alternate SG. Don't you think
in this particular case, the DRST msg should be ignored by the ASP?

Apart from that, this message can NOT be optional for the ASP to process,
at least the ASP should be able to read and discard it, don't you agree?
Otherwise, interoperability will be impossible.

Thanks
/M.Cruz

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Gradischnig, Klaus" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA: DRST message
Date: Mon, 18 Jun 2001 09:31:52 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: chi02.npac.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.173.57.225]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Maria,

receiving a TFR for a prohibited destination implicitly cancels the
prohibited status. If a destination were still prohibited, no TFR message
would be sent for it. The analog applies to DRST messages.

Klaus

> -----Original Message-----
> From: Maria_Cruz_Bartolome_Rodrigo +34913393208
> [mailto:[email-masked]]
> Sent: June 18, 2001 10:23 AM
> To: sigtran
> Subject: M3UA: DRST message
> 
> 
> 
> Hi all,
> 
> There is something unclear in the 3.4.6 chapter (Destination
> Restricted - DRST), see in caps:
> 
> --------------------------------------------------------------
> ----------
> "The DRST message is optionally sent from the SG to all concerned
> ASPs 
> to indicate that the SG has determined that one or more SS7 
> destinations are now restricted, or in response to a DAUD message
> if 
> appropriate. The M3UA at the ASP is expected to send traffic to
> the 
> affected destination via an alternate SG of equal priority, but
> only if 
> such an alternate route exists and is available. IF THE AFFECTED
> DESTINATION IS CURRENTLY CONSIDERED UNAVAILABLE BY THE ASP,
> TRAFFIC TO 
> THE AFFECTED DESTINATION THROUGH THE SG INITIATING THE DRST SHOULD
> BE
> RESUMED.
> THIS MESSAGE IS OPTIONAL FOR THE SG TO SEND AND OPTIONAL FOR THE
> ASP TO
> PROCESS. It is for use in the "STP" case described in Section
> 1.4.2."
> --------------------------------------------------------------
> ----------
> 
> If the affected destinations (those restricted, I presumed) are 
> considered unavailable by the ASP, then traffic can't be resumed
> neither
> through the SG initiating the DRST nor the alternate SG. Don't you
> think
> in this particular case, the DRST msg should be ignored by the
> ASP?
> 
> Apart from that, this message can NOT be optional for the ASP to
> process,
> at least the ASP should be able to read and discard it, don't you
> agree?
> Otherwise, interoperability will be impossible.
> 
> Thanks
> /M.Cruz
> 
> 
> ---
> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA: DRST message
Date: Mon, 18 Jun 2001 10:44:56 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.59">
<TITLE>RE: M3UA: DRST message</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi Maria ...</FONT>
</P>

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
SIZE=2>From: &nbsp; Maria_Cruz_Bartolome_Rodrigo +34913393208 [<A
HREF="mailto:[email-masked]">mailto:maria-cruz
[email-masked]</A>] </FONT> <BR><FONT
SIZE=2>Sent:&nbsp;&nbsp; Monday, June 18, 2001 10:23 AM</FONT> <BR><FONT
SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT> <BR><FONT
SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; M3UA: DRST
message</FONT> </P>
<BR>

<P><FONT SIZE=2>Hi all,</FONT>
</P>

<P><FONT SIZE=2>There is something unclear in the 3.4.6 chapter
(Destination</FONT> <BR><FONT SIZE=2>Restricted - DRST), see in caps:</FONT>
</P>

<P><FONT
SIZE=2>---------------------------------------------------------------------
---</FONT> <BR><FONT SIZE=2>&quot;The DRST message is optionally sent from
the SG to all concerned</FONT> <BR><FONT SIZE=2>ASPs </FONT>
<BR><FONT SIZE=2>to indicate that the SG has determined that one or more SS7
</FONT> <BR><FONT SIZE=2>destinations are now restricted, or in response to
a DAUD message</FONT> <BR><FONT SIZE=2>if </FONT>
<BR><FONT SIZE=2>appropriate. The M3UA at the ASP is expected to send
traffic to</FONT> <BR><FONT SIZE=2>the </FONT>
<BR><FONT SIZE=2>affected destination via an alternate SG of equal priority,
but</FONT> <BR><FONT SIZE=2>only if </FONT>
<BR><FONT SIZE=2>such an alternate route exists and is available. IF THE
AFFECTED</FONT> <BR><FONT SIZE=2>DESTINATION IS CURRENTLY CONSIDERED
UNAVAILABLE BY THE ASP,</FONT> <BR><FONT SIZE=2>TRAFFIC TO </FONT>
<BR><FONT SIZE=2>THE AFFECTED DESTINATION THROUGH THE SG INITIATING THE DRST
SHOULD</FONT> <BR><FONT SIZE=2>BE</FONT>
<BR><FONT SIZE=2>RESUMED.</FONT>
<BR><FONT SIZE=2>THIS MESSAGE IS OPTIONAL FOR THE SG TO SEND AND OPTIONAL
FOR THE</FONT> <BR><FONT SIZE=2>ASP TO</FONT>
<BR><FONT SIZE=2>PROCESS. It is for use in the &quot;STP&quot; case
described in Section</FONT> <BR><FONT SIZE=2>1.4.2.&quot;</FONT>
<BR><FONT
SIZE=2>---------------------------------------------------------------------
---</FONT> </P>

<P><FONT SIZE=2>If the affected destinations (those restricted, I presumed)
are </FONT> <BR><FONT SIZE=2>considered unavailable by the ASP, then traffic
can't be resumed</FONT> <BR><FONT SIZE=2>neither</FONT>
<BR><FONT SIZE=2>through the SG initiating the DRST nor the alternate SG.
Don't you</FONT> <BR><FONT SIZE=2>think</FONT>
<BR><FONT SIZE=2>in this particular case, the DRST msg should be ignored by
the</FONT> <BR><FONT SIZE=2>ASP?</FONT>
</P>

<P><FONT SIZE=2>[Greg] Klaus answered this one better than I could.</FONT>
</P>

<P><FONT SIZE=2>Apart from that, this message can NOT be optional for the
ASP to</FONT> <BR><FONT SIZE=2>process,</FONT>
<BR><FONT SIZE=2>at least the ASP should be able to read and discard it,
don't you</FONT> <BR><FONT SIZE=2>agree?</FONT>
<BR><FONT SIZE=2>Otherwise, interoperability will be impossible.</FONT> </P>

<P><FONT SIZE=2>[Greg] I agree - this was not the intent of the current
wording. How about &quot; ... and optional for the ASP to act on.&nbsp;
?</FONT> </P>

<P><FONT SIZE=2>Cheers,</FONT>
</P>

<P><FONT SIZE=2>&nbsp; Greg Sidebottom</FONT> </P>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>Thanks</FONT>
<BR><FONT SIZE=2>/M.Cruz</FONT>
</P>
<BR>
<BR>

---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY>
</HTML>

</x-html>
Date: Mon, 18 Jun 2001 16:59:49 +0200
From: Maria_Cruz_Bartolome_Rodrigo +34913393208 
      <[email-masked]>
Subject: Re: M3UA: DRST message
Sender: [email-masked]
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Organization: EEM/TD/LNA
X-Mailer: Mozilla 4.73C-EEM/TD [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
X-SMTP-HELO: albatross-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: albatross-ext.wise.edt.ericsson.se [194.237.142.116]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Greg and Klaus,

Right now I got the point, thanks for the fast answers.

However, that sentence may not be clear enough, what about:

... If the affected destinations are ALREADY considered RESTRICTED by the
ASP...

Cheers
/MCruz

"Gradischnig, Klaus" wrote:
> 
> Maria,
> 
> receiving a TFR for a prohibited destination implicitly cancels the
> prohibited status. If a destination were still prohibited, no TFR message
> would be sent for it. The analog applies to DRST messages.
> 
> Klaus
> 
> > -----Original Message-----
> > From: Maria_Cruz_Bartolome_Rodrigo +34913393208
> > [mailto:[email-masked]]
> > Sent: June 18, 2001 10:23 AM
> > To: sigtran
> > Subject: M3UA: DRST message
> >
> >
> >
> > Hi all,
> >
> > There is something unclear in the 3.4.6 chapter (Destination
> > Restricted - DRST), see in caps:
> >
> > --------------------------------------------------------------
> > ----------
> > "The DRST message is optionally sent from the SG to all concerned
> > ASPs
> > to indicate that the SG has determined that one or more SS7
> > destinations are now restricted, or in response to a DAUD message
> > if
> > appropriate. The M3UA at the ASP is expected to send traffic to
> > the
> > affected destination via an alternate SG of equal priority, but
> > only if
> > such an alternate route exists and is available. IF THE AFFECTED
> > DESTINATION IS CURRENTLY CONSIDERED UNAVAILABLE BY THE ASP,
> > TRAFFIC TO
> > THE AFFECTED DESTINATION THROUGH THE SG INITIATING THE DRST SHOULD
> > BE
> > RESUMED.
> > THIS MESSAGE IS OPTIONAL FOR THE SG TO SEND AND OPTIONAL FOR THE
> > ASP TO
> > PROCESS. It is for use in the "STP" case described in Section
> > 1.4.2."
> > --------------------------------------------------------------
> > ----------
> >
> > If the affected destinations (those restricted, I presumed) are
> > considered unavailable by the ASP, then traffic can't be resumed
> > neither
> > through the SG initiating the DRST nor the alternate SG. Don't you
> > think
> > in this particular case, the DRST msg should be ignored by the
> > ASP?
> >
> > Apart from that, this message can NOT be optional for the ASP to
> > process,
> > at least the ASP should be able to read and discard it, don't you
> > agree?
> > Otherwise, interoperability will be impossible.
> >
> > Thanks
> > /M.Cruz
> >
> >
> > ---
> > You are currently subscribed to sigtran as:
> > [email-masked]
> > To unsubscribe send a blank email to
> > [email-masked]
> >
> 
> ---
> You are currently subscribed to sigtran as:
[email-masked]
> To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 18 Jun 2001 16:59:49 +0200
From: Maria_Cruz_Bartolome_Rodrigo +34913393208 
      <[email-masked]> 
Subject: Re: M3UA: DRST message
Sender: [email-masked]
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Organization: EEM/TD/LNA
X-Mailer: Mozilla 4.73C-EEM/TD [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
X-SMTP-HELO: albatross-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [194.237.142.116]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Greg and Klaus,

Right now I got the point, thanks for the fast answers.

However, that sentence may not be clear enough, what about:

... If the affected destinations are ALREADY considered RESTRICTED by the
ASP...

Cheers
/MCruz

"Gradischnig, Klaus" wrote:
> 
> Maria,
> 
> receiving a TFR for a prohibited destination implicitly cancels the
> prohibited status. If a destination were still prohibited, no TFR message
> would be sent for it. The analog applies to DRST messages.
> 
> Klaus
> 
> > -----Original Message-----
> > From: Maria_Cruz_Bartolome_Rodrigo +34913393208
> > [mailto:[email-masked]]
> > Sent: June 18, 2001 10:23 AM
> > To: sigtran
> > Subject: M3UA: DRST message
> >
> >
> >
> > Hi all,
> >
> > There is something unclear in the 3.4.6 chapter (Destination
> > Restricted - DRST), see in caps:
> >
> > --------------------------------------------------------------
> > ----------
> > "The DRST message is optionally sent from the SG to all concerned
> > ASPs
> > to indicate that the SG has determined that one or more SS7
> > destinations are now restricted, or in response to a DAUD message
> > if
> > appropriate. The M3UA at the ASP is expected to send traffic to
> > the
> > affected destination via an alternate SG of equal priority, but
> > only if
> > such an alternate route exists and is available. IF THE AFFECTED
> > DESTINATION IS CURRENTLY CONSIDERED UNAVAILABLE BY THE ASP,
> > TRAFFIC TO
> > THE AFFECTED DESTINATION THROUGH THE SG INITIATING THE DRST SHOULD
> > BE
> > RESUMED.
> > THIS MESSAGE IS OPTIONAL FOR THE SG TO SEND AND OPTIONAL FOR THE
> > ASP TO
> > PROCESS. It is for use in the "STP" case described in Section
> > 1.4.2."
> > --------------------------------------------------------------
> > ----------
> >
> > If the affected destinations (those restricted, I presumed) are
> > considered unavailable by the ASP, then traffic can't be resumed
> > neither
> > through the SG initiating the DRST nor the alternate SG. Don't you
> > think
> > in this particular case, the DRST msg should be ignored by the
> > ASP?
> >
> > Apart from that, this message can NOT be optional for the ASP to
> > process,
> > at least the ASP should be able to read and discard it, don't you
> > agree?
> > Otherwise, interoperability will be impossible.
> >
> > Thanks
> > /M.Cruz
> >
> >
> > ---
> > You are currently subscribed to sigtran as:
> > [email-masked]
> > To unsubscribe send a blank email to
> > [email-masked]
> >
> 
> ---
> You are currently subscribed to sigtran as:
[email-masked]
> To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 18 Jun 2001 10:02:32 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: Missing Primitives
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-221.dallas.net [209.44.42.221]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

RTB_Cleared appears in ANSI Figure 7/T1.111.3.

RTB_Cleared is a confirmation of the Clear_RTB request.

--Brian

Ken Morneault wrote:                       (Mon, 18 Jun 2001 08:51:11)
> 
> 
> Brian,
> 
> Per your previous suggestion, ACTION_DROP_MSGS was 
> removed and CLEAR_RTB added.  I've only looked at the
> ITU specs so far, but I cannot find the RB_CLEARED and
> RTB_CLEARED indications.  Can you provide a reference.
> Further, what does MTP3 do with these indications?
> 
> Regards,
> 
> Ken
> 

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 18 Jun 2001 10:06:44 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA 08: ASPM procedures
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-221.dallas.net [209.44.42.221]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

Sounds fine!

Ken Morneault wrote:                     (Mon, 18 Jun 2001 10:09:28)
> 
> 
> Brian,
> 
> Yes, this text needs to be changed.  How about:
> 
> "At the ASP, the M2UA layer will take action based on the 
> appropriate MTP specification.  The ASP may indicate to 
> another ASP that it should become active.  However, the 
> ASP to ASP communication is out of the scope of this 
> document."
> 
> Ken
> 
> At 10:00 PM 6/14/01 -0500, you wrote:
> >Section 4.3.2
> >
> >         "... Athe [sic] ASP, M2UA shall either cause
> >         other ASPs to become active or send link-out-
> >         of-service primitives to MTP3."
> >
> >Just how was M2UA at the ASP going to cause other ASPs
> >to become active?  Also, what indications are sent to
> >MTP3 is certainly up to the ASP implementor and does
> >not impact interoperability with any SG implementation,
> >per previous discussion pertaining to SG actions towards
> >MTP2.
> >

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Adams, Richard Anthony (Richard)" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: RE: M3UA: DRST message
Date: Mon, 18 Jun 2001 16:21:16 +0100
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: ihemail2.firewall.lucent.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ihemail2.lucent.com [192.11.222.163]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Maria, Greg and Klaus,
The "restricted" procedure is a national option in SS7. So the SG should NOT
send DRST if the network doesn't support restriction. I would assume an ASP
receiving DRST in such a network would just (have) to discard it - although
it could use it as an indication that the destination is now available!  

But what the DRST indicates is, as Klaus pointed out,  that a previously
unavailable destination is now available (but restricted). 
With kind regards,
Richard A. Adams,
[email-masked], tel : +44 1666 83 2503 fax: + 44 1666 83 2712
Lucent Tech.,
Swindon Road,
Malmesbury,
Wiltshire SN16 9NA.

> ----------
> From: 	Maria_Cruz_Bartolome_Rodrigo
> +34913393208[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Monday, June 18, 2001 3:59 PM
> To: 	sigtran
> Cc: 	[email-masked]
> Subject: 	Re: M3UA: DRST message
> 
> 
> Hi Greg and Klaus,
> 
> Right now I got the point, thanks for the fast answers.
> 
> However, that sentence may not be clear enough, what about:
> 
> ... If the affected destinations are ALREADY considered RESTRICTED
> by the ASP...
> 
> Cheers
> /MCruz
> 
> 
> 
> 
> 
> "Gradischnig, Klaus" wrote:
> > 
> > Maria,
> > 
> > receiving a TFR for a prohibited destination implicitly cancels the
> > prohibited status. If a destination were still prohibited, no TFR
> message
> > would be sent for it. The analog applies to DRST messages.
> > 
> > Klaus
> > 
> > > -----Original Message-----
> > > From: Maria_Cruz_Bartolome_Rodrigo +34913393208
> > > [mailto:[email-masked]]
> > > Sent: June 18, 2001 10:23 AM
> > > To: sigtran
> > > Subject: M3UA: DRST message
> > >
> > >
> > >
> > > Hi all,
> > >
> > > There is something unclear in the 3.4.6 chapter (Destination
> > > Restricted - DRST), see in caps:
> > >
> > > --------------------------------------------------------------
> > > ----------
> > > "The DRST message is optionally sent from the SG to all concerned
> > > ASPs
> > > to indicate that the SG has determined that one or more SS7
> > > destinations are now restricted, or in response to a DAUD message
> > > if
> > > appropriate. The M3UA at the ASP is expected to send traffic to
> > > the
> > > affected destination via an alternate SG of equal priority, but
> > > only if
> > > such an alternate route exists and is available. IF THE AFFECTED
> > > DESTINATION IS CURRENTLY CONSIDERED UNAVAILABLE BY THE ASP,
> > > TRAFFIC TO
> > > THE AFFECTED DESTINATION THROUGH THE SG INITIATING THE DRST SHOULD
> > > BE
> > > RESUMED.
> > > THIS MESSAGE IS OPTIONAL FOR THE SG TO SEND AND OPTIONAL FOR THE
> > > ASP TO
> > > PROCESS. It is for use in the "STP" case described in Section
> > > 1.4.2."
> > > --------------------------------------------------------------
> > > ----------
> > >
> > > If the affected destinations (those restricted, I presumed) are
> > > considered unavailable by the ASP, then traffic can't be resumed
> > > neither
> > > through the SG initiating the DRST nor the alternate SG. Don't you
> > > think
> > > in this particular case, the DRST msg should be ignored by the
> > > ASP?
> > >
> > > Apart from that, this message can NOT be optional for the ASP to
> > > process,
> > > at least the ASP should be able to read and discard it, don't you
> > > agree?
> > > Otherwise, interoperability will be impossible.
> > >
> > > Thanks
> > > /M.Cruz
> > >
> > >
> > > ---
> > > You are currently subscribed to sigtran as:
> > > [email-masked]
> > > To unsubscribe send a blank email to
> > > [email-masked]
> > >
> > 
> > ---
> > You are currently subscribed to sigtran as:
> [email-masked]
> > To unsubscribe send a blank email to
> [email-masked]
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
> [email-masked]
> 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: RE: M3UA: DRST message
Date: Mon, 18 Jun 2001 11:33:49 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Maria,

No, for this case the ASP considers the destination as "unavailable" and
then receives a DRST from the SG.  If the affected destination were already
considered restricted then the ASP would not need to resume traffic as it
should already be using the restricted route.  So I think that the current
text is correct ... 

    "If The Affected Destination is currently considered unavailable by the
ASP, traffic to the affected destination through the SG(P) initiating the
DRST should be resumed.  This message is optional for the SG to send and
optional for the ASP to act on.  It is for use in the "STP" case described
in Section 1.4.2."

But this does lead me to a question. The "optional for the ASP to act on"
might be too weak, at least for the case of an unavailable destination.  I
think a robust ASP implementation should consider the DRST for a destination
currently considered unavailable as equivalent to an DAVA.  Would people be
willing to add a statement that "The ASP SHOULD consider a previously
unavailable destination as available".

Greg Sidebottom

 -----Original Message-----
From: 	Maria_Cruz_Bartolome_Rodrigo +34913393208
[mailto:[email-masked]] Sent:	Monday, June
18, 2001 11:00 AM
To:	sigtran
Cc:	[email-masked]
Subject:	Re: M3UA: DRST message

Hi Greg and Klaus,

Right now I got the point, thanks for the fast answers.

However, that sentence may not be clear enough, what about:

... If the affected destinations are ALREADY considered RESTRICTED by the
ASP...

Cheers
/MCruz

"Gradischnig, Klaus" wrote:
> 
> Maria,
> 
> receiving a TFR for a prohibited destination implicitly cancels the
> prohibited status. If a destination were still prohibited, no TFR message
> would be sent for it. The analog applies to DRST messages.
> 
> Klaus
> 
> > -----Original Message-----
> > From: Maria_Cruz_Bartolome_Rodrigo +34913393208
> > [mailto:[email-masked]]
> > Sent: June 18, 2001 10:23 AM
> > To: sigtran
> > Subject: M3UA: DRST message
> >
> >
> >
> > Hi all,
> >
> > There is something unclear in the 3.4.6 chapter (Destination
> > Restricted - DRST), see in caps:
> >
> > --------------------------------------------------------------
> > ----------
> > "The DRST message is optionally sent from the SG to all concerned
> > ASPs
> > to indicate that the SG has determined that one or more SS7
> > destinations are now restricted, or in response to a DAUD message
> > if
> > appropriate. The M3UA at the ASP is expected to send traffic to
> > the
> > affected destination via an alternate SG of equal priority, but
> > only if
> > such an alternate route exists and is available. IF THE AFFECTED
> > DESTINATION IS CURRENTLY CONSIDERED UNAVAILABLE BY THE ASP,
> > TRAFFIC TO
> > THE AFFECTED DESTINATION THROUGH THE SG INITIATING THE DRST SHOULD
> > BE
> > RESUMED.
> > THIS MESSAGE IS OPTIONAL FOR THE SG TO SEND AND OPTIONAL FOR THE
> > ASP TO
> > PROCESS. It is for use in the "STP" case described in Section
> > 1.4.2."
> > --------------------------------------------------------------
> > ----------
> >
> > If the affected destinations (those restricted, I presumed) are
> > considered unavailable by the ASP, then traffic can't be resumed
> > neither
> > through the SG initiating the DRST nor the alternate SG. Don't you
> > think
> > in this particular case, the DRST msg should be ignored by the
> > ASP?
> >
> > Apart from that, this message can NOT be optional for the ASP to
> > process,
> > at least the ASP should be able to read and discard it, don't you
> > agree?
> > Otherwise, interoperability will be impossible.
> >
> > Thanks
> > /M.Cruz
> >
> >
> > ---
> > You are currently subscribed to sigtran as:
> > [email-masked]
> > To unsubscribe send a blank email to
> > [email-masked]
> >
> 
> ---
> You are currently subscribed to sigtran as:
[email-masked]
> To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 18 Jun 2001 10:52:22 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: Registration messages and procedures
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      KAA03085
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-221.dallas.net [209.44.42.221]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

Unfortunately, this is not a function which is provided by element
management and which might require the exchange of PDUs between MTP3 peers
per Clause 12 of Q.704.  Some mechanism must be provided in M2UA to
accomodate this signalling function.  If you do no wish to reuse the
Registration function of M3UA for this purpose, new messages and new
procedures will be required.

--Brian

Ken Morneault wrote:                      (Mon, 18 Jun 2001 08:59:18)
> 
> 
> Brian,
> 
> I don't see a need for dynamic provisioning of this type
> for M2UA.  An network or element management system
> would suffice.
> 
> Regards,
> 
> Ken
> 
> At 04:27 PM 6/16/01 -0500, you wrote:
> >sigtran,
> >
> >I would like to propose the attached text to be included
> >in the M2UA specification.  The text is consistent (stolen)
> >from the M3UA specification and provides the ASP with the
> >ability to control the dynamic registration of Interface
> >Identifiers in support of the Automatic Allocation of
> >Signalling Data Terminals and Signalling Data Links as
> >provided for in the Q.704 and other specifications.
> >
> >--Brian
> >
> >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> >
> >x.x.x Registration Request (REG REQ)
> >
> >The REG REQ message is sent by an ASP to indicate to a remote M2UA
> >peer that it wishes to register one or more given Link Keys with the
> >remote peer.  Typically, an ASP would send this message to an SGP,
> >and expectes to receive a REG RSP in return with an associated
> >Interface Identifier value.
> >
> >The REG REQ message contains the following parameters:
> >
> >      Link Key                Mandatory
> >
> >The format for the REG REQ message is as follows:
> >
> >     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 = ??           |            Length             |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    \                                                               \
> >    /                           Link Key 1                          /
> >    \                                                               \
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    \                                                               \
> >    /                              ...                              /
> >    \                                                               \
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |            Tag = ??           |            Length             |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    \                                                               \
> >    /                           Link Key n                          /
> >    \                                                               \
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >Link Key: fixed length
> >
> >    The Link Key parameter is mandatory.  The sender of this message
> >    expects the receiver of this message will create a Link Key entry
> >    and assign a unique Interface Identifier value to it, if the Link
> >    Key entry does not yet exist.
> >
> >    The Link Key parameter may be present multiple times in the same
> >    message.  This is used to allow the registration of multiple Link
> >    Keys in a single message.
> >
> >The format of the Link Key  parameter is as follows:
> >
> >     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
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                       Local-LK-Identifier                     |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                 Signalling Data Terminal Identifier           |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                   Signalling Data Link Identifier             |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >Local-LK-Identifier: 32-bit integer
> >
> >    The mandatory Local-LK-Identifier field is used to uniquely
> >    identify the registration request.  The Identifier value is
> >    assigned by the ASP, and is used to correlate the response in a
> >    REG RSP message with the original registration request.  The
> >    Identifier value must remain unique until the REG RSP is
> >    received.
> >
> >    The format of the Local-LK-Identifier field is as follows:
> >
> >     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 = ??            |         Length = 8            |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                    Local-LK-Identifier value                  |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >Signalling Data Terminal Identifier:
> >
> >    The Signalling Data Terminal Identifier parameter is mandatory,
> >    and identifies the Signalling Data Terminal associated with the
> >    SS7 link for which the ASP is registering.  The format is as
> >    follows:
> >
> >     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 = ??            |         Length = 8            |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |          Reserved             |        SDT Identifier         |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    The SDT Identifier is a 32-bit unsigned value which may only be
> >    significant to 12 or 14 bits depending on the SS7 variant which
> >    is supported by the MTP Level 3 at the ASP.  Insignificant SDTI
> >    bits are coded 0.
> >
> >Signalling Data Link Identifier:
> >
> >    The Signalling Data Link Identifier parameter is mandatory, and
> >    identifies the Siganlling Data Link Identifier associated with
> >    the SS7 link for which the ASP is registering.  The format is as
> >    follows:
> >
> >     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 = ??            |         Length = 8            |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |          Reserved             |        SDL Identifier         |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    The SDL Identifier is a 32-bit unsigned value which may only be
> >    significant to 12 or 14 bits depending on the SS7 variant which
> >    is supported by the MTP Level 3 at the ASP.  Insignificant SDLI
> >    bits are coded 0.
> >
> >x.x.x Registration Response (REG RSP)
> >
> >The REG RSP message is used as a response to the REG