Subject: july sigtran mail archives part 2

From: "Ong, Lyndon" <[email-masked]>
Date: Fri, 3 Aug 2001 09:20:23 -0700

From: [email-masked]
X-Lotus-FromDomain: HSS
To: "sigtran" <[email-masked]>
Date: Mon, 16 Jul 2001 09:25:29 +0530
Subject: RE: M3UA Changes : 6 vs 7
X-SMTP-HELO: hindon.hss.co.in
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [202.54.26.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi,
I would like to have a copy of the changes in M3UA draft 6 vs draft 7.
Thanks
Prashant Singh

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Antonio Roque-Alvarez (ECE)" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: RE: Comments on M3UA MIB
Date: Mon, 16 Jul 2001 12:30:43 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
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]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

-----Original Message-----
From: Srivats P. [mailto:[email-masked]] Sent: Tuesday, July 10, 2001
5:11 AM
To: sigtran
Subject: Re: RE: Comments on M3UA MIB

Antonio,

Find comments inline ...

Regards,
Srivats P.

At 7/9/01 1:53:00 PM, you wrote:
>
>Hello,
>
>Thank you very much for your comments.
>Please, find answers inline.
>
>Regards,
>Antonio
>
>
>
>-----Original Message-----
>From: Srivats P. [mailto:[email-masked]]
>Sent: Friday, June 29, 2001 9:32 AM
>To: sigtran
>Subject: Comments on M3UA MIB
>
>
>Antonio,
>
>I have some comments on the M3UA MIB Draft ver 01 -
>
>1. Section 3.1.2.3 Signaling Process Table - Para 4
>"Several SP will correspond to one SP Endpoint. They will be linked by the 
>Association Id."
>I don't understand what you want to say by the above statement
>
>[Antonio] What I try to say is that there may be more than one entry in the
table with the same AssocId ( that's the common link ). All this entries are
differentiated by the AppId which the SP is serving.
>
>I will rephrase the hold chapter:
>
>"Defines data related to a Signaling Process, identified by the Association
ID of the association established to that remote Endpoint where the SP is
running, and the Logical Application ID which the SP is serving.
>
>A Signaling Process is a process instance that uses M3UA to communicate
with other signaling process. An ASP, an SGP and an IPSP are all signaling
processes.
>
>As a SP can maintain different states and traffic handling modes for every
LApp it is serving, i.e. The ASP_1 may be ASP-ACTIVE(LOAD-SHARING) for AS_1,
>ASP-INACTIVE for AS_2 and ASP-ACTIVE(OVER-RIDE) for AS_3. Then, one entry
>will be created in this table per every combination of AS ID and
Association ID.
>
>All the entries corresponding to the same SP running in an specific
Endpoint will have a common link, the Association Id."
>
>
>
>2. Section 3.1.2.4 Signaling Process Endpoint Table - Para 6
>"The main table also contains statistics data related to the M3UA messaging
>exchanged through that association between the Signaling Processes that
>hold the association."
>This has been moved to another table.
>
>[Antonio] OK, removed
>
>
>3. Section 3.1.2.5 Signaling Process Endpoint Statistics Table
>As per the object definition for this table, the following
>fields need to be included in this table - m3uaAppId and m3uaSpEpId
>Remove m3uaSpEpRowStatus.
>
>[Antonio] You are right, indexes were missing, but SPE Table is indexed by
SPE ID and Assoc ID.
>OK, removing m3uaSpEpRowStatus.

[Srivats] Why is Assoc Id part of the index ? In my opinion SPEP ID is
unique in itself and will suffice to serve as index.

[Antonio] Yes you are right, but I considered that might be useful to be
able to make queries about an SPE using the AssocId of the association
established towards that Endpoint.

>
>I have a question here. Do you want to maintain statistics
>on a per AS - ASP basis ? In that case how do you propose
>to maitain statistics for messages which are not related to a particular
>AS such as ASPUP, ASPDN etc. ?
>Or should it be only on ASP basis, instead of AS - ASP ?
>
>[Antonio] No, I don't want to maintain statistics on a per AS(App) -
ASP(SP) basis. I just want to maintain statistics on a per ASP(SP) basis,
that's why the main group if statistics is maintained in the SPE table. An
SPE identifies the SP that is runnin g
> on it.
>Statistics related to AS(App) are maintained in App Table. Currently there
is only one defined: Number of Times an App is unreachable ( because it is
DOWN ).
>
>
>
>4. Section 3.1.2.6 Routing Table
>What about "Routing Context" ? Or do you propose to use
>m3uaPeerAppId as the routing context ?
>
>[Antonio] I just wanted to remark that the result of the routing is an
Application ID, that is the same as the Routing Context. That makes me think
about changing all the references to "Logical Application" by "Routing
Context". Then, we would have:
>
>- "RC Table" instead of "Logical Application Table".
>- An entry in Signaling Process table would be indexed by AssocId and the
RcId which the SP is serving.

[Srivats] But then the text would become inconsistent with Routing Table at
ASP.

[Antonio] Not completely if we consider that an SG is giving service (
reachability ) to a set of DPC's. This group of DPC's can be considered a
RC.

>
>
>
>5. Section 3.1.2.6 Network Appearance Table
>Duplicate Section No., Add m3uaNaRowStatus
>
>[Antonio] OK, done.
>
>
>6. Section 3.1.2.7.2 Local and Remote IP Address Tables
>I suggest using m3uaSpEpId instead of m3uaAssocId as
>the index.
>
>[Antonio] Could you elaborate on this a little more, please.

[Srivats] It is my understanding that spepId is unique and sufficient to
suffice as the index for the spep Table. And since it is possible to
configure the Local and Remote Address Tables for a particular SPEP, these
should be indexed using spep Id.

[Antonio] You are right again, so new index is going to be added using spep
id. But as I have said in issue 3, it might be useful to keep assoc id as
index as well...

>
>
>7. Object Definition of m3uaMaxStreamInbound
>Should it have a MAX-ACCESS of "read-write" or "read-only" ?
>Secondly the SCTP MIB already has this object, and while
>accepting incoming associations, SCTP uses its own value rather
>than M3UA's value.
>
>[Antonio] When SCTP is initialized, M3UA will have to provide a value to
SCTP. This is why I thought it should be configured here.
>What about the case where the value configured in SCTP is bigger than the
value wanted by the user, M3UA in this case.

[Srivats] From Section 10 SCTP - ULP Interface of RFC 2970, I don't see any
such parameter in either the INITIALIZE or the ASSOCIATE primitive.

[Antonio] OK, I was confused with our own implementation, but I will remove
it from the standard MIB.

>
>8. Object Definition of m3uaSpEpEntry
>Index should not include "m3uaAppId"
>
>[Antonio] Yes, you are right. This was already fixed in new version. It is
m3uaSpEpAssocId instead of m3uaAppId
>
>9. Object Definition of m3uaSpEpStatRowStatus
>Delete definition as all entries in this table are "read-only"
>
>[Antonio] OK, done.
>
>10. Object Definition of m3uaRoutingTable
>As the object is currently defined, this cannot be used at
>at a ASP M3UA. A Routing Key at an ASP would be for the peer
>Logical Application ie. SG. Thus, only the DPC component of
>routing key would be used, everything else would be null.
>But a DPC may be accessible to ASP via multiple SGs. But the
>table cannot take multiple rows becoz that would lead to
>duplicate routing keys which is the index for the table.
>
>[Antonio] That's right. Then...
>The result of the routing table would be a ResultSet each containing one or
more AppIds and a priority for every one. The routing table at SGP will only
allow to add one RC/App ID per ResultSet.
>
>This means that a ResultSet Table must be added to the mib.
>
>Any comments on that??

[Srivats] Either you do that or define two routing tables one for ASP and
one for SG ... letme think this over ...

[Antonio] Having a look to draft 7, it seems that this problem has
disappeared as the word "SG" has been replaced by "SGP" in many paragraphs.
Then, it cannot be inferred from the new text that "a DPC may be accessible
to ASP via multiple SGs". Am I right ??
Anyway If we would want to keep this possibility: 1. I have been trying to
maintain all data for different entities in common tables so I wouldn't like
to split Routing Table.
2. Although RT is splitted, a new RouteSet Table would be needed for ASP RT
anyway.

>
>11. Typos -
>-Date on Page 1. Should be May 23, 2001
>-Abstract on Page 1 - Para 2. Should be M3UA
>-Section 1. Introduction - Para 3. Should be M3UA
>-Object Definition of "LOGICAL APPLICATION TABLE" : Change 
>"Application Server" to "Logical Application" and "AS"
>to "App"
>
>[Antonio] OK, done
>
>Thank you very much again and sorry for the late response.
>
>Regards,
>Srivats P.
>
>
>
>---
>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]
To: "sigtran" <[email-masked]>
Date: Mon, 16 Jul 2001 08:21:54 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Mailer: MailCity Service
Subject: m2ua WG Last Call
X-Sender-Ip: 63.96.78.21
Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80)
X-SMTP-HELO: shared1-mail.whowhere.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: shared1-batch.whowhere.com [209.185.123.82]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Folks,

We are now starting WG Last Call for the M2UA specification, based on
draft-ietf-sigtran-m2ua-09.txt.  Please get any comments in by Friday, July
28th.  When giving a comment, please first send an email copy to myself
([email-masked]) and Ken Morneault ([email-masked]) to get the comment
recorded and numbered.

Thanks for your help.

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]
From: "Balani, Sandeep" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2UA comment #2
Date: Mon, 16 Jul 2001 10:40:31 -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]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

> Hi Ken, 
>   I have a few comments in M2UA draft 9. 
> 
> 1) In M2UA draft 9, u have introduced correlation id in data message and
> corresponding Ack messages. But there was no details on how to use the
> correlation id ? What will happen if the Ack for a data message with
> correlation id is missing ? 
> I have another basic question why it was introduced, when UA's assume to
> be sitting over relible transport layer SCTP. 
> 
> 2) In the section where dynamic registration is added, at some places word
> routing key and SGP are used, i think may be we should be consistent about
> different term in the draft. 
> 
> 3)  In the retrieval request/confirm messages, ACTION_RTRV_TRANS is
> present at some places in description, but it is actually removed from
> valid values of Actions. ACTION_DROP_MSG is missing from valid action
> types which was existing in draft 7 . 
> 
> 4) Ken, i am skeptic about the registration/deregistration procedure in
> M2UA, because i think its different from M3UA in the sense that M3UA has
> to just configure the Routing key at its own layer and its ready to handle
> traffic for that routing key.
> On the other hand for M2UA it require a lot of other procedures like
> configuring the link at NIF, MTP2 and M2UA, aligning the SS7 link at MTP2,
> wait for alignment complete.   Ken could u please throw some light on this
> procedure specific to M2UA  so that this could be feasible for
> implementors.
>  
> 
> Thanks
> Sandeep
> 
> 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Lotus-FromDomain: MCMAIN@MCEXT
From: Andrew Barrington <[email-masked]>
Sender: Andrew Barrington <[email-masked]>
To: "sigtran" <[email-masked]>
Date: Mon, 16 Jul 2001 19:37:13 +0100
Subject: Re: String handling & representation in the info string field.
X-SMTP-HELO: cvis21.Marconicomms.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [195.99.244.53]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

All,
     A minor issue - as per Gregs memo below I propose that the following
text (or similar) be used to clarify that the info string parameter should
contain a null terminating character. This is then consistent with the host
name string description as in SCTP RFC 2960. I think Greg holds a lot of
hope in me not to screw it up however here it is.......

"At least one null terminator shall be included in the info string parameter
if present and must be included in the length of that parameter".

The intention is that if there is no string then the info string parameter
should either not be present in a message or contain a single null
character.

The issue arose during testing with the ethereal M3UA decoder, which assumed
that the string was null terminated and the info string I was sending
wasn't...

Any objections to this proposal ?

Cheers,

Andrew

---------------------- Forwarded by Andrew Barrington/MAIN/MC1 on 16/07/2001
19:24 ---------------------------

"Greg Sidebottom" <[email-masked]> on 16/07/2001 17:37:54

   To:       Andrew Barrington/MAIN/MC1@MCMAIN                  
   cc:                                                          

   Subject:  Re: String handling & representation in the info   
           string field.                                      

Hi Andrew,

Actually we hadn't considered one way or the other whether to delimit with a
null character.  If you believe a null character has some benefit then I
encourage you to make a quick proposal to the list (together with a
clarification on whether you think the null character would be included in
the length).  If not then can I get you to supply a clarification sentance
(so I don't screw it up!)?

Thanks,

  Greg

----- Original Message -----
From: "Andrew Barrington" <[email-masked]> To:
<[email-masked]>
Sent: Saturday, July 14, 2001 3:17 PM
Subject: String handling & representation in the info string field.

>
>
> Greg,
>      A couple of queries on the info string parameter.
>
> i)   Is a string contained in the info string parameter delimited by a
null
> character ?
> ii)  If so is the null character included in the info string parameter
length ?
>
> either way I think it would help to clarify this in the M3UA spec.
>
> Thanks,
>
> Andrew
>
>

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 16 Jul 2001 13:58:50 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: String handling & representation in the info string field.
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-253.dallas.net [209.44.42.253]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Andrew,

I see no reason whatsoever for requiring a null character on a string which
has an indicated length.  Besides, it should take about 2 seconds to fix
Ethereal ;)  It seems that the only purpose of the INFO string is for
debugging, and a monitor like Ethereal needs to be written to accept invalid
information in all fields (anyway) for it to serve its purpose.

I don't believe it is an interoperability issue at all, and if there is no
other compelling reason, there is simply no need to require a null character
anywhere in the string.

My $0.02.

--Brian

Andrew Barrington wrote:                     (Mon, 16 Jul 2001 19:37:13)
> 
> 
> All,
>      A minor issue - as per Gregs memo below I propose that the following
text
> (or similar) be used to clarify that the info string parameter should
contain a
> null terminating character. This is then consistent with the host name
string
> description as in SCTP RFC 2960. I think Greg holds a lot of hope in me
not to
> screw it up however here it is.......
> 
> "At least one null terminator shall be included in the info string
parameter if
> present and must be included in the length of that parameter".
> 
> The intention is that if there is no string then the info string parameter
> should either not be present in a message or contain a single null
character.
> 
> The issue arose during testing with the ethereal M3UA decoder, which
assumed
> that the string was null terminated and the info string I was sending
wasn't...
> 
> Any objections to this proposal ?
> 
> Cheers,
> 
> Andrew

-- 
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: Mon, 16 Jul 2001 15:10:24 -0400
From: Warren Anthony Briggs <[email-masked]>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
CC: [email-masked]
Subject: draft-ietf-sigtran-sua-06.txt
X-SMTP-HELO: ottawa.pt.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [206.191.2.130]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

John Loughney,

Could  you please clarify the following issue for me?

Section 3.9.2.3   (Global Title)  of draft-ietf-sigtran-sua-06.txt  no
longer includes an Odd/Even indicator.  Yet the descriptions  for the
conversion of Translation type, Numbering Plan and Nature of Address seem to
refer Odd/Even indicator. Please see below.

     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 = 0x8001          |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   No. Digits  | Trans. type   |    Num. Plan  | Nature of Add |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Global Title Digits                  |

1) SS7 network uses GTI = 0001

   Nature of Address is taken over. It is implicitly assumed that
   Translation Type = Unknown and Numbering Plan = E.164 (value 1). The
   number of digits is determined by the SCCP address length and
   Odd/Even indicator.

3) SS7 network uses GTI = 0011

   Numbering Plan and Translation Type are taken over. It is implicitly
   assumed that the Nature of Address = Unknown. The number of digits
   is determined by the SCCP address length and the Odd/Even indicator.

Best Regards,
Warren Briggs

---
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, 16 Jul 2001 15:18:31 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
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]

Brian,

I don't have a problem with making ASP Idenfiier in the ASP Up message
mandatory.  It would be useful for the case of remote ASPs in Active/Standby
as well as Broadcast mode of operattion.

However, it is unclear to me that multiple ASPs can share the same SCTP
endpoints.  Greg - could you please clarify.

Regards,

Ken

At 02:28 AM 7/15/01 -0500, you wrote:
>Ken, Greg, John,
>
>I would like to propose that the ASP Identifier in the ASP Up
>message be made mandatory as the SGP might have no other mechanism
>to identify the ASP which has connected via an SCTP association.
>
>That there exists cases where the SGP cannot identify the
>connecting ASP is clear: any configuration which has multiple
>ASPs for a given host sharing the same SCTP endpoints as
>illlustrated in the architectural diagrams for M3UA as multiple
>ASPs per Host cannot be distinguished by SCTP endpoint.  The
>SGP has no other means to distinguish these ASPs and cannot
>perform management blocking functions or AS state notifications
>or any other procedures applicable in the AS-INACTIVE state.
>In some configurations, the SGP will be unable to peform its
>functions properly in all ASP states because it cannot identify
>the ASP and match it to static configuration data.
>
>Making the parameter mandatory allows the SGP to alway be able
>to distinguish between connecting ASPs and apply the procedures
>appropriately.
>
>The text in the ASP Up message description and text in the ASP
>Up procedures would have to be changed to reflect that the ASP
>Id is a mandatory parameter.
>
>Comments?
>
>-- 
>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, 16 Jul 2001 15:57:51 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA comment #2
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,

Pls see responses below.

Regards,

Ken

At 10:40 AM 7/16/01 -0700, Balani, Sandeep wrote:

> > Hi Ken, 
> >   I have a few comments in M2UA draft 9. 
> > 
> > 1) In M2UA draft 9, u have introduced correlation id in data message and
> > corresponding Ack messages. But there was no details on how to use the
> > correlation id ? What will happen if the Ack for a data message with
> > correlation id is missing ? 
> > I have another basic question why it was introduced, when UA's assume to
> > be sitting over relible transport layer SCTP. 
> > 

There was a thread that covered the use of Correlation ID for M3UA and M2UA
entitled "M3UA:  Changeover between ASPs".  Please refer to Brian Bidulock's
email in this thread dated 06/01/01.  It provides an example of the use for
Correlation ID.

> > 2) In the section where dynamic registration is added, at some places
word
> > routing key and SGP are used, i think may be we should be consistent
about
> > different term in the draft. 
> > 

I didn't find any uses of routing key, but did replace SGP with SG for
consistency.

> > 3)  In the retrieval request/confirm messages, ACTION_RTRV_TRANS is
> > present at some places in description, but it is actually removed from
> > valid values of Actions. ACTION_DROP_MSG is missing from valid action
> > types which was existing in draft 7 . 
> > 

I removed the ACTION_RTRV_TRANS from the text since it was removed as an
Action.  ACTION_DROP_MSGS was not needed since Status Request (Flush or
Clear RTB) can be used.

> > 4) Ken, i am skeptic about the registration/deregistration procedure in
> > M2UA, because i think its different from M3UA in the sense that M3UA has
> > to just configure the Routing key at its own layer and its ready to
handle
> > traffic for that routing key.
> > On the other hand for M2UA it require a lot of other procedures like
> > configuring the link at NIF, MTP2 and M2UA, aligning the SS7 link at
MTP2,
> > wait for alignment complete.   Ken could u please throw some light on
this
> > procedure specific to M2UA  so that this could be feasible for
> > implementors.
> >  

As noted in the document, the REG / DE-REG messages are only used if
automatic allocation of Signaling Terminals or Signaling Data Links.
Please refer to Clause 12 of Q.704 for a description.  

> > 
> > 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: Mon, 16 Jul 2001 15:07:35 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
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-253.dallas.net [209.44.42.253]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

Ooops.  SCTP endpoints is not really what I meant :[  What I meant was that
there may be multiple ASPs on the same host sharing the same set of IP
addresses.

The SG/SGP cannot necesarily distinguish between ASPs on the same host
(i.e., they may be using dynamically allocated port numbers to connect to
the SG/SGP well-known port number).
Also, rather than having the SG/SGP try to distinguish partially the
identify of a connecting ASP by the IP address (and/or port number) from
which the ASP is connecting, it seems simpler and more to the sake of
interoperability that the ASP simply identify itself when it goes ASPUP.

--Brian

Ken Morneault wrote:                    (Mon, 16 Jul 2001 15:18:31)
> 
> 
> Brian,
> 
> I don't have a problem with making ASP Idenfiier in the ASP
> Up message mandatory.  It would be useful for the case
> of remote ASPs in Active/Standby as well as Broadcast
> mode of operattion.
> 
> However, it is unclear to me that multiple ASPs can share
> the same SCTP endpoints.  Greg - could you please clarify.
> 
> Regards,
> 
> Ken
> 
> At 02:28 AM 7/15/01 -0500, you wrote:
> >Ken, Greg, John,
> >
> >I would like to propose that the ASP Identifier in the ASP Up
> >message be made mandatory as the SGP might have no other mechanism
> >to identify the ASP which has connected via an SCTP association.
> >
> >That there exists cases where the SGP cannot identify the
> >connecting ASP is clear: any configuration which has multiple
> >ASPs for a given host sharing the same SCTP endpoints as
> >illlustrated in the architectural diagrams for M3UA as multiple
> >ASPs per Host cannot be distinguished by SCTP endpoint.  The
> >SGP has no other means to distinguish these ASPs and cannot
> >perform management blocking functions or AS state notifications
> >or any other procedures applicable in the AS-INACTIVE state.
> >In some configurations, the SGP will be unable to peform its
> >functions properly in all ASP states because it cannot identify
> >the ASP and match it to static configuration data.
> >
> >Making the parameter mandatory allows the SGP to alway be able
> >to distinguish between connecting ASPs and apply the procedures
> >appropriately.
> >
> >The text in the ASP Up message description and text in the ASP
> >Up procedures would have to be changed to reflect that the ASP
> >Id is a mandatory parameter.
> >
> >Comments?
> >
> >-- 
> >Brian F. G. Bidulock
> >[email-masked]
> >http://www.openss7.org/
> >

-- 
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: Michael Tüxen <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re(2): String handling & representation in the info string field.
Date: Mon, 16 Jul 2001 22:11:08 +0200
X-Mailer: CTM PowerMail 3.0.9 carbon <http://www.ctmdev.com>
X-SMTP-HELO: ilsa.franken.de
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ilsa.franken.de [193.175.24.42]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hiiiiiiiiiii,
I agree with Brian.
I can not see any reason why we should make the message format conformant to
the C string convention. Other languages use a string length parameter to
describe the end of the string. Since we have a length field in the
parameter, we know the length.
The Bug in ethereal is due to a, well not clear API description.
It will be fixed in the next release (and the complete dissector will be
updated to a more recent version of M3UA when it is out)

Best regards
Michael
-- 
e-mail: [email-masked]

On Mon, Jul 16, 2001, Brian F. G. Bidulock <[email-masked]> wrote:

>Andrew,
>
>I see no reason whatsoever for requiring a null character on a
>string which has an indicated length.  Besides, it should take
>about 2 seconds to fix Ethereal ;)  It seems that the only
>purpose of the INFO string is for debugging, and a monitor like
>Ethereal needs to be written to accept invalid information in
>all fields (anyway) for it to serve its purpose.
>
>I don't believe it is an interoperability issue at all, and if
>there is no other compelling reason, there is simply no need to
>require a null character anywhere in the string.
>
>My $0.02.
>
>--Brian
>
>Andrew Barrington wrote:                     (Mon, 16 Jul 2001 19:37:13)
>> 
>> 
>> All,
>>      A minor issue - as per Gregs memo below I propose that the
>following text
>> (or similar) be used to clarify that the info string parameter should
>contain a
>> null terminating character. This is then consistent with the host name
>string
>> description as in SCTP RFC 2960. I think Greg holds a lot of hope in me
>not to
>> screw it up however here it is.......
>> 
>> "At least one null terminator shall be included in the info string
>parameter if
>> present and must be included in the length of that parameter".
>> 
>> The intention is that if there is no string then the info string
parameter
>> should either not be present in a message or contain a single null
>character.
>> 
>> The issue arose during testing with the ethereal M3UA decoder, which
assumed
>> that the string was null terminated and the info string I was sending
>wasn't...
>> 
>> Any objections to this proposal ?
>> 
>> Cheers,
>> 
>> Andrew
>
>-- 
>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 leave-sigtran-
>[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Mon, 16 Jul 2001 15:25:47 -0500
From: Kurt Kite <[email-masked]>
Reply-To: [email-masked]
Organization: Ericsson North America Inc.
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
X-SMTP-HELO: imr1.ericy.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: imr1.ericy.com [208.237.135.240]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

"Brian F. G. Bidulock" wrote:

> Ken,
>
> Ooops.  SCTP endpoints is not really what I meant :[  What I
> meant was that there may be multiple ASPs on the same host
> sharing the same set of IP addresses.
>
> The SG/SGP cannot necesarily distinguish between ASPs on the
> same host (i.e., they may be using dynamically allocated port
> numbers to connect to the SG/SGP well-known port number).
> Also, rather than having the SG/SGP try to distinguish partially
> the identify of a connecting ASP by the IP address (and/or
> port number) from which the ASP is connecting, it seems simpler
> and more to the sake of interoperability that the ASP simply
> identify itself when it goes ASPUP.

Unless I misunderstood your proposal for ASP Id, the SG/SGP will still have
to use the IP address/port number because the ASP Id is only "significant
among the ASPs that support an AS."

I don't see a compelling reason to make the ASP Id mandatory. The draft is
full of examples of optional parameters, e.g., network appearance.

/Kurt

>
>
> --Brian
>
> Ken Morneault wrote:                    (Mon, 16 Jul 2001 15:18:31)
> >
> >
> > Brian,
> >
> > I don't have a problem with making ASP Idenfiier in the ASP
> > Up message mandatory.  It would be useful for the case
> > of remote ASPs in Active/Standby as well as Broadcast
> > mode of operattion.
> >
> > However, it is unclear to me that multiple ASPs can share
> > the same SCTP endpoints.  Greg - could you please clarify.
> >
> > Regards,
> >
> > Ken
> >
> > At 02:28 AM 7/15/01 -0500, you wrote:
> > >Ken, Greg, John,
> > >
> > >I would like to propose that the ASP Identifier in the ASP Up
> > >message be made mandatory as the SGP might have no other mechanism
> > >to identify the ASP which has connected via an SCTP association.
> > >
> > >That there exists cases where the SGP cannot identify the
> > >connecting ASP is clear: any configuration which has multiple
> > >ASPs for a given host sharing the same SCTP endpoints as
> > >illlustrated in the architectural diagrams for M3UA as multiple
> > >ASPs per Host cannot be distinguished by SCTP endpoint.  The
> > >SGP has no other means to distinguish these ASPs and cannot
> > >perform management blocking functions or AS state notifications
> > >or any other procedures applicable in the AS-INACTIVE state.
> > >In some configurations, the SGP will be unable to peform its
> > >functions properly in all ASP states because it cannot identify
> > >the ASP and match it to static configuration data.
> > >
> > >Making the parameter mandatory allows the SGP to alway be able
> > >to distinguish between connecting ASPs and apply the procedures
> > >appropriately.
> > >
> > >The text in the ASP Up message description and text in the ASP
> > >Up procedures would have to be changed to reflect that the ASP
> > >Id is a mandatory parameter.
> > >
> > >Comments?
> > >
> > >--
> > >Brian F. G. Bidulock
> > >[email-masked]
> > >http://www.openss7.org/
> > >
>
> --
> 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, 16 Jul 2001 16:28:51 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
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-253.dallas.net [209.44.42.253]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Kurt,

Kurt Kite wrote:                       (Mon, 16 Jul 2001 15:25:47)
> 
> Unless I misunderstood your proposal for ASP Id, the SG/SGP will still
> have to use the IP address/port number because the ASP Id is only
"significant
> among the ASPs that support an AS."
>
What I am saying is that it is more significant than that.  By the very
nature of the client-server arrangement where the SGP is the server and the
ASP is the client, the ASP knows implicitly which SGP it is connecting to.
However, the server (as usual) has no idea which application process is
connecting to it.

Besides, this line you quote talks about significance, not uniqueness.  It
seems trivial to me that in should be possible to assign an ASP Id at an ASP
which is unique over a very large number of deployed Hosts, precluding the
need to rely on layer boundary violations to identify an ASP.  In dynamic IP
address configurations, it is not possible to rely upon IP addresses as
identifying an ASP.

Now, there are a good number of procedures and a large portion of the ASP
management at the Layer Manager which needs to know the identify of the ASP.
Diagnostics, debugs, logs, management indications, all these need to
pinpoint the identity of the ASP.

> 
> I don't see a compelling reason to make the ASP Id mandatory. The draft is
full
> of examples of optional parameters, e.g., network appearance.
> 

Unfortunately, for the parameters that you cite, it can always be determined
by local UA configuration data at the SGP or ASP wether they need to be
included in the message or not.

The ASP has no way of knowing from local UA configuration data whether an
SGP requires an ASP Id to identify it.

++++++++
If you don't want to make the parameter `Mandatory,' how about adding
another Error Code:

	"Refused - ASP Identifier Required         0xc"

To be sent in response to an ASPUP message which does not contain an ASP Id
parameter when the SGP requires one.  Then, instead of simply adding 8 bytes
to ever ASPUP message as proposed, the ASP can go around again a second time
with an ASP Id. ;)
++++++++

Tell me how you will handle this situation at the SGP:

I have 3 hosts sporting 8 ASPs each.  All three hosts DHCP boot all
interfaces.  Your SGP permits SCTP assocations from any IP address in the
DHCP pool.  As your associations come up, 3 ASPs connect to your well-known
UA port number on the SGP with various demand allocated port numbers.  They
all send ASPUPs with no ASP Ids.

	o   What ASPs just connected?
	o   What do you tell LM in the M-ASP_STATUS?
	o   What do you write to your logs?
	o   Which AS notifications do you send to these ASPs
	    while they are in the ASP-DOWN state?

Compelled yet?

--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]
Sender: [email-masked]
Date: Mon, 16 Jul 2001 17:12:54 -0500
From: Kurt Kite <[email-masked]>
Reply-To: [email-masked]
Organization: Ericsson North America Inc.
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
X-SMTP-HELO: imr1.ericy.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [208.237.135.240]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

"Brian F. G. Bidulock" wrote:

> Kurt,
>
> Kurt Kite wrote:                       (Mon, 16 Jul 2001 15:25:47)
> >
> > Unless I misunderstood your proposal for ASP Id, the SG/SGP will still
> > have to use the IP address/port number because the ASP Id is only
"significant
> > among the ASPs that support an AS."
> >
> What I am saying is that it is more significant than that.  By
> the very nature of the client-server arrangement where the SGP
> is the server and the ASP is the client, the ASP knows
> implicitly which SGP it is connecting to.  However, the server
> (as usual) has no idea which application process is connecting
> to it.

If each ASP has a unique IP address/port number combination then the SGP can
determine which ASP is connecting to it.

>
>
> Besides, this line you quote talks about significance, not
> uniqueness.

Then I misunderstood the proposal. Perhaps it needs clarifiation.

> It seems trivial to me that in should be possible
> to assign an ASP Id at an ASP which is unique over a very large
> number of deployed Hosts, precluding the need to rely on layer
> boundary violations to identify an ASP.  In dynamic IP address
> configurations, it is not possible to rely upon IP addresses as
> identifying an ASP.

I did not indicate that it would be complicated to generate a unique ASP id,
only that I did not see a compelling reason to do so. If an implementation
is not planning on using dynamic IP addresses and port numbers then a unique
ASP Id address is simply not necessary.

>
>
> Now, there are a good number of procedures and a large portion
> of the ASP management at the Layer Manager which needs to know
> the identify of the ASP.  Diagnostics, debugs, logs, management
> indications, all these need to pinpoint the identity of the ASP.

Ok.

>
>
> >
> > I don't see a compelling reason to make the ASP Id mandatory. The draft
is full
> > of examples of optional parameters, e.g., network appearance.
> >
>
> Unfortunately, for the parameters that you cite, it can always
> be determined by local UA configuration data at the SGP or ASP
> wether they need to be included in the message or not.
>
> The ASP has no way of knowing from local UA configuration data
> whether an SGP requires an ASP Id to identify it.

Why can't the ASP figure this out from local configuration data? If it can't
then send the ASP Id. The SG can use it or not.

>
>
> ++++++++
> If you don't want to make the parameter `Mandatory,' how about
> adding another Error Code:
>
>         "Refused - ASP Identifier Required         0xc"
>
> To be sent in response to an ASPUP message which does not
> contain an ASP Id parameter when the SGP requires one.  Then,
> instead of simply adding 8 bytes to ever ASPUP message as
> proposed, the ASP can go around again a second time with an ASP
> Id. ;)

If the ASP Id is not made mandatory then this error code is probably needed.
However, I doubt if anyone would build an ASP that would react to it. The
ASP will either support the generation of ASP Id or it will not.

>
> ++++++++
>
> Tell me how you will handle this situation at the SGP:
>
> I have 3 hosts sporting 8 ASPs each.  All three hosts DHCP boot
> all interfaces.  Your SGP permits SCTP assocations from any
> IP address in the DHCP pool.  As your associations come up,
> 3 ASPs connect to your well-known UA port number on the SGP with
> various demand allocated port numbers.  They all send ASPUPs
> with no ASP Ids.

>
>         o   What ASPs just connected?
>         o   What do you tell LM in the M-ASP_STATUS?
>         o   What do you write to your logs?
>         o   Which AS notifications do you send to these ASPs
>             while they are in the ASP-DOWN state?
>
> Compelled yet?

No. I am not disagreeing with you. If an ASP Host is going to use DHCP to
allocate IP addresses then it will have to generate unique ASP Ids for use
by the SGP. What I am saying is that it is possible to build an SGP and an
ASP that do not use DHCP, i.e.,
the IP addresses are statically assigned as well as the port number, in
which case unique
ASP Id are not needed. Hence, I don't see a compelling reason to force the
ASP to generate
one.

/Kurt

>
>
> --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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 16 Jul 2001 18:23:16 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
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.253]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Kurt,

Ok.  I think we're on the same page.

Do agree that the SGP cannot determine from local UA configuation data?
That it must rely upon SCTP and IP configuration data?

Your position, if I understand it correctly, is that it is sufficient that
the SGP rely upon IP addresses and such to determine an ASP Id in static IP
configurations.

I agree, getting away without ASP Id is possible (but clumsy) where:

    1.    (a)	One Host has only one ASP per SGP.

          or
    
	  (b)	IP Addresses on ASP Hosts are static or
	        selected from disjoint sets.

          and

    2.    (a)	Only one ASP per Host registers per SGP.

          or

	  (b)   Port numbers for ASPs are static or are
		selected from disjoint sets.

Situation 1(a) is uninteresting because is goes against carrier-grade
recommendations.

Situation 1(b) is possible, but precluded by most RFPs I've seen which
require dynamic addressing... (but wait!)

Situation 2(a) is uninteresting because is reduces the reliability of the
overall model by not allowing full mesh associations between groups of ASPs
and SGPs.

Situation 2(b) requires that both the SGP and the ASP be provisioned with
static or complex port number assignments for each ASP in a host and would
be as difficult to coordinate as assigning each ASP an ASP Id (or, more
difficult).

My position is that the SGP should not provision and rely on (nor be forced
to provision and rely on) layer-below information (in this case IP addresses
and port numbers) even when it might determine the ASP Id in a few cases.
What I feel that it can be made to rely on is the UA managed identifier.

Except in the uninteresting corner cases above, the SGP will need to require
an ASP identifier anyay.  Making the parameter mandatory is the simple thing
to do, covers all the cases, and relieves both the SGP and ASP from the need
to rely on layer-below dependent configuration information.

Keeping the separation between configuration of the UA and SCTP/IP will also
IMHO serve to increase interoperability and portability of the UAs.

Do you have any interesting cases where the ASP can get away without sending
an ASP Id and the ASP would buckle under the weight of these 8 bytes?

--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]
X-Lotus-FromDomain: MCMAIN@MCEXT
From: Andrew Barrington <[email-masked]>
Sender: Andrew Barrington <[email-masked]>
To: "sigtran" <[email-masked]>
Date: Tue, 17 Jul 2001 08:32:48 +0100
Subject: Re: Re(2): String handling & representation in the info string
field.
X-SMTP-HELO: cvis29.marconicomms.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: cvis29.marconicomms.com [195.99.244.61]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

All,
     It must be said that I originally agreed with Michael and Brians
comments that the info string should not include a null character but was
swayed by the fact that SCTP included a null character in its host name
string. So for consistency I assumed we would prefer to include the null
character. I am happy either way as long as the convention is made clear and
I appreciate the comments.

I'll leave it to Greg to adjudicate.

Thanks,

Andrew

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 17 Jul 2001 03:13:18 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Re(2): String handling & representation in the info string
field.
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.226]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Andrew,

Although adding a null terminating character may be trivial, in the host
name parameter, an implementation which relies on the presence of a null
termination is asking for a buffer overflow vulnerability.

Because secure and robust coding practice dictates that the null termination
should never be relied upon, its presence in either parameter is pointless,
particularly as the length of the string is indicated by other means.

Consider the note in RFC 2960 as pure cruft.  It requires that the
implementor place a useless character at the end of the string.

(It doesn't even really make much sense: it says "at least one" but I don't
know how a Host Name should ever have an null character in the middle of
it... :|

--Brian

Andrew Barrington wrote:              (Tue, 17 Jul 2001 08:32:48)
> 
> 
> All,
>      It must be said that I originally agreed with Michael and Brians
comments
> that the info string should not include a null character but was swayed by
the
> fact that SCTP included a null character in its host name string. So for
> consistency I assumed we would prefer to include the null character. I am
happy
> either way as long as the convention is made clear and I appreciate the
> comments.
> 
> I'll leave it to Greg to adjudicate.
> 
> Thanks,
> 
> Andrew
> 

-- 
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: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
Date: Tue, 17 Jul 2001 12:55:25 +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: [131.228.20.26]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian & Ken,

> I don't have a problem with making ASP Idenfiier in the ASP
> Up message mandatory.  It would be useful for the case
> of remote ASPs in Active/Standby as well as Broadcast
> mode of operattion.

Neither do I.

> However, it is unclear to me that multiple ASPs can share
> the same SCTP endpoints.  Greg - could you please clarify.

My feeling as well.  I've never thought that multiple ASPs in a host could
share the same SCTP endpoints.  

best regards,
John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Fairlie-Cuninghame, Robert" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2PA association endpoint addresses.
Date: Tue, 17 Jul 2001 03:52:02 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: exchange1.nuera.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [12.105.228.79]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Ken (et al),

I was just rereading the M2PA draft again today and had a couple of
questions wrt to version 02.

My comments are concerned with the examples given in 4.1.2 Link Alignment
(yup the 'ol bit about the relationship between IPSP endpoint addresses,
associations and SLC's), specifically, where an IPSP has two or more
endpoint addresses (ie multi-homed) such as in Figure 7.

Now I'm not sure if these examples are contrived just to show how links and
relationships work - why I couldn't see any reasons why you would construct
a system as described (and I couldn't see any disclaimer text to that end). 

My questions are: when an IPSP has two distinct IP endpoint addresses, why
wouldn't you use a single association between the two multi-homed IPSP's? 

Surely this will have better failover characteristics when one interface
fails (ie, the failover is handled transparently in layer two). I noticed
that the use of SCTP multi-homed capabilities is not discussed at all in the
draft especially in contrast to using multiple associations to each endpoint
address. 

I assume it would be desirable to have some layer management status
reporting when a SCTP endpoint addresses is unreachable. As this information
does not affect Layer 3 perhaps this is outside the scope of the draft but
it is still imperative that the operator is informed of any connectivity
failures.

What is Figure 9 trying to show? Is it just another contrived example? Why
would you want to form multiple layer 2 links between the same IP address
set? I'm not saying that it shouldn't be possible to do this but I see no
gain. If it is just an example for generality's sake perhaps there should be
a text saying that it is unlikely that there is any real gain from this
configuration.

Regards,

Robert.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Tue, 17 Jul 2001 09:40:55 -0500
From: Kurt Kite <[email-masked]>
Reply-To: [email-masked]
Organization: Ericsson North America Inc.
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
X-SMTP-HELO: imr1.ericy.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: imr1.ericy.com [208.237.135.240]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

"Brian F. G. Bidulock" wrote:

> Kurt,
>
> Ok.  I think we're on the same page.
>
> Do agree that the SGP cannot determine from local UA
> configuation data?  That it must rely upon SCTP and IP
> configuration data?

The SGPs must know the IP addresses and port numbers used by the ASPs.

>
>
> Your position, if I understand it correctly, is that it is
> sufficient that the SGP rely upon IP addresses and such to
> determine an ASP Id in static IP configurations.
>
> I agree, getting away without ASP Id is possible (but clumsy)
> where:

Thanks. I know that must have been hard for you to admit.

>
>
>     1.    (a)   One Host has only one ASP per SGP.
>
>           or
>
>           (b)   IP Addresses on ASP Hosts are static or
>                 selected from disjoint sets.
>
>           and
>
>     2.    (a)   Only one ASP per Host registers per SGP.
>
>           or
>
>           (b)   Port numbers for ASPs are static or are
>                 selected from disjoint sets.
>
> Situation 1(a) is uninteresting because is goes against
> carrier-grade recommendations.
>
> Situation 1(b) is possible, but precluded by most RFPs
> I've seen which require dynamic addressing... (but wait!)

But not by the ones which do not.

>
>
> Situation 2(a) is uninteresting because is reduces the
> reliability of the overall model by not allowing full mesh
> associations between groups of ASPs and SGPs.
>
> Situation 2(b) requires that both the SGP and the ASP be
> provisioned with static or complex port number assignments
> for each ASP in a host and would be as difficult to
> coordinate as assigning each ASP an ASP Id (or, more
> difficult).
>
> My position is that the SGP should not provision and rely
> on (nor be forced to provision and rely on) layer-below
> information (in this case IP addresses and port numbers)
> even when it might determine the ASP Id in a few cases.
> What I feel that it can be made to rely on is the UA managed
> identifier.
>
> Except in the uninteresting corner cases above, the SGP
> will need to require an ASP identifier anyay.  Making the
> parameter mandatory is the simple thing to do, covers all
> the cases, and relieves both the SGP and ASP from the need
> to rely on layer-below dependent configuration information.
>
> Keeping the separation between configuration of the UA and
> SCTP/IP will also IMHO serve to increase interoperability
> and portability of the UAs.

I understand your position and I don't have a problem with it.
I don't have a problem with an ASP Id.

>
>
> Do you have any interesting cases where the ASP can get
> away without sending an ASP Id and the ASP would buckle
> under the weight of these 8 bytes?

I never indicated that an additional 8 bytes of overhead is a performance
concern. My only point, and it is a simple one, is that it is possible to
determine the identity of an ASP without an ASP Id if static IP addressing
and port number assignment are used. So, I don't think it necessary to make
ASP Id mandatory in all cases. But, I agree that it is a fairly trivial
thing to do and if it does become
mandatory I am not going to lose any sleep over it.

/Kurt

>
>
> --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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 17 Jul 2001 10:31:41 -0700
From: nirmalesh <[email-masked]>
Subject: Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
Sender: root@nodots-daemon
To: "sigtran" <[email-masked]>
Organization: TeleSys
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
X-SMTP-HELO: snfc21.pbi.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mta6.snfc21.pbi.net [206.13.28.240]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi ,
 If you make ASP id as a mandotary field then another issue will  pop up
"how do you manage ASP Ids" across all ASPs , Same ASP Id could be used by
the  different ASPs.
Solution could be :
 There has to be some central  authority who will be allocating the ASP ids
across the system .
  But do we really want to do it  ? Can any one suggest making it automated
!!! or get rid of the
 ASP Id ,as one can achieve with the Static IP and Port No.s

cheers,
Nirmalesh

Kurt Kite wrote:

> "Brian F. G. Bidulock" wrote:
>
> > Kurt,
> >
> > Ok.  I think we're on the same page.
> >
> > Do agree that the SGP cannot determine from local UA
> > configuation data?  That it must rely upon SCTP and IP
> > configuration data?
>
> The SGPs must know the IP addresses and port numbers used
> by the ASPs.
>
> >
> >
> > Your position, if I understand it correctly, is that it is
> > sufficient that the SGP rely upon IP addresses and such to
> > determine an ASP Id in static IP configurations.
> >
> > I agree, getting away without ASP Id is possible (but clumsy)
> > where:
>
> Thanks. I know that must have been hard for you to admit.
>
> >
> >
> >     1.    (a)   One Host has only one ASP per SGP.
> >
> >           or
> >
> >           (b)   IP Addresses on ASP Hosts are static or
> >                 selected from disjoint sets.
> >
> >           and
> >
> >     2.    (a)   Only one ASP per Host registers per SGP.
> >
> >           or
> >
> >           (b)   Port numbers for ASPs are static or are
> >                 selected from disjoint sets.
> >
> > Situation 1(a) is uninteresting because is goes against
> > carrier-grade recommendations.
> >
> > Situation 1(b) is possible, but precluded by most RFPs
> > I've seen which require dynamic addressing... (but wait!)
>
> But not by the ones which do not.
>
> >
> >
> > Situation 2(a) is uninteresting because is reduces the
> > reliability of the overall model by not allowing full mesh
> > associations between groups of ASPs and SGPs.
> >
> > Situation 2(b) requires that both the SGP and the ASP be
> > provisioned with static or complex port number assignments
> > for each ASP in a host and would be as difficult to
> > coordinate as assigning each ASP an ASP Id (or, more
> > difficult).
> >
> > My position is that the SGP should not provision and rely
> > on (nor be forced to provision and rely on) layer-below
> > information (in this case IP addresses and port numbers)
> > even when it might determine the ASP Id in a few cases.
> > What I feel that it can be made to rely on is the UA managed
> > identifier.
> >
> > Except in the uninteresting corner cases above, the SGP
> > will need to require an ASP identifier anyay.  Making the
> > parameter mandatory is the simple thing to do, covers all
> > the cases, and relieves both the SGP and ASP from the need
> > to rely on layer-below dependent configuration information.
> >
> > Keeping the separation between configuration of the UA and
> > SCTP/IP will also IMHO serve to increase interoperability
> > and portability of the UAs.
>
> I understand your position and I don't have a problem with it.
> I don't have a problem with an ASP Id.
>
> >
> >
> > Do you have any interesting cases where the ASP can get
> > away without sending an ASP Id and the ASP would buckle
> > under the weight of these 8 bytes?
>
> I never indicated that an additional 8 bytes of overhead is a performance
> concern. My only point, and it is a simple one, is that it is possible to
determine
> the identity of an ASP without an ASP Id if static IP addressing and port
number
> assignment are used. So, I don't think it necessary to make ASP Id
mandatory
> in all cases. But, I agree that it is a fairly trivial thing to do and if
it does
> become
> mandatory I am not going to lose any sleep over it.
>
> /Kurt
>
> >
> >
> > --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]
>
> ---
> 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: "Tomar, Nitin" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA07: Routing Context assignment
Date: Tue, 17 Jul 2001 10:49:02 -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: [132.233.247.11]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brain, 
 This text is fine for me.
- Nitin.

[snip]
sentence in Section 4.2.4.1 to read:

	The method of Routing Context value assignment at the
	SGP is implementation dependent but must be guaranteed
	to be unique for each Application Server or Routing Key
	served by the SGP.

Would that work for you?

--Brian

Tomar, Nitin wrote:                  (Thu, 12 Jul 2001 13:49:12)
> 
> Hi Greg, Brian,
> 
> Lets assume that its currently not possible to have multiple
> vendor SGPs in a single SG but IMHO we can try to resolve the
> issues as much as possible within the protocol rather than
> keeping it "implementation dependent" and moreover by forcing
> RC assignments to be shared between SGPs, I think the draft is
> going into distributed architecture of M3UA which is a
> proprietary area, well above is my view point and being a
> M3UA-SGP developer I found this approach to be more logical
> for non-distributed M3UA.
> 
> Thanks
> Nitin. 
> 
> -----Original Message-----
> From: Greg Sidebottom [mailto:[email-masked]]
> Sent: Wednesday, July 11, 2001 9:38 PM
> To: sigtran
> Subject: Re: M3UA07: Routing Context assignment
> 
> 
> Hi Nitin, Brian,
> 
> I agree with Brian - I can't see it as currently possible to
> have multiple vendor SGPs in a single SG.  I think I can see
> it as useful for the SGPs to use the same RC values for the
> same RKs while trying to share AS/ASP states and allow
> redirection of traffic between the SGPs.   But assuming this
> is true, then IMHO the Network Appearance values also need to
> be unique across the contained SGPs in an SG as well.
> 
> Cheers,
> 
>    Greg
> 
> ----- Original Message -----
> From: "Brian F. G. Bidulock" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Monday, July 09, 2001 11:09 PM
> Subject: Re: M3UA07: Routing Context assignment
> 
> 
> > Nitin,
> >
> > I don't think that in M3UA07 it is really possible to have
> > multiple SGP from multiple vendors interoperable on just the
> > basis of the M3UA07 spec.  I agree it would be a good thing;
> > however, M3UA07 doesn't really support it.
> >
> > Several times throughout the M3UA07 draft, the SGP are
> > identified as having to present a single SG view, coordinate
> > state between them, and permit rerouting of traffic between
> > them.  In the absence of an SGP to SGP protocol to support
> > interoperability, I don't believe that SGP from multiple
> > vendors will be able to interoperate within an SG.
> >
> > If SGP were allowed to operate in a more "decoupled"
> > fashion, then, your proposal has merit.  However, that is
> > not the case.
> >
> > --Brian
> >
> > Tomar, Nitin wrote:                             (Mon, 09 Jul 2001
> 18:15:40)
> > > Hi All,
> > >
> > >  I have an issue in Routing Context assignment in Dynamic
> > >  RKM procedure and would like to know what other M3UA
> > >  developers think of it.
> > >
> > > Thanks
> > > Nitin.
> > >
> > >
> > > The section 4.2.4.1 of draft 7 states:
> > > 'The method of routing context value assignment at the
> > > SG/SGP is implementation dependent but must be guaranteed
> > > to be unique across all SGPs in an SG'
> > >
> > >
> > > Consider the following scenario:
> > >
> > >         -------------      <-- Reg Req (RK1)
> > >         |   SGP1  |   -----------------------------
> > >         -------------     Reg Rsp (RC1) ->   |
> > >                                                          -------------
> > >                                                          |   ASP1  |
> > >                                                          -------------
> > >                                                                   |
> > >         -------------      <--- Reg Req (RK1)   |
> > >         |   SGP2  |---------------------------------
> > >         -------------      Reg Rsp (RC2) ->
> > >
> > >
> > > SGP1 and SGP2 are part of same SG, also SGP1 and SGP2 are
> > > two different implementations of two different vendors [I
> > > think this is quite possible at least from
> > > interoperability point of view]
> > >
> > > ASP1 wants to register RK1 with SGP1 [sends REG REQ and
> > > get REG RSP as well] and gets RC1 from SGP1, now ASP1
> > > wants to register RK1 with SGP2 and may get RC2 from SGP2
> > > in REG RSP message.
> > >
> > > As per draft, these RC1 and RC2 has to be unique and
> > > implementation dependent, I'm just wondering how this will
> > > be achieved among different implementations.
> > >
> > > I think the above issue can be resolved by just modifying
> > > the definition of Routing Context, Can we explicitly make
> > > the Routing Context's significance restricted between SGP
> > > and ASP [which actually is] exactly similar to what we
> > > have for network appearance, that will remove the
> > > "implementation dependent but must be guaranteed to be
> > > unique" text from the draft  and ASP will be able to
> > > handle both the RCs (RC1 towards SGP1 and RC2 towards
> > > SGP2) for a single RK and will send the ASPAC [RC1]
> > > towards SGP1 and ASPAC [RC2] towards SGP2.
> > >
> > > any comments?
> > >
> > >
> > >
> > >
> > >
> > > ---
> > > 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]
> 
> 
> 
> ---
> 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]
Sender: [email-masked]
Date: Tue, 17 Jul 2001 18:12:04 -0500
From: Tom George <[email-masked]>
Organization: Alcatel USA, Inc.
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M2PA association endpoint addresses.
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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Robert,

Comments below. 

tomG. a.k.a. "et al" 8-)

"Fairlie-Cuninghame, Robert" wrote:
> Hi Ken (et al),
> 
> I was just rereading the M2PA draft again today and had a couple of
> questions wrt to version 02.
> 
> My comments are concerned with the examples given in 4.1.2 Link Alignment
> (yup the 'ol bit about the relationship between IPSP endpoint addresses,
> associations and SLC's), specifically, where an IPSP has two or more
> endpoint addresses (ie multi-homed) such as in Figure 7.
> 
> Now I'm not sure if these examples are contrived just to show how links
and
> relationships work - why I couldn't see any reasons why you would
construct
> a system as described (and I couldn't see any disclaimer text to that
end).
> 
> My questions are: when an IPSP has two distinct IP endpoint addresses, why
> wouldn't you use a single association between the two multi-homed IPSP's?
> 
> Surely this will have better failover characteristics when one interface
> fails (ie, the failover is handled transparently in layer two). I noticed
> that the use of SCTP multi-homed capabilities is not discussed at all in
the
> draft especially in contrast to using multiple associations to each
endpoint
> address.

It may be the case that the hardware does not lend itself to multi-homing.
So I think we want the ability to use multiple links for redundancy.

There is nothing in the M2PA protocol to prevent the use of multi-homing.
The M2PA link corresponds to the SCTP association. If the association is
multi-homed, M2PA works the same. (Almost. M2PA would have to specify the
list of addresses instead of just one address.) SCTP can use its failover
procedure and M2PA does not have to know about it.

I think there is a problem that could happen with multi-homing. (Someone
tell me if I'm wrong.) Compare two configurations. 

   Configuration 1: Figure 7. 

   Configuration 2: looks a lot like Figure 7, but it has only one link with
a multi-homed association (IPA and IPC at IPSP X; IPB and IPD at IPSP Y). 

In configuration 1, say there is a failure at the processor with address
IPB. This should cause a time-controlled changeover to the other link.
The time-control allows messages that went to IPB to clear out before
subsequent messages are sent to IPD. This prevents missequencing.

In configuration 2, if the processor with IPB fails, the SCTP at IPA will
immediately failover to destination IPD. There is no time control.
So there is a potential for missequencing.

> I assume it would be desirable to have some layer management status
> reporting when a SCTP endpoint addresses is unreachable. As this
information
> does not affect Layer 3 perhaps this is outside the scope of the draft but
> it is still imperative that the operator is informed of any connectivity
> failures.

This sounds like an SCTP layer management issue. 

> What is Figure 9 trying to show? Is it just another contrived example? Why
> would you want to form multiple layer 2 links between the same IP address
> set? I'm not saying that it shouldn't be possible to do this but I see no
> gain. If it is just an example for generality's sake perhaps there should
be
> a text saying that it is unlikely that there is any real gain from this
> configuration.

If you wanted to use IPSP X as a "protocol converter box", then you might
want to have an SS7/IP link at IPSP X corresponding to each regular SS7
link. 

I doubt that this will be a popular configuration, but the capability is
there if anyone needs it. 

> Regards,
> Robert.

-- 
* Tom George        972-519-3168         [email-masked]   * *
PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  * *
Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   * * I
actively disclaim speaking for Alcatel USA, Inc. I do not purport * * to
advertise or represent its position,  operations, or activities. *

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
X-Lotus-FromDomain: HSS
To: "sigtran" <[email-masked]>
Date: Wed, 18 Jul 2001 09:42:38 +0530
Subject: M3UA: IPSP-IPSP examples
X-SMTP-HELO: hindon.hss.co.in
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [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]

Hello Greg,

It would be good if the draft could have  some examples for the IPSP-IPSP
scenario in section "5. Examples of M3UA Procedures".
I think it would help clarify things.

thanks and regards,
Harsh

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: A M I T <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Dynamic registration of ASP
Date: Wed, 18 Jul 2001 10:57:17 +0530
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-SMTP-HELO: smtp.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]>
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.2314.1000" name=GENERATOR></HEAD> <BODY>
<DIV><FONT color=#0000ff face=Tahoma size=2><SPAN
class=052372305-18072001>Hi,</SPAN></FONT></DIV> <DIV><FONT color=#0000ff
face=Tahoma size=2><SPAN class=052372305-18072001>Since we do not have any
dynamic registration for ASP in SUA.</SPAN></FONT></DIV> <DIV><FONT
color=#0000ff face=Tahoma size=2><SPAN class=052372305-18072001>How can be
dynamically register an ASP in SUA layer at SG side?</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Tahoma size=2><SPAN
class=052372305-18072001>--Amit</SPAN></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>
From: [email-masked]
X-Lotus-FromDomain: HSS
To: "sigtran" <[email-masked]>
Date: Wed, 18 Jul 2001 15:13:52 +0530
Subject: m2ua AS broadcast mode
X-SMTP-HELO: hindon.hss.co.in
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [202.54.26.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi

Can somebody comment on the following?

1.The draft 09 specifies in sec 4.3.3.4 "The ASPs within a broadcast mode AS
must coordinate between themselves to determine which portion of the
broadcast traffic they will handle."

The broadcast mode requires that all traffic to be sent to all ASPs active
for a given AS.
Does that mean that when a new ASP becomes ACTIVE for an already active AS,
for example, it may receive
"estab confirm" without having sent a "estab request" initially? If yes, is
it expected that when a new ASP becomes ACTIVE for an AS in this mode, it
needs to first get in sync with the another ASP for the link status? Or is
it intended that the ASPs decide  which links (interface ids) of an AS it is
supposed to work with and discard messges received from the SG that do not
pertain to these links.

Or does "traffic" only refers to DATA messages? If so, a clarification may
be added to the draft stating that broadcast is only applicable for DATA
messages.

thanks and regards,
Harsh

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 18 Jul 2001 05:21:46 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: m2ua AS broadcast mode
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-248.dallas.net [209.44.42.248]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Harsh,

Please see comments below...

[email-masked] wrote:                  (Wed, 18 Jul 2001 15:13:52)
> 
> 
> Hi
> 
> Can somebody comment on the following?
> 
> 1.The draft 09 specifies in sec 4.3.3.4
> "The ASPs within a broadcast mode AS must coordinate between
> themselves to determine which portion of the broadcast traffic
> they will handle."
> 
> The broadcast mode requires that all traffic to be sent to all
> ASPs active for a given AS.

> Does that mean that when a new ASP becomes ACTIVE for an
> already active AS, for example, it may receive "estab confirm"
> without having sent a "estab request" initially?

Yes.

> If yes, is it expected that when a new ASP becomes ACTIVE for
> an AS in this mode, it needs to first get in sync with the
> another ASP for the link status?

Yes.  Except that it doesn't have to do so "first", the ASP needs to get in
sync for an IID before it starts reacting to MAUP messages it receives for
that IID: it must also, of course, coordinate with it's ASP peers to ensure
that, say, only one ASP is processing a given IID.

> Or is it intended that the ASPs decide  which links (interface
> ids) of an AS it is supposed to work with and discard messges
> received from the SG that do not pertain to these links.

Yes also.  However, the ASPs may choose to transfer IIDs between them,
syncing state first.  Also, the ASP may not necessarily choose to discard
messages for IIDs for which the ASP is not "responsible".  It may choose to
buffer them a little and keep the state of the IID in sync in the even that
the ASP which is currently responsible for that IID fails.  That is one
purpose of the Correlation Id, so that a broadcast ASP which is
transparently taking over for a failed broadcast ASP for a given IID can
determine which message was last processed by the failed ASP (via ASP-to-ASP
syncronization).

> 
> Or does "traffic" only refers to DATA messages?

No, traffic refers to all MAUP messages.

> If so, a clarification may be added to the draft stating that
> broadcast is only applicable for DATA messages.

No need, it refers to all MAUP messages.

-- 
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: Wed, 18 Jul 2001 08:07:47 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2PA association endpoint addresses.
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]

Pls see one comment below.

Regards,

Ken

At 06:12 PM 7/17/01 -0500, you wrote:
>Robert,
>
>Comments below. 
>
>tomG. a.k.a. "et al" 8-)
>
>"Fairlie-Cuninghame, Robert" wrote:
> > Hi Ken (et al),
> > 
> > I was just rereading the M2PA draft again today and had a couple of
> > questions wrt to version 02.
> > 
> > My comments are concerned with the examples given in 4.1.2 Link
Alignment
> > (yup the 'ol bit about the relationship between IPSP endpoint addresses,
> > associations and SLC's), specifically, where an IPSP has two or more
> > endpoint addresses (ie multi-homed) such as in Figure 7.
> > 
> > Now I'm not sure if these examples are contrived just to show how links
and
> > relationships work - why I couldn't see any reasons why you would
construct
> > a system as described (and I couldn't see any disclaimer text to that
end).
> > 
> > My questions are: when an IPSP has two distinct IP endpoint addresses,
why
> > wouldn't you use a single association between the two multi-homed
IPSP's?
> > 
> > Surely this will have better failover characteristics when one interface
> > fails (ie, the failover is handled transparently in layer two). I
noticed
> > that the use of SCTP multi-homed capabilities is not discussed at all in
the
> > draft especially in contrast to using multiple associations to each
endpoint
> > address.
>
>It may be the case that the hardware does not lend itself to
>multi-homing. So I think we want the ability to use multiple links for
>redundancy.
>
>There is nothing in the M2PA protocol to prevent the use of
>multi-homing. The M2PA link corresponds to the SCTP association. If the
>association is multi-homed, M2PA works the same. (Almost. M2PA would
>have to specify the list of addresses instead of just one address.) SCTP
>can use its failover procedure and M2PA does not have to know about it.
>
>
>I think there is a problem that could happen with multi-homing. (Someone
>tell me if I'm wrong.) Compare two configurations. 
>
>    Configuration 1: Figure 7. 
>
>    Configuration 2: looks a lot like Figure 7, but it has only one link
>with a multi-homed association (IPA and IPC at IPSP X; IPB and IPD at
>IPSP Y). 
>
>In configuration 1, say there is a failure at the processor with address
>IPB. This should cause a time-controlled changeover to the other link.
>The time-control allows messages that went to IPB to clear out before
>subsequent messages are sent to IPD. This prevents missequencing.
>
>In configuration 2, if the processor with IPB fails, the SCTP at IPA
>will immediately failover to destination IPD. There is no time control.
>So there is a potential for missequencing.

There would be no mis-sequencing in this case.  The messages in a SCTP
association are guaranteed to be delivered in-order even if a destination
address fails.

>  
> > I assume it would be desirable to have some layer management status
> > reporting when a SCTP endpoint addresses is unreachable. As this
information
> > does not affect Layer 3 perhaps this is outside the scope of the draft
but
> > it is still imperative that the operator is informed of any connectivity
> > failures.
>
>This sounds like an SCTP layer management issue. 
>
>  
> > What is Figure 9 trying to show? Is it just another contrived example?
Why
> > would you want to form multiple layer 2 links between the same IP
address
> > set? I'm not saying that it shouldn't be possible to do this but I see
no
> > gain. If it is just an example for generality's sake perhaps there
should be
> > a text saying that it is unlikely that there is any real gain from this
> > configuration.
>
>If you wanted to use IPSP X as a "protocol converter box", then you
>might want to have an SS7/IP link at IPSP X corresponding to each
>regular SS7 link. 
>
>I doubt that this will be a popular configuration, but the capability is
>there if anyone needs it. 
>
> > 
> > Regards,
> > 
> > Robert.
>
>
>-- 
>* Tom George        972-519-3168         [email-masked]   *
>* PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
>* Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   *
>* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
>* to advertise or represent its position,  operations, or activities. *
>
>
>---
>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: RE: [SUA] Dynamic registration of ASP
Date: Wed, 18 Jul 2001 16:26:19 +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: [131.228.20.22]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Amit,

> Since we do not have any dynamic registration for ASP in SUA.
> How can be dynamically register an ASP in SUA layer at SG side? 

I actually think the dynamic registration is not needed in SUA.
There has been some discussion & the feeling is that it would overly
complicate the protocol.

br,
John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Kevin McCandless <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M2PA association endpoint addresses.
Date: Wed, 18 Jul 2001 07:20:15 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: rainier.illuminet.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [63.116.20.100]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Tom:

What is the status of the M2PA draft?  I know it currently is version 2 but
when what is the target date for last call?

Thanks,

Kevin

-----Original Message-----
From: Tom George [mailto:[email-masked]] Sent: Tuesday, July 17,
2001 6:12 PM
To: sigtran
Subject: Re: M2PA association endpoint addresses.

Robert,

Comments below. 

tomG. a.k.a. "et al" 8-)

"Fairlie-Cuninghame, Robert" wrote:
> Hi Ken (et al),
> 
> I was just rereading the M2PA draft again today and had a couple of
> questions wrt to version 02.
> 
> My comments are concerned with the examples given in 4.1.2 Link Alignment
> (yup the 'ol bit about the relationship between IPSP endpoint addresses,
> associations and SLC's), specifically, where an IPSP has two or more
> endpoint addresses (ie multi-homed) such as in Figure 7.
> 
> Now I'm not sure if these examples are contrived just to show how links
and
> relationships work - why I couldn't see any reasons why you would
construct
> a system as described (and I couldn't see any disclaimer text to that
end).
> 
> My questions are: when an IPSP has two distinct IP endpoint addresses, why
> wouldn't you use a single association between the two multi-homed IPSP's?
> 
> Surely this will have better failover characteristics when one interface
> fails (ie, the failover is handled transparently in layer two). I noticed
> that the use of SCTP multi-homed capabilities is not discussed at all in
the
> draft especially in contrast to using multiple associations to each
endpoint
> address.

It may be the case that the hardware does not lend itself to multi-homing.
So I think we want the ability to use multiple links for redundancy.

There is nothing in the M2PA protocol to prevent the use of multi-homing.
The M2PA link corresponds to the SCTP association. If the association is
multi-homed, M2PA works the same. (Almost. M2PA would have to specify the
list of addresses instead of just one address.) SCTP can use its failover
procedure and M2PA does not have to know about it.

I think there is a problem that could happen with multi-homing. (Someone
tell me if I'm wrong.) Compare two configurations. 

   Configuration 1: Figure 7. 

   Configuration 2: looks a lot like Figure 7, but it has only one link with
a multi-homed association (IPA and IPC at IPSP X; IPB and IPD at IPSP Y). 

In configuration 1, say there is a failure at the processor with address
IPB. This should cause a time-controlled changeover to the other link.
The time-control allows messages that went to IPB to clear out before
subsequent messages are sent to IPD. This prevents missequencing.

In configuration 2, if the processor with IPB fails, the SCTP at IPA will
immediately failover to destination IPD. There is no time control.
So there is a potential for missequencing.

> I assume it would be desirable to have some layer management status
> reporting when a SCTP endpoint addresses is unreachable. As this
information
> does not affect Layer 3 perhaps this is outside the scope of the draft but
> it is still imperative that the operator is informed of any connectivity
> failures.

This sounds like an SCTP layer management issue. 

> What is Figure 9 trying to show? Is it just another contrived example? Why
> would you want to form multiple layer 2 links between the same IP address
> set? I'm not saying that it shouldn't be possible to do this but I see no
> gain. If it is just an example for generality's sake perhaps there should
be
> a text saying that it is unlikely that there is any real gain from this
> configuration.

If you wanted to use IPSP X as a "protocol converter box", then you might
want to have an SS7/IP link at IPSP X corresponding to each regular SS7
link. 

I doubt that this will be a popular configuration, but the capability is
there if anyone needs it. 

> Regards,
> Robert.

-- 
* Tom George        972-519-3168         [email-masked]   * *
PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  * *
Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   * * I
actively disclaim speaking for Alcatel USA, Inc. I do not purport * * to
advertise or represent its position,  operations, or activities. *

---
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: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07: Routing Context assignment
Date: Wed, 18 Jul 2001 12:00:38 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail3.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail3.rdc1.on.home.com [24.2.9.90]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greetings,

Certainly I agree with Brian/Nitin that from a protocol perspective the RC
only needs to be unique within the SCTP association (i.e., between the SGP
and ASP).  I believe that the original rationale for the SG restriction was
to make it easier for the SGPs to coordinate their AS states within an SG
and re-direct traffic through another SGP when one SGP loses its
connectivity to the AS(P).

But seeing as I think it is possible for the SGPs to coordinate/re-direct
without the restriction (and I haven't seen the proponents of this
restriction defend it at all) I'm considering it as consensus to make the
change below for Issue 8.

Cheers,

   Greg

----- Original Message -----
From: "Tomar, Nitin" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Tuesday, July 17, 2001 1:49 PM
Subject: RE: M3UA07: Routing Context assignment

> Brain,
>  This text is fine for me.
> - Nitin.
>
> [snip]
> sentence in Section 4.2.4.1 to read:
>
> The method of Routing Context value assignment at the
> SGP is implementation dependent but must be guaranteed
> to be unique for each Application Server or Routing Key
> served by the SGP.
>
> Would that work for you?
>
> --Brian
>
>
> Tomar, Nitin wrote:                  (Thu, 12 Jul 2001 13:49:12)
> >
> > Hi Greg, Brian,
> >
> > Lets assume that its currently not possible to have multiple
> > vendor SGPs in a single SG but IMHO we can try to resolve the
> > issues as much as possible within the protocol rather than
> > keeping it "implementation dependent" and moreover by forcing
> > RC assignments to be shared between SGPs, I think the draft is
> > going into distributed architecture of M3UA which is a
> > proprietary area, well above is my view point and being a
> > M3UA-SGP developer I found this approach to be more logical
> > for non-distributed M3UA.
> >
> > Thanks
> > Nitin.
> >
> > -----Original Message-----
> > From: Greg Sidebottom [mailto:[email-masked]]
> > Sent: Wednesday, July 11, 2001 9:38 PM
> > To: sigtran
> > Subject: Re: M3UA07: Routing Context assignment
> >
> >
> > Hi Nitin, Brian,
> >
> > I agree with Brian - I can't see it as currently possible to
> > have multiple vendor SGPs in a single SG.  I think I can see
> > it as useful for the SGPs to use the same RC values for the
> > same RKs while trying to share AS/ASP states and allow
> > redirection of traffic between the SGPs.   But assuming this
> > is true, then IMHO the Network Appearance values also need to
> > be unique across the contained SGPs in an SG as well.
> >
> > Cheers,
> >
> >    Greg
> >
> > ----- Original Message -----
> > From: "Brian F. G. Bidulock" <[email-masked]>
> > To: "sigtran" <[email-masked]>
> > Sent: Monday, July 09, 2001 11:09 PM
> > Subject: Re: M3UA07: Routing Context assignment
> >
> >
> > > Nitin,
> > >
> > > I don't think that in M3UA07 it is really possible to have
> > > multiple SGP from multiple vendors interoperable on just the
> > > basis of the M3UA07 spec.  I agree it would be a good thing;
> > > however, M3UA07 doesn't really support it.
> > >
> > > Several times throughout the M3UA07 draft, the SGP are
> > > identified as having to present a single SG view, coordinate
> > > state between them, and permit rerouting of traffic between
> > > them.  In the absence of an SGP to SGP protocol to support
> > > interoperability, I don't believe that SGP from multiple
> > > vendors will be able to interoperate within an SG.
> > >
> > > If SGP were allowed to operate in a more "decoupled"
> > > fashion, then, your proposal has merit.  However, that is
> > > not the case.
> > >
> > > --Brian
> > >
> > > Tomar, Nitin wrote:                             (Mon, 09 Jul 2001
> > 18:15:40)
> > > > Hi All,
> > > >
> > > >  I have an issue in Routing Context assignment in Dynamic
> > > >  RKM procedure and would like to know what other M3UA
> > > >  developers think of it.
> > > >
> > > > Thanks
> > > > Nitin.
> > > >
> > > >
> > > > The section 4.2.4.1 of draft 7 states:
> > > > 'The method of routing context value assignment at the
> > > > SG/SGP is implementation dependent but must be guaranteed
> > > > to be unique across all SGPs in an SG'
> > > >
> > > >
> > > > Consider the following scenario:
> > > >
> > > >         -------------      <-- Reg Req (RK1)
> > > >         |   SGP1  |   -----------------------------
> > > >         -------------     Reg Rsp (RC1) ->   |
> > >
  -------------
> > > >                                                          |   ASP1  |
  -------------
> > > >                                                                   |
> > > >         -------------      <--- Reg Req (RK1)   |
> > > >         |   SGP2  |---------------------------------
> > > >         -------------      Reg Rsp (RC2) ->
> > > >
> > > >
> > > > SGP1 and SGP2 are part of same SG, also SGP1 and SGP2 are
> > > > two different implementations of two different vendors [I
> > > > think this is quite possible at least from
> > > > interoperability point of view]
> > > >
> > > > ASP1 wants to register RK1 with SGP1 [sends REG REQ and
> > > > get REG RSP as well] and gets RC1 from SGP1, now ASP1
> > > > wants to register RK1 with SGP2 and may get RC2 from SGP2
> > > > in REG RSP message.
> > > >
> > > > As per draft, these RC1 and RC2 has to be unique and
> > > > implementation dependent, I'm just wondering how this will
> > > > be achieved among different implementations.
> > > >
> > > > I think the above issue can be resolved by just modifying
> > > > the definition of Routing Context, Can we explicitly make
> > > > the Routing Context's significance restricted between SGP
> > > > and ASP [which actually is] exactly similar to what we
> > > > have for network appearance, that will remove the
> > > > "implementation dependent but must be guaranteed to be
> > > > unique" text from the draft  and ASP will be able to
> > > > handle both the RCs (RC1 towards SGP1 and RC2 towards
> > > > SGP2) for a single RK and will send the ASPAC [RC1]
> > > > towards SGP1 and ASPAC [RC2] towards SGP2.
> > > >
> > > > any comments?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ---
> > > > 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]
> >
> >
> >
> > ---
> > 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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA (V7) DRST question
Date: Wed, 18 Jul 2001 12:51:22 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail3.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail3.rdc1.on.home.com [24.2.9.90]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Bonsoir(!) Didier

SGP is intended here so no typo - do you see an issue with this?

An SGP could use a DRST to tell the ASP to use another SGP (if possible) for
traffic to the affected destination(s).  If acted upon, this could avoid
inter-SGP traffic, or inter-SG traffic where the SGPs are in different SGs.

Cheers,

   Greg Sidebottom

----- Original Message -----
From: "Desiderio, Didier" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Wednesday, July 18, 2001 12:25 PM
Subject: M3UA (V7) DRST question

> Hi
>
> sentence in section 3.4.6 Destination Restricted (DRST):
>
> "via an alternate SGP of equal priority" : is there a typo here ? It is SG
> instead of SGP, I guess ???
>
> Could someone confirm ?
>
> Thanks and regards,
>
> Didier Desiderio
> COMPAQ - Sophia-Antipolis - France
> > Mail [email-masked]
> > Phone +33 (0) 4 92 95 57 93
> Fax +33 (0) 4 92 95 58 48
>
>
>
>
> ---
> 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]>
Date: Wed, 18 Jul 2001 10:05:05 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Mailer: MailCity Service
Subject: status report
X-Sender-Ip: 63.96.78.21
Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80)
X-SMTP-HELO: shared1-mail.whowhere.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: shared1-batch.whowhere.com [209.185.123.82]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Folks,

The following is a status report on current Sigtran WG activities.  Any
comments or corrections welcome.

We have made fairly slow progress since the last meeting, and still need to
complete the Adaptation Layer work, AS documents and MIB documents, plenty
of stuff still to do.

Here's what I have as current status:

SCTP: now in TSV WG, still resolving error check issue.

IUA:
  Now RFC 3057
  http://ietf.org/internet-drafts/draft-morneault-sigtran-iua-issues-00.txt
lists implementation notes, updated as needed.

M3UA:
  http://ietf.org/internet-drafts/draft-ietf-sigtran-m3ua-07.txt
  now completing comments from WG Last Call, next step
  will be A-D/IESG review.  Standards Track.

M2UA:
  http://ietf.org/internet-drafts/draft-ietf-sigtran-m2ua-09.txt
  now in WG Last Call, ending Friday July 27th. Stds Track.

SUA:
  http://ietf.org/internet-drafts/draft-ietf-sigtran-sua-06.txt
  in line for WG Last Call.  Standards Track.

M2PA:
  http://ietf.org/internet-drafts/draft-ietf-sigtran-m2pa-02.txt
  in line for WG Last Call.  Standards Track.

V5UA:
  http://ietf.org/internet-drafts/draft-ietf-sigtran-v5ua-01.txt
  still work in progress.  Standards Track.

DUA:
  http://search.ietf.org/internet-drafts/draft-anil-sigtran-dua-00.txt
  still work in progress.  Level of interest?

SCTP AS:
 
http://ietf.org/internet-drafts/draft-ietf-sigtran-sctp-applicability-06.txt
  now resolving A-D comments, next 
  step will be A-D/IESG review.  Informational.

Signaling AS:
 
http://ietf.org/internet-drafts/draft-ietf-sigtran-signalling-over-sctp-appl
ic-02.txt
  still work in progress.  Informational.

SCTP MIB:
  http://ietf.org/internet-drafts/draft-ietf-sigtran-sctp-mib-04.txt
  ready for WG Last Call soon.  Standards Track.

M3UA MIB:
  http://ietf.org/internet-drafts/draft-sigtran-m3ua-mib-01.txt
  still work in progress.  Standards Track.

Bakeoff Testing:
  SCTP - 3 bakeoffs done, need at least 1 more
  M3UA - 1 bakeoff done
  IUA  - bakeoff tentatively scheduled with Megaco
  Others - Tbd

Note: There was also a proposal for a TUA, but I read insufficient support
to request this be added to the WG items, especially in view of the number
of items we still need to complete.  If people disagree, this can be raised
at the London meeting, or via the list.

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]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Wed, 18 Jul 2001 13:13:19 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: M2UAv9: Issue#3 Heartbeat
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:

Brian submitted comment regarding the re-addition of Heartbeat and Heartbeat
Ack to M2UA.  Below is a brief discussion on the history of
Heartbeat/Heartbeat Ack in M2UA.  Please review and send in comments
regarding your interest in:

* leaving M2UA as is (i.e. leave out Heartbeat and Heartbeat Ack)

* re-adding Heartbeat and Heartbeat Ack to M2UA

Regards,

Ken

>Greetings,
>
>I don't have an e-mail trail wrt Heartbeat discussions for the M3UA (I am
>not nearly so thorough as Ken!) but there was support for the M3UA
Heartbeat
>from a few places.  As Ken says it was primarily considered useful to run
>M3UA over TCP/UDP but there was some support for using it over SCTP as well
>(M3UA processor separate from SCTP if I recall?).  Also, strategically,
>having a Heartbeat IMHO helps in M3UA acceptance by customers in the
>marketplace as TALI and ISTP (I think) had it as a feature.
>
>I'd prefer to leave it in the M3UA, even if it is "cruft"  2;^)
>
>Cheers,
>
>     Greg
>
>----- Original Message -----
>From: "Ken Morneault" <[email-masked]>
>To: <[email-masked]>
>Cc: "Lyndon Ong" <[email-masked]>; "Greg Sidebottom" <[email-masked]>;
>"John Loughney" <[email-masked]>
>Sent: Tuesday, July 17, 2001 11:19 AM
>Subject: Re: M2UA: Heartbeat
>
>
>
>Brian,
>
>Yes, I believe it was only discussed in regards to M2UA.
>
>If you'd like we can raise this as an issue for M2UA.
>
>Ken
>
>At 09:42 AM 7/17/01 -0500, Brian F. G. Bidulock wrote:
> >Ken,
> >
> >Well, the other way to get consistency would be
> >to remove the BEAT from M3UA and SUA.  I agree
> >that it could be easily covered in an extension
> >draft for transport which might need it.
> >
> >Was the concensus in December just for M2UA?
> >
> >--Brian
> >
> >On Tue, 17 Jul 2001, Ken Morneault wrote:
> >
> > >
> > >
> > > Brian,
> > >
> > > I looked back at the history trail left in email.  In Nov '00, you
sent
> > > an email titled "Issue #13 - Heartbeat/Other Transport Layers".  You
> > > asked for Heartbeat to be removed because it was "cruft".  There
> > > was some discussion on the email list.  At the December meeting,
> > > it was discussed again and the consensus was that it should
> > > be removed.  The consensus was summarized in some email during
> > > December.  I can send you the emails if you'd like to review them.
> > >
> > > I *believe* the general feeling was that it would not be useful if
> > > SCTP was used.  If someone wanted to specify M2UA with TCP,
> > > then they could write a draft that described how it would work.
> > >
> > > Regards,
> > >
> > > Ken
> > >
> > > At 03:24 AM 7/17/01 -0500, Brian F. G. Bidulock wrote:
> > > >Ken,
> > > >
> > > >Is there some reason why the BEAT and BEAT ACK ASPSM messages
> > > >are not applicable to M2UA when they are applicable to M3UA?
> > > >It appears that M2UA has the same text permiting non-SCTP
> > > >transport as an option. (TCP is mentioned.)
> > > >
> > > >It would improve consistency between the UAs to add the BEAT
> > > >and BEAT ACK text from M3UA sections 3.5.5, 3.5.6, and 4.2.3.7
> > > >to M2UA.
> > > >
> > > >--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: Wed, 18 Jul 2001 13:15:22 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: M2UAv9: Issue #4 ASP Down Reason Parameter
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:

Brian also submitted a comment regarding the Reason parameter in the ASP
Down message.  Below is a brief discussion to try to determine reasons for
the Reason parameter.

Please provide justifications for the Reason parameter or it will be
removed.

Regards,

Ken

>Hi Ken et al
>
>The M3UA Reason parameter was originally intended to supply a reason to the
>receiver of the ASP-Down, but only to provide additional information to
>Layer Management (Logs/Alarms etc).  There was no tie to a future extension
>draft.  The "management blocking" reason parameter was originally useful in
>the ASP Down Ack message but in Issue 7 the ASP-Down Ack response to an
>ASP-Up was removed.
>
>I agree that it should be removed - even being optional is kind of lame.
>It could be made optional but only if we can think of some other reasons
>that make more sense.
>
>Cheers,
>
>   Greg Sidebottom
>
>----- Original Message -----
>From: "Ken Morneault" <[email-masked]>
>To: <[email-masked]>; "Lyndon Ong" <[email-masked]>
>Cc: "Greg Herlein" <[email-masked]>; "John Grana" <[email-masked]>;
><[email-masked]>; <[email-masked]>; <[email-masked]>
>Sent: Tuesday, July 17, 2001 11:15 AM
>Subject: Re: M2UA: Reason Parameter in ASP Down (Ack)
>
>
> >
> >
> > Brian,
> >
> > Based on previous email discussions, I have no problem with
> > removing the Reason parameter since there is no specified
> > purpose for its existence.  I have not removed it from M2UA
> > because I was waiting for further comments as to whether
> > or not it should be removed from M2UA/M3UA/SUA.
> > Unfortunately, there were no comments.
> >
> > Greg, John - what do you think?
> >
> > Regards,
> >
> > Ken
> >
> > At 04:32 AM 7/17/01 -0500, Brian F. G. Bidulock wrote:
> > >Ken,
> > >
> > >Again, the Reason parameter in the ASP Down (Ack) messages
> > >can only take on one value.
> > >
> > >This is also applicable to IUA and SUA.  M3UA at least
> > >adds the values Unspecified and User Part Unavailable.
> > >
> > >While SUA and M3UA mark this parameter as Mandatory, IAU
> > >and M2UA do not mark this parameter as mandatory or optional.
> > >
> > >Certainly a parameter which conveys no information should
> > >be optional...
> > >
> > >I would like the see that parameter marked Optional and
> > >leave it to some extension draft to indicate when the
> > >parameter is required if it adds new values to the parameter.
> > >
> > >I mean, really, what is this parameter but a placeholder
> > >for some extension draft anyway.
> > >
> > >SUA makes the parameter mandatory, but it has only one
> > >value.  This does not make sense.  SUA should mark the
> > >parameter optional.
> > >
> > >M3UA makes the parameter mandatory, yet allows a reason
> > >of "Unspecified".  This does not make sense either.  If
> > >one can get away under some circumstances in not specifying
> > >the reason (setting it to "unspecified") then there is
> > >equal justification for leaving the parameter out of the
> > >message.
> > >
> > >All UAs should mark this parameter as optional and describe
> > >when it must be placed in the message in the procedure which
> > >requires its value.
> > >
> > >--
> > >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: "Garnero, Pierre" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA (V7) DRST question
Date: Wed, 18 Jul 2001 19:31:42 +0200
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: zcamail04.zca.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: zcamail04.zca.compaq.com [161.114.32.104]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Greg,

well yes, we see an issue... :-)

In the "1.2 Terminology" chapter we read:

" Signalling Gateway - An SG .......
- An SG appears to the SS7 network as an SS7 signalling point...."

=> so, on a specific SS7 network, the SG is identified by a unique PC.

Then how traffic could be diverted to another SGP in the same SG when an ASP
has received a DRST (or DUNA) message ?

I suppose that in most of the cases, a DRST is sent by an SGP that has
received a TFR from its SS7 side. If this assumption is true, the ASP must
not send traffic to an alternate SGP that is in the same SG. It must choose
another "route" (if there is one with equal priority) then, another SG...
???

Cheers,

Pierre

-----Original Message-----
From: Greg Sidebottom [mailto:[email-masked]] Sent: Wednesday, July 18,
2001 6:51 PM
To: sigtran
Subject: Re: M3UA (V7) DRST question

Bonsoir(!) Didier

SGP is intended here so no typo - do you see an issue with this?

An SGP could use a DRST to tell the ASP to use another SGP (if possible) for
traffic to the affected destination(s).  If acted upon, this could avoid
inter-SGP traffic, or inter-SG traffic where the SGPs are in different SGs.

Cheers,

   Greg Sidebottom

----- Original Message -----
From: "Desiderio, Didier" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Wednesday, July 18, 2001 12:25 PM
Subject: M3UA (V7) DRST question

> Hi
>
> sentence in section 3.4.6 Destination Restricted (DRST):
>
> "via an alternate SGP of equal priority" : is there a typo here ? It is SG
> instead of SGP, I guess ???
>
> Could someone confirm ?
>
> Thanks and regards,
>
> Didier Desiderio
> COMPAQ - Sophia-Antipolis - France
> > Mail [email-masked]
> > Phone +33 (0) 4 92 95 57 93
> Fax +33 (0) 4 92 95 58 48
>
>
>
>
> ---
> 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: "Tomar, Nitin" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA06: Routing Key Management procedure
Date: Wed, 18 Jul 2001 10:58:58 -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: [132.233.247.11]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greg, Brian,

Please see response below.

-Nitin

[snip]
> > > 1. Is RKM procedure valid for IPSP-IPSP communication as well? In
> > > either case I think the draft can specify it clearly in section
> > > 3.5.5 and related sections. If RKM is allowed for IPSP-IPSP
> > > scenario, can client and server both initiate REG-REQ and 
> DEREG-REQ
> > > messages, I do not find any reason they should not do so.
> > 
> > [Greg] I agree that RKM should be possible for IPSP-to IPSP but this
> > is not an application that I have an interest.  I'm not sure though
> > that it makes sense to register in both directions point-to-point to
> > set up a two way communication.  I see that currently ASPs 
> use the REG
> > REQ to set-up two way traffic with the SG - the SG doesn't need a
> > separate procedure to register for which traffic it wants from the
> > ASP, as it is usually related.  But I suppose there could be an
> > application to Register in both directions to set up two sets of
> > two-way traffic beween IPSPs.  Do people need this described?
> > 
> > [Nitin] I may be missing something here, do you mean that 
> with REG REQ
> > message an ASP can specify an SGP that what traffic it'll be sending
> > towards it, if so how an SGP will come to know that the traffic
> > related to the RK specified in REG REQ message is handled by ASP or
> > the ASP wants to send this traffic to SGP.
> 
> [Brian] This is stiking on an SGP issue which has been raised several
times.
> How does the SGP know what traffic it is to receive?
> 
> These issues are all related.  Placing the Routing Context in the DATA
> message permits the the SGP to screen the DATA messages on 
> the basis of
> valid Routing Contexts.  Breaking the routing label into parameters
> permits the SG to screen the routing label without parsing the DATA
> payload (after the ASP has just finished packing it).
> 
> Placing the restriction that the ASP can only send messages to an SGP
> which have the symmetrical Routing Key associated with the Routing
> Context permits the SGP to know what traffic it is expected to process
> when a REG REQ is performed and screen the messages per above when the
> messages actually arrive.

[Nitin] Brian can you please specify some example of a 'symmetrical Routing
Key'
  so that I can understand what type of Routing Key ASP can register with
SGP.

[snip] 
> > >
> > > 3. In section 4.3.4.1 and 4.3.4.2, The draft does not 
> specifies any
> > > timers associated with the REG REQ and DEREG REQ messages, I think
> > > there is a need for timers for RKM messages, as an ASP 
> can not wait
> > > indefinitely for the REG RSP if SG decides to respond to REG REQ
> > > containing multiple RKs with multiple REG RSP messages'
> > >
> > > The timer can be similar to what we have for ASPM messages,
> > > something like this:
> > >
> > > 'When ASP sends an REG REQ it starts timer T(RK-ack). If the ASP
> > > does not receive a response to REG REQ within T(RK-ack), 
> the ASP may
> > > restart T(RK-ack) and resend REG REQ messages until it receives an
> > > REG REQ message.  T(RK-ack) is provisionable, with a default of n
> > > seconds. Alternatively, retransmission of REG RSP messages may be
> > > put under control of Layer Management'
> > >
> > 
> > [Greg] Actually I think that these timers of marginal use, allowing
> > the resending of a message for which there is no response.  I see it
> > as useful for ASP Up/Down, and for ASP Active/Inact and 
> REG/DEREG when
> > there is only one contained request (e.g., RK/RC).  But for ASP
> > Active/Inact and REG/DEREG with more than one request, they are not
> > very useful.  Robust implementations should probably run a timer per
> > request (RK or RC), not per message.  An implemenation can't leave
> > these requests open indefinitely - if there is no reponse 
> to a request
> > the application will have to take action to retry or close it.  Per
> > this text, and the current ASP Active text, if a REG RESP 
> is received
> > containing a result for only one of two requests, then the Timer is
> > cancelled and we still have an outstanding request.  There 
> are also I
> > think possible cases where a "response" is ambiguous, at 
> least for ASP
> > Active messages that are errored.
> > 
> > So I think we have a couple of options: 1) add REG/DEREG 
> timers ) on a
> > per/transaction basis (and change ASP-Active/Inactive timers), 2)
> > remove the explicit message timers and add text saying that the
> > sending application should run a timer to close/resend each request,
> > or 3) remove the text.  Views?
> > 
> > [Nitin] I'm in favor of 1st option, as this issue is 
> related to timers
> > for ASP-Active/Inactive too, it makes more sense to have these
> > per/transaction basis, that may cause a bit more handling in the
> > protocol but it will ensure the consistency among the ASPM and DRKM
> > procedures.
> 
> [Brian] For the current T(ack) timer, control is essentially placed 
> in the hands
> of management: either management runs its own algorithm, or when the
> timer expires management is informed of the failure.  
> 
> What this timer really accomplishes is seeing if the SG is dead on a
> valid SCTP association.  I don't know how an SG could be 
> "dead" for one
> RK contained in a REG REQ but "alive" for another.  I like the idea of
> cancelling the timer when when any REG RESP pertaining to the sent REG
> REQ is returned.  That would mean that the ASP could do something like
> assume that the SG is dead and, say, cycle the SCTP 
> association under LM
> control.
> 
> I like with 1) and Nitin's text (with the exception that the timer is
> cancelled when the first REG RESP message with a result pertaining to
> the original REG REQ is received, and the addition of management
> primitives M-REQ_REQ and M-REG_RESP so that management can 
> also control
> the situation as is currently provided for ASP_UP).
> 
[Nitin] Brian, This looks reasonable and shall be added into the draft.

[snip]
> > > 6. The 'Registration Status' parameter values in REG RSP message
> > > need one more type of error value : 'Multiple SI not supported' as
> > > none of the existing error value cover this [In case SG optionally
> > > support only one SI in a Routing key as per section 1.4.2.2].
> > >
> > 
> > [Greg} I can add this. Actually there are a few more error 
> values that
> > probably make sense. - "Invalid SI" , OPC, CIC Range, SSN", for
> > example.  Others?
> 
> [Brian] Let's not get into adding a whole but of error codes here...
> 
> I think that Nitin's example is adequately covered under the "Error -
> Invalid Routing Key" per the description in the on Page 79 of M3UA-07:
> 
> 	"If the SGP determines that the received Routing Key data is
> 	invalid, or contains invalid parameter values, the SGP returns a
> 	Registration Response message to the ASP, containing a
> 	Registration Result "Error - Invalid Routing Key", "Error -
> 	Invalid DPC", "Error - Invalid Network Appearance" as
> 	appropriate."
> 
> Rather than getting into a long list of error results, why not add an
> optional INFO String to the Registration Status which can contain
> additional implementation specific or diagnostic information.
> 
[Nitin] Yes, Optional INFO string will solve the purpose.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 18 Jul 2001 13:24:55 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA-07: minor error
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-248.dallas.net [209.44.42.248]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

Sorry... I can't read (missed the "(Standby)").  The text is fine.

--Brian

On Fri, 13 Jul 2001, Brian F. G. Bidulock wrote:

> Greg,
> 
> In the second to last paragraph of section 4.2.3.4 (in the middle
> of page 76 of v7), first sentence:
> 
> 	In the case of a Load-share (Standby) mode AS, the traffic is not 
> 	started to the ASP until the SGP or IPSP determines that there are 
> 	insufficient resources available in the AS.  ...
> 
> This should be "sufficient" instead of "insufficient".
> 
> --Brian
> 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 18 Jul 2001 13:38:58 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA06: Routing Key Management procedure
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.248]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Nitin,

By symmetrical RK, I meant the same routing key as in the forward direction
but with point codes reversed.

For example: If the SG routes all traffic for OPC=a, DPC=b, CIC=x-y, to the
ASP, it only expects traffic for OPC=b, DPC=a, CIC=x-y from the ASP.

--brian

Tomar, Nitin wrote:                   (Wed, 18 Jul 2001 10:58:58)

[snip]
> > 
> > Placing the restriction that the ASP can only send messages to
> > an SGP which have the symmetrical Routing Key associated with
> > the Routing Context permits the SGP to know what traffic it is
> > expected to process when a REG REQ is performed and screen the
> > messages per above when the messages actually arrive.
> 
> [Nitin] Brian can you please specify some example of a
> 'symmetrical Routing Key' so that I can understand what type of
> Routing Key ASP can register with SGP.
>
[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: Kevin McCandless <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: status report
Date: Wed, 18 Jul 2001 11:45:38 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: rainier.illuminet.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [63.116.20.100]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Lyndon:

Exactly what I have been looking for!

Thanks.....

Kevin

-----Original Message-----
From: Lyndon Ong [mailto:[email-masked]] Sent: Wednesday, July
18, 2001 12:05 PM To: sigtran
Subject: status report

Folks,

The following is a status report on current Sigtran WG activities.  Any
comments or corrections welcome.

We have made fairly slow progress since the last meeting, and still need to
complete the Adaptation Layer work, AS documents and MIB documents, plenty
of stuff still to do.

Here's what I have as current status:

SCTP: now in TSV WG, still resolving error check issue.

IUA:
  Now RFC 3057
  http://ietf.org/internet-drafts/draft-morneault-sigtran-iua-issues-00.txt
lists implementation notes, updated as needed.

M3UA:
  http://ietf.org/internet-drafts/draft-ietf-sigtran-m3ua-07.txt
  now completing comments from WG Last Call, next step
  will be A-D/IESG review.  Standards Track.

M2UA:
  http://ietf.org/internet-drafts/draft-ietf-sigtran-m2ua-09.txt
  now in WG Last Call, ending Friday July 27th. Stds Track.

SUA:
  http://ietf.org/internet-drafts/draft-ietf-sigtran-sua-06.txt
  in line for WG Last Call.  Standards Track.

M2PA:
  http://ietf.org/internet-drafts/draft-ietf-sigtran-m2pa-02.txt
  in line for WG Last Call.  Standards Track.

V5UA:
  http://ietf.org/internet-drafts/draft-ietf-sigtran-v5ua-01.txt
  still work in progress.  Standards Track.

DUA:
  http://search.ietf.org/internet-drafts/draft-anil-sigtran-dua-00.txt
  still work in progress.  Level of interest?

SCTP AS:
 
http://ietf.org/internet-drafts/draft-ietf-sigtran-sctp-applicability-06.txt
  now resolving A-D comments, next 
  step will be A-D/IESG review.  Informational.

Signaling AS:
 
http://ietf.org/internet-drafts/draft-ietf-sigtran-signalling-over-sctp-appl
ic-02.txt
  still work in progress.  Informational.

SCTP MIB:
  http://ietf.org/internet-drafts/draft-ietf-sigtran-sctp-mib-04.txt
  ready for WG Last Call soon.  Standards Track.

M3UA MIB:
  http://ietf.org/internet-drafts/draft-sigtran-m3ua-mib-01.txt
  still work in progress.  Standards Track.

Bakeoff Testing:
  SCTP - 3 bakeoffs done, need at least 1 more
  M3UA - 1 bakeoff done
  IUA  - bakeoff tentatively scheduled with Megaco
  Others - Tbd

Note: There was also a proposal for a TUA, but I read insufficient support
to request this be added to the WG items, especially in view of the number
of items we still need to complete.  If people disagree, this can be raised
at the London meeting, or via the list.

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]
From: Kevin McCandless <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: status report
Date: Wed, 18 Jul 2001 12:55:24 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: rainier.illuminet.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [63.116.20.100]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Lyndon:

Another issue is the TUA you raised in this email.  We did an internal
review of SUA and TUA and had a concern that TUA would be required to
transmit MAP and IANA messages.  We are satisfied with SUA as long as it
will handle Map, Cap, Tcap. 

Sincerely,

Kevin McCandless 
Senior Network Planner 
Illuminet 
913-814-6397 
[email-masked] 

-----Original Message-----
From: Lyndon Ong [mailto:[email-masked]] Sent: Wednesday, July
18, 2001 12:05 PM To: sigtran
Subject: status report

Folks,

The following is a status report on current Sigtran WG activities.  Any
comments or corrections welcome.

We have made fairly slow progress since the last meeting, and still need to
complete the Adaptation Layer work, AS documents and MIB documents, plenty
of stuff still to do.

Here's what I have as current status:

SCTP: now in TSV WG, still resolving error check issue.

IUA:
  Now RFC 3057
  http://ietf.org/internet-drafts/draft-morneault-sigtran-iua-issues-00.txt
lists implementation notes, updated as needed.

M3UA:
  http://ietf.org/internet-drafts/draft-ietf-sigtran-m3ua-07.txt
  now completing comments from WG Last Call, next step
  will be A-D/IESG review.  Standards Track.

M2UA:
  http://ietf.org/internet-drafts/draft-ietf-sigtran-m2ua-09.txt
  now in WG Last Call, ending Friday July 27th. Stds Track.

SUA:
  http://ietf.org/internet-drafts/draft-ietf-sigtran-sua-06.txt
  in line for WG Last Call.  Standards Track.

M2PA:
  http://ietf.org/internet-drafts/draft-ietf-sigtran-m2pa-02.txt
  in line for WG Last Call.  Standards Track.

V5UA:
  http://ietf.org/internet-drafts/draft-ietf-sigtran-v5ua-01.txt
  still work in progress.  Standards Track.

DUA:
  http://search.ietf.org/internet-drafts/draft-anil-sigtran-dua-00.txt
  still work in progress.  Level of interest?

SCTP AS:
 
http://ietf.org/internet-drafts/draft-ietf-sigtran-sctp-applicability-06.txt
  now resolving A-D comments, next 
  step will be A-D/IESG review.  Informational.

Signaling AS:
 
http://ietf.org/internet-drafts/draft-ietf-sigtran-signalling-over-sctp-appl
ic-02.txt
  still work in progress.  Informational.

SCTP MIB:
  http://ietf.org/internet-drafts/draft-ietf-sigtran-sctp-mib-04.txt
  ready for WG Last Call soon.  Standards Track.

M3UA MIB:
  http://ietf.org/internet-drafts/draft-sigtran-m3ua-mib-01.txt
  still work in progress.  Standards Track.

Bakeoff Testing:
  SCTP - 3 bakeoffs done, need at least 1 more
  M3UA - 1 bakeoff done
  IUA  - bakeoff tentatively scheduled with Megaco
  Others - Tbd

Note: There was also a proposal for a TUA, but I read insufficient support
to request this be added to the WG items, especially in view of the number
of items we still need to complete.  If people disagree, this can be raised
at the London meeting, or via the list.

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]
From: Michael Tüxen <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Comment for the RFC-2960-bis draft.
Date: Wed, 18 Jul 2001 22:26:05 +0200
X-Mailer: CTM PowerMail 3.0.9 carbon <http://www.ctmdev.com>
X-SMTP-HELO: ilsa.franken.de
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ilsa.franken.de [193.175.24.42]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Dear all,
my understanding is that you send an SACK for every second packet containing
DATA chunks.

This means for example you can receive a packet with 10 DATA chunks you
start the delayed ACK timer and send a SACK when it runs off. If you receive
another packet with DATA chunks you send a SACK acknowledging the DATA
chunks of both packets.

You should not send a SACK in resond to control chunks unless it is
specified elsewhere, for example after having received a SHUTDOWN or so.

Best regards
Michael
-- 
e-mail: [email-masked]

On Wed, Jul 18, 2001, Andreas Jungmaier <[email-masked]> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Dear all,
>
>I have a remark for section 6.2. of the current RFC 2960 respectively
>the same section in the document draft-ietf-tsvwg-rfc2960-bis-00.txt
>
>It says there:
>
> 6.2  Acknowledgement on Reception of DATA Chunks
>
>   The SCTP endpoint MUST always acknowledge the reception of each valid
>   DATA chunk.
>
>   The guidelines on delayed acknowledgement algorithm specified in
>   Section 4.2 of [RFC2581] SHOULD be followed.  Specifically, an
>   acknowledgement SHOULD be generated for at least every second packet
>   (not every second DATA chunk) received, and SHOULD be generated
>   within 200 ms of the arrival of any unacknowledged DATA chunk.
>
>Now, it is, IMHO, not clear from that section whether that 
>only applies to packets containing data chunks (as one could
>think according to the section header), or it applies to
>_all_ packets (well, it says "EVERY SECOND PACKET"). 
>
>I am not sure whether it would make sense to send
>a SACK after two Heartbeat chunks have been received ?!
>
>Any comments ?
>
>
>Best regards, 
>
>Andreas Jungmaier
>
>- ----------------------------------
------------------------------------------
> \|/ _____ \|/    Andreas Jungmaier, Dipl.-Ing. 
> "@'/ , . \`@"    University of Essen           [email-masked]
> /_| \___/ |__\   -> Computer Networking        Tel. : +49 (0201) 183-7636
>    \___U_/          Technology Group <-
>- ----------------------------------
------------------------------------------
>PGP Public Key and Fingerprint: see http://www.exp-math.uni-essen.de/~ajung
>
>- ----------------------------------
------------------------------------------
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.0.5 (GNU/Linux)
>Comment: For info see http://www.gnupg.org
>
>iD8DBQE7Vg9gd2Uw+xBvGUIRAkdnAJ92WGOZOS4Pd3rwKF/GtBsBcD9QTQCgns3V
>Hql19wXuTlwQDf1yxGYnA3Q=
>=PP9M
>-----END PGP SIGNATURE-----
>
>
>---
>You are currently subscribed to sigtran as:
[email-masked]
>To unsubscribe send a blank email to leave-sigtran-
>[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA (V7) DRST question
Date: Wed, 18 Jul 2001 16:28:54 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail3.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail3.rdc1.on.home.com [24.2.9.90]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Pierre,

Response below ..

----- Original Message -----
From: "Garnero, Pierre" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Wednesday, July 18, 2001 1:31 PM
Subject: RE: M3UA (V7) DRST question

> Hi Greg,
>
> well yes, we see an issue... :-)
>
> In the "1.2 Terminology" chapter we read:
>
> " Signalling Gateway - An SG .......
> - An SG appears to the SS7 network as an SS7 signalling point...."
>
> => so, on a specific SS7 network, the SG is identified by a unique PC.
>

[Greg] Yes.

> Then how traffic could be diverted to another SGP in the same SG when an
ASP
> has received a DRST (or DUNA) message ?

[Greg] I'm not sure that I see the problem yet.  From the ASP perspective it
need only know that it has two equal routes to the affected destination, via
two (for example) SGPs.  If the ASP receives a DRST from one of them , then
the ASP could optionally re-direct outgoing traffic via the other SGP.
Both SGPs are part of the same SG, and therefore share the same point code -
but remember that this point code is not the affected destination.

>
> I suppose that in most of the cases, a DRST is sent by an SGP that has
> received a TFR from its SS7 side.

[Greg] Not necessarily.  I think a DRST could result from a received TFR
directly only in the case where the two SGPs have no connectivity between
them (i.e. if the SGP has no other routes to the affected destination).  But
we also state that SGPs should share MTP3/AS/ASP state and re-direct traffic
between themselves, so I don't think this is a normal case.

A TFR is always consumed by the SG MTP3 state machine.  If one SGP gets a
TFR on a route it must update the other SGP and hold a common route/routeset
state because the MTP3 management has no concept of SGPs forming an SG.

If this assumption is true, the ASP must
> not send traffic to an alternate SGP that is in the same SG. It must
choose
> another "route" (if there is one with equal priority) then, another SG...
> ???
>

[Greg] I don't follow you here.  Even if the assumption is true (e.g.,
failure of inter-SGP communication), why can't the ASP send the traffic via
the other SGP?  The ASP has two equal routes to the affected destination and
has received a DRST wrt one of the routes.

Cheers,

   Greg

>
> Cheers,
>
> Pierre
>
>
>
> -----Original Message-----
> From: Greg Sidebottom [mailto:[email-masked]]
> Sent: Wednesday, July 18, 2001 6:51 PM
> To: sigtran
> Subject: Re: M3UA (V7) DRST question
>
>
> Bonsoir(!) Didier
>
> SGP is intended here so no typo - do you see an issue with this?
>
> An SGP could use a DRST to tell the ASP to use another SGP (if possible)
for
> traffic to the affected destination(s).  If acted upon, this could avoid
> inter-SGP traffic, or inter-SG traffic where the SGPs are in different
SGs.
>
> Cheers,
>
>    Greg Sidebottom
>
> ----- Original Message -----
> From: "Desiderio, Didier" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Wednesday, July 18, 2001 12:25 PM
> Subject: M3UA (V7) DRST question
>
>
> > Hi
> >
> > sentence in section 3.4.6 Destination Restricted (DRST):
> >
> > "via an alternate SGP of equal priority" : is there a typo here ? It is
SG
> > instead of SGP, I guess ???
> >
> > Could someone confirm ?
> >
> > Thanks and regards,
> >
> > Didier Desiderio
> > COMPAQ - Sophia-Antipolis - France
> > > Mail [email-masked]
> > > Phone +33 (0) 4 92 95 57 93
> > Fax +33 (0) 4 92 95 58 48
> >
> >
> >
> >
> > ---
> > 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: Wed, 18 Jul 2001 16:00:01 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA (V7) DRST question
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-248.dallas.net [209.44.42.248]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

The behavior makes sense the way you describe it.  In makes sense to leave
it as SGP instead of SG.

Although it may appear on the surface that an implementation could use DRST
for some sort of soft load-balancing across SGP, it should give
consideration to the need for controlled rerouting of traffic flows between
SGP to avoid mis-sequencing of the traffic within an SLS.  That is, before
changing traffic from one SGP to another (whether SG to SG or not), the ASP
should withold messages for that traffic flow for a duration.

The addition of an optional Correlation Id and Ack would give the ASP the
ability to perform a changeback-like procedure where it can be assured that
a traffic flow has been acknolwedged as processed before restarting traffic
on a new flow.

--Brian

Greg Sidebottom wrote:                       (Wed, 18 Jul 2001 16:28:54)
> Hi Pierre,
> 
> Response below ..
> 
> ----- Original Message -----
> From: "Garnero, Pierre" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Wednesday, July 18, 2001 1:31 PM
> Subject: RE: M3UA (V7) DRST question
> 
> 
> > Hi Greg,
> >
> > well yes, we see an issue... :-)
> >
> > In the "1.2 Terminology" chapter we read:
> >
> > " Signalling Gateway - An SG .......
> > - An SG appears to the SS7 network as an SS7 signalling point...."
> >
> > => so, on a specific SS7 network, the SG is identified by a unique PC.
> >
> 
> [Greg] Yes.
> 
> > Then how traffic could be diverted to another SGP in the same SG when an
> ASP
> > has received a DRST (or DUNA) message ?
> 
> [Greg] I'm not sure that I see the problem yet.  From the ASP perspective
it
> need only know that it has two equal routes to the affected destination,
via
> two (for example) SGPs.  If the ASP receives a DRST from one of them ,
then
> the ASP could optionally re-direct outgoing traffic via the other SGP.
> Both SGPs are part of the same SG, and therefore share the same point code
-
> but remember that this point code is not the affected destination.
> 
> >
> > I suppose that in most of the cases, a DRST is sent by an SGP that has
> > received a TFR from its SS7 side.
> 
> [Greg] Not necessarily.  I think a DRST could result from a received TFR
> directly only in the case where the two SGPs have no connectivity between
> them (i.e. if the SGP has no other routes to the affected destination).
But
> we also state that SGPs should share MTP3/AS/ASP state and re-direct
traffic
> between themselves, so I don't think this is a normal case.
> 
> A TFR is always consumed by the SG MTP3 state machine.  If one SGP gets a
> TFR on a route it must update the other SGP and hold a common
route/routeset
> state because the MTP3 management has no concept of SGPs forming an SG.
> 
> 
> If this assumption is true, the ASP must
> > not send traffic to an alternate SGP that is in the same SG. It must
> choose
> > another "route" (if there is one with equal priority) then, another
SG...
> > ???
> >
> 
> [Greg] I don't follow you here.  Even if the assumption is true (e.g.,
> failure of inter-SGP communication), why can't the ASP send the traffic
via
> the other SGP?  The ASP has two equal routes to the affected destination
and
> has received a DRST wrt one of the routes.
> 
> Cheers,
> 
>    Greg
> 
> >
> > Cheers,
> >
> > Pierre
> >
> >
> >
> > -----Original Message-----
> > From: Greg Sidebottom [mailto:[email-masked]]
> > Sent: Wednesday, July 18, 2001 6:51 PM
> > To: sigtran
> > Subject: Re: M3UA (V7) DRST question
> >
> >
> > Bonsoir(!) Didier
> >
> > SGP is intended here so no typo - do you see an issue with this?
> >
> > An SGP could use a DRST to tell the ASP to use another SGP (if possible)
> for
> > traffic to the affected destination(s).  If acted upon, this could avoid
> > inter-SGP traffic, or inter-SG traffic where the SGPs are in different
> SGs.
> >
> > Cheers,
> >
> >    Greg Sidebottom
> >
> > ----- Original Message -----
> > From: "Desiderio, Didier" <[email-masked]>
> > To: "sigtran" <[email-masked]>
> > Sent: Wednesday, July 18, 2001 12:25 PM
> > Subject: M3UA (V7) DRST question
> >
> >
> > > Hi
> > >
> > > sentence in section 3.4.6 Destination Restricted (DRST):
> > >
> > > "via an alternate SGP of equal priority" : is there a typo here ? It
is
> SG
> > > instead of SGP, I guess ???
> > >
> > > Could someone confirm ?
> > >
> > > Thanks and regards,
> > >
> > > Didier Desiderio
> > > COMPAQ - Sophia-Antipolis - France
> > > > Mail [email-masked]
> > > > Phone +33 (0) 4 92 95 57 93
> > > Fax +33 (0) 4 92 95 58 48
> > >
> > >
> > >
> > >
> > > ---
> > > 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]

-- 
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: Kevin McCandless <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Status of sigtran protocols
Date: Wed, 18 Jul 2001 14:17:51 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: rainier.illuminet.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [63.116.20.100]
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">

<META content="MSHTML 5.50.4611.1300" name=GENERATOR></HEAD> <BODY>
<DIV><FONT face=Arial size=2><SPAN class=952361421-18072001>Attached you
will find and MS word document that takes the information Lyndon put
together and formats it a little and includes two additional items SCTP and
TUA.&nbsp; I needed this for my internal tracking.&nbsp; If you would like,
I can keep this up to date for the group.</SPAN></FONT></DIV> <DIV><FONT
face=Arial size=2><SPAN 
class=952361421-18072001></SPAN></FONT>&nbsp;</DIV> <DIV><FONT face=Arial
size=2><SPAN class=952361421-18072001>Please provide text edits
Lyndon...</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=952361421-18072001></SPAN></FONT>&nbsp;</DIV> <DIV><FONT face=Arial
size=2><SPAN 
class=952361421-18072001>Sincerely,</SPAN></FONT></DIV> <P><FONT
face="Lucida Calligraphy">Kevin McCandless</FONT> <BR><FONT face=Arial
size=2>Senior Network Planner</FONT> <BR><FONT face=Arial
size=2>Illuminet</FONT> <BR><FONT face=Arial size=2>913-814-6397</FONT>
<BR><FONT face=Arial size=2>[email-masked]</FONT> </P>
<DIV>&nbsp;</DIV></BODY></HTML>

</x-html>

Attachment Converted: "c:\program files\qualcomm\eudora
pro\attach\Sigtran-status.doc" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA06: Routing Key Management procedure
Date: Wed, 18 Jul 2001 17:22:15 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail3.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail3.rdc1.on.home.com [24.2.9.90]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian, Nitin,

I'm attempting to wrap this up. See responses below ...

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]> To: "sigtran"
<[email-masked]> Cc: <[email-masked]>
Sent: Thursday, July 12, 2001 6:24 PM
Subject: Re: M3UA06: Routing Key Management procedure

> Nitin, Greg,
>
> Please see comments below...
>
> Tomar, Nitin wrote:                      (Thu, 12 Jul 2001 14:12:23)
>
> [snip]
> > >
> > > Greg,
> > >
> > > I have few queries/comments on Routing key procedure.
> > >
> > > - Nitin.
> > >
> > > 1. Is RKM procedure valid for IPSP-IPSP communication as well? In
> > > either case I think the draft can specify it clearly in section
> > > 3.5.5 and related sections. If RKM is allowed for IPSP-IPSP
> > > scenario, can client and server both initiate REG-REQ and DEREG-REQ
> > > messages, I do not find any reason they should not do so.
> >
> > [Greg] I agree that RKM should be possible for IPSP-to IPSP but this
> > is not an application that I have an interest.  I'm not sure though
> > that it makes sense to register in both directions point-to-point to
> > set up a two way communication.  I see that currently ASPs use the REG
> > REQ to set-up two way traffic with the SG - the SG doesn't need a
> > separate procedure to register for which traffic it wants from the
> > ASP, as it is usually related.  But I suppose there could be an
> > application to Register in both directions to set up two sets of
> > two-way traffic beween IPSPs.  Do people need this described?
> >
> > [Nitin] I may be missing something here, do you mean that with REG REQ
> > message an ASP can specify an SGP that what traffic it'll be sending
> > towards it, if so how an SGP will come to know that the traffic
> > related to the RK specified in REG REQ message is handled by ASP or
> > the ASP wants to send this traffic to SGP.
>
> This is stiking on an SGP issue which has been raised several times.
> How does the SGP know what traffic it is to receive?
>
> These issues are all related.  Placing the Routing Context in the DATA
> message permits the the SGP to screen the DATA messages on the basis of
> valid Routing Contexts.  Breaking the routing label into parameters
> permits the SG to screen the routing label without parsing the DATA
> payload (after the ASP has just finished packing it).
>
> Placing the restriction that the ASP can only send messages to an SGP
> which have the symmetrical Routing Key associated with the Routing
> Context permits the SGP to know what traffic it is expected to process
> when a REG REQ is performed and screen the messages per above when the
> messages actually arrive.
>

[Greg2]  Brian, I'm thinking that there are cases where the addressing will
not be symmetrical across the SGP, so this is may be too restrictive.  For
ISUP traffic this is probably fine but SCCP traffic may be a problem.  I
think there are valid cases where the OPC and DPC may not be simply inverted
by the ASP for the response to a query.  You could have, for example, a
message coming in from an SS7 STP (after SCCP GTT) with the OPC of the STP.
This message is directed to an ASP, which addresses the response directly to
an SEP behind the STP, or to the SG (or another SS7 node) for a GTT in the
response direction.  So I think it is too restrictive to enforce this in the
protocol - we should leave this to a decoupled screening function.

I'm not sure why an SG must currently parse the entire Data Payload to look
at the DPC, OPC etc for the purposes of screening at the SG.  Screening may
be easier if the Routing Label is in separate parameters (your proposal) but
it is certainly possible either way.

> >
> > >
> > > 2. De-registration request for RK not registered through REG REQ
> > > message is valid or not? lets say RK was statically configured at an
> > > SG which supports both static and dynamic configuration of RKs.
> >
> > [Greg] I don't think so, but it is really up to the configuration
> > manager.  When we first put together the registration protocol we (the
> > authors) agreed that an SG would need to police whether the ASP is
> > allowed to change a particular piece of configuration data.  If the
> > piece of configuration data (RK) was "statically" created by a local
> > mangement system, as opposed to created based on a REG REQ, then an
> > ASP sending a DEREG should not cause deletion of the entry or RK.
> >
> > It is possible that SGs could have features that will allow a lot of
> > flexibility here, such as allowing a new ASP to register/deregister
> > dynamically on a statically defined RK, but I don't think we need to
> > go there with the protocol.  Perhaps the best way out is to have the
> > configuration manager decide whether to honor the DEREG REQ, based on
> > the present RK data
> >
> > [Nitin] Fine,
> >
> > >
> > > 3. In section 4.3.4.1 and 4.3.4.2, The draft does not specifies any
> > > timers associated with the REG REQ and DEREG REQ messages, I think
> > > there is a need for timers for RKM messages, as an ASP can not wait
> > > indefinitely for the REG RSP if SG decides to respond to REG REQ
> > > containing multiple RKs with multiple REG RSP messages'
> > >
> > > The timer can be similar to what we have for ASPM messages,
> > > something like this:
> > >
> > > 'When ASP sends an REG REQ it starts timer T(RK-ack). If the ASP
> > > does not receive a response to REG REQ within T(RK-ack), the ASP may
> > > restart T(RK-ack) and resend REG REQ messages until it receives an
> > > REG REQ message.  T(RK-ack) is provisionable, with a default of n
> > > seconds. Alternatively, retransmission of REG RSP messages may be
> > > put under control of Layer Management'
> > >
> >
> > [Greg] Actually I think that these timers of marginal use, allowing
> > the resending of a message for which there is no response.  I see it
> > as useful for ASP Up/Down, and for ASP Active/Inact and REG/DEREG when
> > there is only one contained request (e.g., RK/RC).  But for ASP
> > Active/Inact and REG/DEREG with more than one request, they are not
> > very useful.  Robust implementations should probably run a timer per
> > request (RK or RC), not per message.  An implemenation can't leave
> > these requests open indefinitely - if there is no reponse to a request
> > the application will have to take action to retry or close it.  Per
> > this text, and the current ASP Active text, if a REG RESP is received
> > containing a result for only one of two requests, then the Timer is
> > cancelled and we still have an outstanding request.  There are also I
> > think possible cases where a "response" is ambiguous, at least for ASP
> > Active messages that are errored.
> >
> > So I think we have a couple of options: 1) add REG/DEREG timers ) on a
> > per/transaction basis (and change ASP-Active/Inactive timers), 2)
> > remove the explicit message timers and add text saying that the
> > sending application should run a timer to close/resend each request,
> > or 3) remove the text.  Views?
> >
> > [Nitin] I'm in favor of 1st option, as this issue is related to timers
> > for ASP-Active/Inactive too, it makes more sense to have these
> > per/transaction basis, that may cause a bit more handling in the
> > protocol but it will ensure the consistency among the ASPM and DRKM
> > procedures.
>
> For the current T(ack) timer, control is essentially placed in the hands
> of management: either management runs its own algorithm, or when the
> timer expires management is informed of the failure.
>
> What this timer really accomplishes is seeing if the SG is dead on a
> valid SCTP association.  I don't know how an SG could be "dead" for one
> RK contained in a REG REQ but "alive" for another.  I like the idea of
> cancelling the timer when when any REG RESP pertaining to the sent REG
> REQ is returned.  That would mean that the ASP could do something like
> assume that the SG is dead and, say, cycle the SCTP association under LM
> control.
>
> I like with 1) and Nitin's text (with the exception that the timer is
> cancelled when the first REG RESP message with a result pertaining to
> the original REG REQ is received, and the addition of management
> primitives M-REQ_REQ and M-REG_RESP so that management can also control
> the situation as is currently provided for ASP_UP).
>

[Greg2] The primitives are already there in Issue 7, althought they may need
a tweak or two.  I'm assuming that 1) with Brian's modification is the
consensus and will add for Issue 8.

> > > 4. Can a ASP is authorized to send REG-REG only and not authorized
> > > to send DEREG-REQ, in either case the draft can specify it clearly
> > > in section 4.3.4.2.
> > >
> >
> > [Greg] I hope not.  Anyway the SG is currently allowed to refuse a REG
> > or DEREG.  If there is an application where it is useful to accept one
> > but not the other, I'd see this as a ploicy decision at the SG.  I
> > don't think we need to cover this in the protocol.
> >
> > [Nitin] OK,
> >
> > > 5. Figure for "Routing Key" parameter description can be modified to
> > > indicate the Network Appearance (optional) as first parameter. [To
> > > comply with section 3.3.1 stating 'Where the optional Network
> > > Appearance parameter is present, it must be the first parameter in
> > > the message']
> >
> > [Greg] Yes this is inconsistent.  I've also had the view expressed to
> > me that the Network Appearance shouldn't be first in the DATA message
> > either as it is technically an optional parameter and the Protocol
> > Data parameter is mandatory.  For some people, mandatory parameters
> > should come first before any optional parameters (like in SS7).  We
> > should sort this out once and for all for Issue 8 - IMHO it should be
> > first in both RK and DATA (when present) as suggested here but I'll do
> > whatever the decoders feel is best.
> >

[Greg2] I don't see any opinions on which way is best here.  For now I'm
assuming we should put the Network Appearance parameter (if present) as the
first one in the RK as per Nitin's suggestion.

> > Of course there is a proposal from Brian to replace the NA everywhere
> > with an RC - we should sort that idea out as well - see this thread.
> >
> > >
> > > 6. The 'Registration Status' parameter values in REG RSP message
> > > need one more type of error value : 'Multiple SI not supported' as
> > > none of the existing error value cover this [In case SG optionally
> > > support only one SI in a Routing key as per section 1.4.2.2].
> > >
> >
> > [Greg} I can add this. Actually there are a few more error values that
> > probably make sense. - "Invalid SI" , OPC, CIC Range, SSN", for
> > example.  Others?
>
> Let's not get into adding a whole but of error codes here...
>
> I think that Nitin's example is adequately covered under the "Error -
> Invalid Routing Key" per the description in the on Page 79 of M3UA-07:
>
> "If the SGP determines that the received Routing Key data is
> invalid, or contains invalid parameter values, the SGP returns a
> Registration Response message to the ASP, containing a
> Registration Result "Error - Invalid Routing Key", "Error -
> Invalid DPC", "Error - Invalid Network Appearance" as
> appropriate."
>
> Rather than getting into a long list of error results, why not add an
> optional INFO String to the Registration Status which can contain
> additional implementation specific or diagnostic information.
>

[Greg]  For REG RESP with multiple Registration Stati(?) this gets messy in
a big hurry (optional INFO String for each Registration Status)?  I don't
see this yet - I'd rather add a few additional failure codes.

Thanks,

   Greg Sidebottom

> >
> > > 7. Section 3.5.5, 3.5.6, 3.5.7 and 3.5.8 numbering is duplicated.
> >
> > [Greg] hopefully this is fixed in Issue 7 - no guarantees though!
> >
> > [Nitin ] Its fixed.
> >
> >
> > Thanks Again,
> >
> >      Greg
> >
>
> --
> 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: Wed, 18 Jul 2001 16:49:37 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA (V7) DRST question
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-248.dallas.net [209.44.42.248]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

I did find one problem with what you describe:  In several places the draft
make mention of things which would preclude, or counter-recommend it:

    Section 1.1

	"Where an SG contains more than one SGP, the SG is a
	logical entity and the contained SGPs must be
	coordinated into a signle management view to the SS7
	network and to the supported Application Servers."

    Section 1.4.1

	"Where an SG contains more than one SGP, the MTP3
	routeset, SPMC and remote AS/ASP states of each SGP
	SHOULD be coordinated across all the SGPs.  Re-routing
	of traffic between SGPs SHOULD also be supported."

--Brian

Greg Sidebottom wrote:                           (Wed, 18 Jul 2001 16:28:54)
> Hi Pierre,
> 
> Response below ..
> 
> ----- Original Message -----
> From: "Garnero, Pierre" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Wednesday, July 18, 2001 1:31 PM
> Subject: RE: M3UA (V7) DRST question
> 
> 
> > Hi Greg,
> >
> > well yes, we see an issue... :-)
> >
> > In the "1.2 Terminology" chapter we read:
> >
> > " Signalling Gateway - An SG .......
> > - An SG appears to the SS7 network as an SS7 signalling point...."
> >
> > => so, on a specific SS7 network, the SG is identified by a unique PC.
> >
> 
> [Greg] Yes.
> 
> > Then how traffic could be diverted to another SGP in the same SG when an
> ASP
> > has received a DRST (or DUNA) message ?
> 
> [Greg] I'm not sure that I see the problem yet.  From the ASP perspective
it
> need only know that it has two equal routes to the affected destination,
via
> two (for example) SGPs.  If the ASP receives a DRST from one of them ,
then
> the ASP could optionally re-direct outgoing traffic via the other SGP.
> Both SGPs are part of the same SG, and therefore share the same point code
-
> but remember that this point code is not the affected destination.
> 
> >
> > I suppose that in most of the cases, a DRST is sent by an SGP that has
> > received a TFR from its SS7 side.
> 
> [Greg] Not necessarily.  I think a DRST could result from a received TFR
> directly only in the case where the two SGPs have no connectivity between
> them (i.e. if the SGP has no other routes to the affected destination).
But
> we also state that SGPs should share MTP3/AS/ASP state and re-direct
traffic
> between themselves, so I don't think this is a normal case.
> 
> A TFR is always consumed by the SG MTP3 state machine.  If one SGP gets a
> TFR on a route it must update the other SGP and hold a common
route/routeset
> state because the MTP3 management has no concept of SGPs forming an SG.
> 
> 
> If this assumption is true, the ASP must
> > not send traffic to an alternate SGP that is in the same SG. It must
> choose
> > another "route" (if there is one with equal priority) then, another
SG...
> > ???
> >
> 
> [Greg] I don't follow you here.  Even if the assumption is true (e.g.,
> failure of inter-SGP communication), why can't the ASP send the traffic
via
> the other SGP?  The ASP has two equal routes to the affected destination
and
> has received a DRST wrt one of the routes.
> 
> Cheers,
> 
>    Greg
> 
> >
> > Cheers,
> >
> > Pierre
> >
> >
> >
> > -----Original Message-----
> > From: Greg Sidebottom [mailto:[email-masked]]
> > Sent: Wednesday, July 18, 2001 6:51 PM
> > To: sigtran
> > Subject: Re: M3UA (V7) DRST question
> >
> >
> > Bonsoir(!) Didier
> >
> > SGP is intended here so no typo - do you see an issue with this?
> >
> > An SGP could use a DRST to tell the ASP to use another SGP (if possible)
> for
> > traffic to the affected destination(s).  If acted upon, this could avoid
> > inter-SGP traffic, or inter-SG traffic where the SGPs are in different
> SGs.
> >
> > Cheers,
> >
> >    Greg Sidebottom
> >
> > ----- Original Message -----
> > From: "Desiderio, Didier" <[email-masked]>
> > To: "sigtran" <[email-masked]>
> > Sent: Wednesday, July 18, 2001 12:25 PM
> > Subject: M3UA (V7) DRST question
> >
> >
> > > Hi
> > >
> > > sentence in section 3.4.6 Destination Restricted (DRST):
> > >
> > > "via an alternate SGP of equal priority" : is there a typo here ? It
is
> SG
> > > instead of SGP, I guess ???
> > >
> > > Could someone confirm ?
> > >
> > > Thanks and regards,
> > >
> > > Didier Desiderio
> > > COMPAQ - Sophia-Antipolis - France
> > > > Mail [email-masked]
> > > > Phone +33 (0) 4 92 95 57 93
> > > Fax +33 (0) 4 92 95 58 48
> > >
> > >
> > >
> > >
> > > ---
> > > 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]

-- 
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, 18 Jul 2001 17:04:15 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA06: Routing Key Management procedure
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.248]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

Please see comments below....

Greg Sidebottom wrote:                                       (Wed, 18 Jul
2001 17:22:15)
> Hi Brian, Nitin,
> 
> I'm attempting to wrap this up. See responses below ...
> 
> ----- Original Message -----
> From: "Brian F. G. Bidulock" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, July 12, 2001 6:24 PM
> Subject: Re: M3UA06: Routing Key Management procedure
> 
> 
> > Nitin, Greg,
> >
> > Please see comments below...
> >
> > Tomar, Nitin wrote:                      (Thu, 12 Jul 2001 14:12:23)
> >
> > [snip]
> > > >
> > > > Greg,
> > > >
> > > > I have few queries/comments on Routing key procedure.
> > > >
> > > > - Nitin.
> > > >
> > > > 1. Is RKM procedure valid for IPSP-IPSP communication as well? In
> > > > either case I think the draft can specify it clearly in section
> > > > 3.5.5 and related sections. If RKM is allowed for IPSP-IPSP
> > > > scenario, can client and server both initiate REG-REQ and DEREG-REQ
> > > > messages, I do not find any reason they should not do so.
> > >
> > > [Greg] I agree that RKM should be possible for IPSP-to IPSP but this
> > > is not an application that I have an interest.  I'm not sure though
> > > that it makes sense to register in both directions point-to-point to
> > > set up a two way communication.  I see that currently ASPs use the REG
> > > REQ to set-up two way traffic with the SG - the SG doesn't need a
> > > separate procedure to register for which traffic it wants from the
> > > ASP, as it is usually related.  But I suppose there could be an
> > > application to Register in both directions to set up two sets of
> > > two-way traffic beween IPSPs.  Do people need this described?
> > >
> > > [Nitin] I may be missing something here, do you mean that with REG REQ
> > > message an ASP can specify an SGP that what traffic it'll be sending
> > > towards it, if so how an SGP will come to know that the traffic
> > > related to the RK specified in REG REQ message is handled by ASP or
> > > the ASP wants to send this traffic to SGP.
> >
> > This is stiking on an SGP issue which has been raised several times.
> > How does the SGP know what traffic it is to receive?
> >
> > These issues are all related.  Placing the Routing Context in the DATA
> > message permits the the SGP to screen the DATA messages on the basis of
> > valid Routing Contexts.  Breaking the routing label into parameters
> > permits the SG to screen the routing label without parsing the DATA
> > payload (after the ASP has just finished packing it).
> >
> > Placing the restriction that the ASP can only send messages to an SGP
> > which have the symmetrical Routing Key associated with the Routing
> > Context permits the SGP to know what traffic it is expected to process
> > when a REG REQ is performed and screen the messages per above when the
> > messages actually arrive.
> >
> 
> [Greg2]  Brian, I'm thinking that there are cases where the addressing
will
> not be symmetrical across the SGP, so this is may be too restrictive.  For
> ISUP traffic this is probably fine but SCCP traffic may be a problem.  I
> think there are valid cases where the OPC and DPC may not be simply
inverted
> by the ASP for the response to a query.  You could have, for example, a
> message coming in from an SS7 STP (after SCCP GTT) with the OPC of the
STP.
> This message is directed to an ASP, which addresses the response directly
to
> an SEP behind the STP, or to the SG (or another SS7 node) for a GTT in the
> response direction.  So I think it is too restrictive to enforce this in
the
> protocol - we should leave this to a decoupled screening function.

Good example!  But...  If the RK (or another RK to the ASP) does not also
include the OPC of the original sender, a TCP conversation will also fail.
So, I don't see a problem there, point code reversal is still fine.  I don't
think anyone really wants to split transactions across ASPs.

> 
> I'm not sure why an SG must currently parse the entire Data Payload to
look
> at the DPC, OPC etc for the purposes of screening at the SG.  Screening
may
> be easier if the Routing Label is in separate parameters (your proposal)
but
> it is certainly possible either way.
> 

To determine which received traffic is suitable (from an ASP) for both
security and screening purposes, the SG must extract and re-examine the Data
Payload that the sending ASP just finished packing.

> 
> > >
> > > >
> > > > 2. De-registration request for RK not registered through REG REQ
> > > > message is valid or not? lets say RK was statically configured at an
> > > > SG which supports both static and dynamic configuration of RKs.
> > >
> > > [Greg] I don't think so, but it is really up to the configuration
> > > manager.  When we first put together the registration protocol we (the
> > > authors) agreed that an SG would need to police whether the ASP is
> > > allowed to change a particular piece of configuration data.  If the
> > > piece of configuration data (RK) was "statically" created by a local
> > > mangement system, as opposed to created based on a REG REQ, then an
> > > ASP sending a DEREG should not cause deletion of the entry or RK.
> > >
> > > It is possible that SGs could have features that will allow a lot of
> > > flexibility here, such as allowing a new ASP to register/deregister
> > > dynamically on a statically defined RK, but I don't think we need to
> > > go there with the protocol.  Perhaps the best way out is to have the
> > > configuration manager decide whether to honor the DEREG REQ, based on
> > > the present RK data
> > >
> > > [Nitin] Fine,
> > >
> > > >
> > > > 3. In section 4.3.4.1 and 4.3.4.2, The draft does not specifies any
> > > > timers associated with the REG REQ and DEREG REQ messages, I think
> > > > there is a need for timers for RKM messages, as an ASP can not wait
> > > > indefinitely for the REG RSP if SG decides to respond to REG REQ
> > > > containing multiple RKs with multiple REG RSP messages'
> > > >
> > > > The timer can be similar to what we have for ASPM messages,
> > > > something like this:
> > > >
> > > > 'When ASP sends an REG REQ it starts timer T(RK-ack). If the ASP
> > > > does not receive a response to REG REQ within T(RK-ack), the ASP may
> > > > restart T(RK-ack) and resend REG REQ messages until it receives an
> > > > REG REQ message.  T(RK-ack) is provisionable, with a default of n
> > > > seconds. Alternatively, retransmission of REG RSP messages may be
> > > > put under control of Layer Management'
> > > >
> > >
> > > [Greg] Actually I think that these timers of marginal use, allowing
> > > the resending of a message for which there is no response.  I see it
> > > as useful for ASP Up/Down, and for ASP Active/Inact and REG/DEREG when
> > > there is only one contained request (e.g., RK/RC).  But for ASP
> > > Active/Inact and REG/DEREG with more than one request, they are not
> > > very useful.  Robust implementations should probably run a timer per
> > > request (RK or RC), not per message.  An implemenation can't leave
> > > these requests open indefinitely - if there is no reponse to a request
> > > the application will have to take action to retry or close it.  Per
> > > this text, and the current ASP Active text, if a REG RESP is received
> > > containing a result for only one of two requests, then the Timer is
> > > cancelled and we still have an outstanding request.  There are also I
> > > think possible cases where a "response" is ambiguous, at least for ASP
> > > Active messages that are errored.
> > >
> > > So I think we have a couple of options: 1) add REG/DEREG timers ) on a
> > > per/transaction basis (and change ASP-Active/Inactive timers), 2)
> > > remove the explicit message timers and add text saying that the
> > > sending application should run a timer to close/resend each request,
> > > or 3) remove the text.  Views?
> > >
> > > [Nitin] I'm in favor of 1st option, as this issue is related to timers
> > > for ASP-Active/Inactive too, it makes more sense to have these
> > > per/transaction basis, that may cause a bit more handling in the
> > > protocol but it will ensure the consistency among the ASPM and DRKM
> > > procedures.
> >
> > For the current T(ack) timer, control is essentially placed in the hands
> > of management: either management runs its own algorithm, or when the
> > timer expires management is informed of the failure.
> >
> > What this timer really accomplishes is seeing if the SG is dead on a
> > valid SCTP association.  I don't know how an SG could be "dead" for one
> > RK contained in a REG REQ but "alive" for another.  I like the idea of
> > cancelling the timer when when any REG RESP pertaining to the sent REG
> > REQ is returned.  That would mean that the ASP could do something like
> > assume that the SG is dead and, say, cycle the SCTP association under LM
> > control.
> >
> > I like with 1) and Nitin's text (with the exception that the timer is
> > cancelled when the first REG RESP message with a result pertaining to
> > the original REG REQ is received, and the addition of management
> > primitives M-REQ_REQ and M-REG_RESP so that management can also control
> > the situation as is currently provided for ASP_UP).
> >
> 
> [Greg2] The primitives are already there in Issue 7, althought they may
need
> a tweak or two.  I'm assuming that 1) with Brian's modification is the
> consensus and will add for Issue 8.
> 
> 
> > > > 4. Can a ASP is authorized to send REG-REG only and not authorized
> > > > to send DEREG-REQ, in either case the draft can specify it clearly
> > > > in section 4.3.4.2.
> > > >
> > >
> > > [Greg] I hope not.  Anyway the SG is currently allowed to refuse a REG
> > > or DEREG.  If there is an application where it is useful to accept one
> > > but not the other, I'd see this as a ploicy decision at the SG.  I
> > > don't think we need to cover this in the protocol.
> > >
> > > [Nitin] OK,
> > >
> > > > 5. Figure for "Routing Key" parameter description can be modified to
> > > > indicate the Network Appearance (optional) as first parameter. [To
> > > > comply with section 3.3.1 stating 'Where the optional Network
> > > > Appearance parameter is present, it must be the first parameter in
> > > > the message']
> > >
> > > [Greg] Yes this is inconsistent.  I've also had the view expressed to
> > > me that the Network Appearance shouldn't be first in the DATA message
> > > either as it is technically an optional parameter and the Protocol
> > > Data parameter is mandatory.  For some people, mandatory parameters
> > > should come first before any optional parameters (like in SS7).  We
> > > should sort this out once and for all for Issue 8 - IMHO it should be
> > > first in both RK and DATA (when present) as suggested here but I'll do
> > > whatever the decoders feel is best.
> > >
> 
> [Greg2] I don't see any opinions on which way is best here.  For now I'm
> assuming we should put the Network Appearance parameter (if present) as
the
> first one in the RK as per Nitin's suggestion.

I don't see a problem with that.  It is convenient as the first parameter
when present, because the parser needs it before unpacking the Data Payload
anyway.  M3UA bears little to no resemblance to SS7 paraemter formats,
anyway.
SS7 goes Mandatory Fixed, Mandatory Variable, Optional and Mandatory fixed
parameters are usually not TLV, but optional fixe are.

I think everyone is fine with the idea of having Network Appearance first.

(On the other hand, I don't think it should be in the message anyway!
It should be a Routing Context instead.)

> 
> > > Of course there is a proposal from Brian to replace the NA everywhere
> > > with an RC - we should sort that idea out as well - see this thread.
> > >
> > > >
> > > > 6. The 'Registration Status' parameter values in REG RSP message
> > > > need one more type of error value : 'Multiple SI not supported' as
> > > > none of the existing error value cover this [In case SG optionally
> > > > support only one SI in a Routing key as per section 1.4.2.2].
> > > >
> > >
> > > [Greg} I can add this. Actually there are a few more error values that
> > > probably make sense. - "Invalid SI" , OPC, CIC Range, SSN", for
> > > example.  Others?
> >
> > Let's not get into adding a whole but of error codes here...
> >
> > I think that Nitin's example is adequately covered under the "Error -
> > Invalid Routing Key" per the description in the on Page 79 of M3UA-07:
> >
> > "If the SGP determines that the received Routing Key data is
> > invalid, or contains invalid parameter values, the SGP returns a
> > Registration Response message to the ASP, containing a
> > Registration Result "Error - Invalid Routing Key", "Error -
> > Invalid DPC", "Error - Invalid Network Appearance" as
> > appropriate."
> >
> > Rather than getting into a long list of error results, why not add an
> > optional INFO String to the Registration Status which can contain
> > additional implementation specific or diagnostic information.
> >
> 
> [Greg]  For REG RESP with multiple Registration Stati(?) this gets messy
in
> a big hurry (optional INFO String for each Registration Status)?  I don't
> see this yet - I'd rather add a few additional failure codes.

But no additional error codes are required in this case: "Invalid Routing
Key" will suffice.  There is no point (beyond diagnostics which is the point
of the INFO string anyway) in indicating precisely what is wrong with the
Routing Key: it will take a human to diagnose the problem anyway.

Also, there is no need to add an INFO string to registration status, just
add it to the REG RSP message.  If the sender wants to place diagnostics in
the INFO string on a per-result basis, it can limit the number of results in
the message to a single result.

> 
> Thanks,
> 
>    Greg Sidebottom
> 
> 
> > >
> > > > 7. Section 3.5.5, 3.5.6, 3.5.7 and 3.5.8 numbering is duplicated.
> > >
> > > [Greg] hopefully this is fixed in Issue 7 - no guarantees though!
> > >
> > > [Nitin ] Its fixed.
> > >
> > >
> > > Thanks Again,
> > >
> > >      Greg
> > >
> >
> > --
> > 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
[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: Andreas Jungmaier <[email-masked]>
Organization: University of Essen, Germany
To: "sigtran" <[email-masked]>
Subject: Comment for the RFC-2960-bis draft.
Date: Wed, 18 Jul 2001 18:36:10 -0400
X-Mailer: KMail [version 1.2]
X-SMTP-HELO: irmgard.exp-math.uni-essen.de
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: irmgard.exp-math.uni-essen.de [132.252.150.18]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Dear all,

I have a remark for section 6.2. of the current RFC 2960 respectively the
same section in the document draft-ietf-tsvwg-rfc2960-bis-00.txt

It says there:

 6.2  Acknowledgement on Reception of DATA Chunks

   The SCTP endpoint MUST always acknowledge the reception of each valid
   DATA chunk.

   The guidelines on delayed acknowledgement algorithm specified in
   Section 4.2 of [RFC2581] SHOULD be followed.  Specifically, an
   acknowledgement SHOULD be generated for at least every second packet
   (not every second DATA chunk) received, and SHOULD be generated
   within 200 ms of the arrival of any unacknowledged DATA chunk.

Now, it is, IMHO, not clear from that section whether that only applies to
packets containing data chunks (as one could think according to the section
header), or it applies to _all_ packets (well, it says "EVERY SECOND
PACKET"). 

I am not sure whether it would make sense to send a SACK after two Heartbeat
chunks have been received ?!

Any comments ?

Best regards, 

Andreas Jungmaier

-
----------------------------------------------------------------------------
\|/ _____ \|/    Andreas Jungmaier, Dipl.-Ing. 
 "@'/ , . \`@"    University of Essen           [email-masked]
/_| \___/ |__\   -> Computer Networking        Tel. : +49 (0201) 183-7636
    \___U_/          Technology Group <- -
----------------------------------------------------------------------------
PGP Public Key and Fingerprint: see http://www.exp-math.uni-essen.de/~ajung
-
----------------------------------------------------------------------------

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA (V7) DRST question
Date: Wed, 18 Jul 2001 18:51:24 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail3.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail3.rdc1.on.home.com [24.2.9.90]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

Response below ...

- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Wednesday, July 18, 2001 5:49 PM
Subject: Re: M3UA (V7) DRST question

> Greg,
>
> I did find one problem with what you describe:  In several
> places the draft make mention of things which would preclude,
> or counter-recommend it:
>
>     Section 1.1
>
> "Where an SG contains more than one SGP, the SG is a
> logical entity and the contained SGPs must be
> coordinated into a signle management view to the SS7
> network and to the supported Application Servers."
>

[Greg] Do you mean it is contradictory because, for example, if only one SGP
in an SG sends a DRST then this is not a single management view from the SG
to the supported Application Servers?  Probably true, but I think this is a
useful exception - the SGPs are coordinating the traffic flows to make them
more efficient.   I think we can get around this by using "should" instead
of "must" (i.e., "  .. the contained SGPs should be coordinated ...  ") as
in the other sections.

>     Section 1.4.1
>
> "Where an SG contains more than one SGP, the MTP3
> routeset, SPMC and remote AS/ASP states of each SGP
> SHOULD be coordinated across all the SGPs.  Re-routing
> of traffic between SGPs SHOULD also be supported."
>
> --Brian

[Greg] I'm not sure yet why this text is contradictory?  The SGP states
maintained locally can be different but aggregated into a single set of
overall SG states, assuming there is no breakdown of inter-SGP
communication.

Thanks,

    Greg

>
> Greg Sidebottom wrote:                           (Wed, 18 Jul 2001
16:28:54)
> > Hi Pierre,
> >
> > Response below ..
> >
> > ----- Original Message -----
> > From: "Garnero, Pierre" <[email-masked]>
> > To: "sigtran" <[email-masked]>
> > Sent: Wednesday, July 18, 2001 1:31 PM
> > Subject: RE: M3UA (V7) DRST question
> >
> >
> > > Hi Greg,
> > >
> > > well yes, we see an issue... :-)
> > >
> > > In the "1.2 Terminology" chapter we read:
> > >
> > > " Signalling Gateway - An SG .......
> > > - An SG appears to the SS7 network as an SS7 signalling point...."
> > >
> > > => so, on a specific SS7 network, the SG is identified by a unique PC.
> > >
> >
> > [Greg] Yes.
> >
> > > Then how traffic could be diverted to another SGP in the same SG when
an
> > ASP
> > > has received a DRST (or DUNA) message ?
> >
> > [Greg] I'm not sure that I see the problem yet.  From the ASP
perspective it
> > need only know that it has two equal routes to the affected destination,
via
> > two (for example) SGPs.  If the ASP receives a DRST from one of them ,
then
> > the ASP could optionally re-direct outgoing traffic via the other SGP.
> > Both SGPs are part of the same SG, and therefore share the same point
code -
> > but remember that this point code is not the affected destination.
> >
> > >
> > > I suppose that in most of the cases, a DRST is sent by an SGP that has
> > > received a TFR from its SS7 side.
> >
> > [Greg] Not necessarily.  I think a DRST could result from a received TFR
> > directly only in the case where the two SGPs have no connectivity
between
> > them (i.e. if the SGP has no other routes to the affected destination).
But
> > we also state that SGPs should share MTP3/AS/ASP state and re-direct
traffic
> > between themselves, so I don't think this is a normal case.
> >
> > A TFR is always consumed by the SG MTP3 state machine.  If one SGP gets
a
> > TFR on a route it must update the other SGP and hold a common
route/routeset
> > state because the MTP3 management has no concept of SGPs forming an SG.
> >
> >
> > If this assumption is true, the ASP must
> > > not send traffic to an alternate SGP that is in the same SG. It must
> > choose
> > > another "route" (if there is one with equal priority) then, another
SG...
> > > ???
> > >
> >
> > [Greg] I don't follow you here.  Even if the assumption is true (e.g.,
> > failure of inter-SGP communication), why can't the ASP send the traffic
via
> > the other SGP?  The ASP has two equal routes to the affected destination
and
> > has received a DRST wrt one of the routes.
> >
> > Cheers,
> >
> >    Greg
> >
> > >
> > > Cheers,
> > >
> > > Pierre
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Greg Sidebottom [mailto:[email-masked]]
> > > Sent: Wednesday, July 18, 2001 6:51 PM
> > > To: sigtran
> > > Subject: Re: M3UA (V7) DRST question
> > >
> > >
> > > Bonsoir(!) Didier
> > >
> > > SGP is intended here so no typo - do you see an issue with this?
> > >
> > > An SGP could use a DRST to tell the ASP to use another SGP (if
possible)
> > for
> > > traffic to the affected destination(s).  If acted upon, this could
avoid
> > > inter-SGP traffic, or inter-SG traffic where the SGPs are in different
> > SGs.
> > >
> > > Cheers,
> > >
> > >    Greg Sidebottom
> > >
> > > ----- Original Message -----
> > > From: "Desiderio, Didier" <[email-masked]>
> > > To: "sigtran" <[email-masked]>
> > > Sent: Wednesday, July 18, 2001 12:25 PM
> > > Subject: M3UA (V7) DRST question
> > >
> > >
> > > > Hi
> > > >
> > > > sentence in section 3.4.6 Destination Restricted (DRST):
> > > >
> > > > "via an alternate SGP of equal priority" : is there a typo here ? It
is
> > SG
> > > > instead of SGP, I guess ???
> > > >
> > > > Could someone confirm ?
> > > >
> > > > Thanks and regards,
> > > >
> > > > Didier Desiderio
> > > > COMPAQ - Sophia-Antipolis - France
> > > > > Mail [email-masked]
> > > > > Phone +33 (0) 4 92 95 57 93
> > > > Fax +33 (0) 4 92 95 58 48
> > > >
> > > >
> > > >
> > > >
> > > > ---
> > > > 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]
>
> --
> 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: Wed, 18 Jul 2001 18:18:06 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA (V7) DRST question
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.248]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

More below...

Greg Sidebottom wrote:                                       (Wed, 18 Jul
2001 18:51:24)
> Hi Brian,
> 
> Response below ...
> 
> - Original Message -----
> From: "Brian F. G. Bidulock" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Wednesday, July 18, 2001 5:49 PM
> Subject: Re: M3UA (V7) DRST question
> 
> 
> > Greg,
> >
> > I did find one problem with what you describe:  In several
> > places the draft make mention of things which would preclude,
> > or counter-recommend it:
> >
> >     Section 1.1
> >
> > "Where an SG contains more than one SGP, the SG is a
> > logical entity and the contained SGPs must be
> > coordinated into a signle management view to the SS7
> > network and to the supported Application Servers."
> >
> 
> [Greg] Do you mean it is contradictory because, for example, if only one
SGP
> in an SG sends a DRST then this is not a single management view from the
SG
> to the supported Application Servers?  Probably true, but I think this is
a
> useful exception - the SGPs are coordinating the traffic flows to make
them
> more efficient.   I think we can get around this by using "should" instead
> of "must" (i.e., "  .. the contained SGPs should be coordinated ...  ") as
> in the other sections.
> 
> >     Section 1.4.1
> >
> > "Where an SG contains more than one SGP, the MTP3
> > routeset, SPMC and remote AS/ASP states of each SGP
> > SHOULD be coordinated across all the SGPs.  Re-routing
> > of traffic between SGPs SHOULD also be supported."
> >
> > --Brian
> 
> [Greg] I'm not sure yet why this text is contradictory?  The SGP states
> maintained locally can be different but aggregated into a single set of
> overall SG states, assuming there is no breakdown of inter-SGP
> communication.

Well, it is just a question of which thing you are sending to the ASP when
you send things like DRST for multiple SGP.
The ASP needs to know whether it is the SG status or the SGP status which is
being indicated.

  If all these things (DUNA/DAVA/DRST) are only an
  indication of the SGP status, then the ASP receives
  one for each SGP and must derive the SG status from
  the aggregate of the SGPs--which is contrary to the
  above statements.
  
  If DUNA/DAVA/DRST are indications of SG status, then
  it must already represent an aggregate view and the
  ASP needs only receive these from one SGP.

Unfortunately you can't have it both ways unless we add something to these
messages: i.e. an indicator as to whether the status applies to the SGP or
the whole SG.

I don't have a problem with the ASP keeping track of these things on a
per-SGP basis.  As a matter of fact I think it is quite apt for M3UA.  But
text list this which recommends otherwise gives the impression that the SG
is aggregating these things for the ASP when  in the per-SGP case, the ASP
must do the aggregation.

> Thanks,
>     Greg

-- 
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, 18 Jul 2001 21:13:21 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: NTFY Insufficient ASP resources active in AS
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-248.dallas.net [209.44.42.248]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

All,

I still cannot see the point in notifying the ASPs *after* there are not
enough active ASPs to take the load.  This will just force the SG to buffer
and possibly fail in all cases of inadvertent deactivation of an ASP.

Why can we not notify *before*.  That is, notify when the AS is running with
no protection (i.e. the "n+0" case instead of the "(n-1)+0" case).  This
would permit an inactive ASP which has inadvertently gone inactive to bring
itself back on-line without failure.

I'm really struggling with this in implementation: because it is possible
that the ASPs may lose communication with each other, they may no longer be
aware of the number of ASPs which are running in an AS.  The SG(P) has this
information.  Why can it not communicate the information to the ASPs for the
AS for which they are configured (as part of the ASP Up Ack or a separate
NTFY before the ASP Up Ack) or for which they are registered (as part of the
REG RSP or in a separate NTFY before the REG RSP is sent).

Also, often in telecommunications systems, going to one's knees is far
preferrable to croaking.  Why cannot the SG report insufficient ASPs without
shutting down traffic?
Setting "n=1" is not a solution, because it does not indicate to the ASPs
when they are vulnerable.

It makes sense to me that the SG would communicate all the state information
that it has at its disposal regarding the ASs and ASPs to the ASPs with
which it communicates.

--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: [email-masked]
X-Lotus-FromDomain: HSS
To: "sigtran" <[email-masked]>
Date: Thu, 19 Jul 2001 09:26:22 +0530
Subject: m2ua-09: comment #5
X-SMTP-HELO: hindon.hss.co.in
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [202.54.26.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi,

1. Sec 4.4.1 para 2 states
" A unique method of Interface Identifier valid assignment at the SG/SGP is
implementation dependent but must be guaranteed to be unique across all SGPs
in an SG."

There is no prior definition of SGP in the draft. Is the concept of SGP here
assumed to be the same as in m3ua?
In any case, the concept should be explained.

regards,
Harsh Bhondwe
Hughes Software Systems

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA06: Routing Key Management procedure
Date: Wed, 18 Jul 2001 23:57:46 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail3.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail3.rdc1.on.home.com [24.2.9.90]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Thanks Brian,

 More below ...

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Wednesday, July 18, 2001 6:04 PM
Subject: Re: M3UA06: Routing Key Management procedure

> Greg,
>
> Please see comments below....
>
> Greg Sidebottom wrote:                                       (Wed, 18 Jul
2001 17:22:15)
> > Hi Brian, Nitin,
> >
> > I'm attempting to wrap this up. See responses below ...
> >
> > ----- Original Message -----
> > From: "Brian F. G. Bidulock" <[email-masked]>
> > To: "sigtran" <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Thursday, July 12, 2001 6:24 PM
> > Subject: Re: M3UA06: Routing Key Management procedure
> >
> >
> > > Nitin, Greg,
> > >
> > > Please see comments below...
> > >
> > > Tomar, Nitin wrote:                      (Thu, 12 Jul 2001 14:12:23)
> > >
> > > [snip]
> > > > >
> > > > > Greg,
> > > > >
> > > > > I have few queries/comments on Routing key procedure.
> > > > >
> > > > > - Nitin.
> > > > >
> > > > > 1. Is RKM procedure valid for IPSP-IPSP communication as well? In
> > > > > either case I think the draft can specify it clearly in section
> > > > > 3.5.5 and related sections. If RKM is allowed for IPSP-IPSP
> > > > > scenario, can client and server both initiate REG-REQ and
DEREG-REQ
> > > > > messages, I do not find any reason they should not do so.
> > > >
> > > > [Greg] I agree that RKM should be possible for IPSP-to IPSP but this
> > > > is not an application that I have an interest.  I'm not sure though
> > > > that it makes sense to register in both directions point-to-point to
> > > > set up a two way communication.  I see that currently ASPs use the
REG
> > > > REQ to set-up two way traffic with the SG - the SG doesn't need a
> > > > separate procedure to register for which traffic it wants from the
> > > > ASP, as it is usually related.  But I suppose there could be an
> > > > application to Register in both directions to set up two sets of
> > > > two-way traffic beween IPSPs.  Do people need this described?
> > > >
> > > > [Nitin] I may be missing something here, do you mean that with REG
REQ
> > > > message an ASP can specify an SGP that what traffic it'll be sending
> > > > towards it, if so how an SGP will come to know that the traffic
> > > > related to the RK specified in REG REQ message is handled by ASP or
> > > > the ASP wants to send this traffic to SGP.
> > >
> > > This is stiking on an SGP issue which has been raised several times.
> > > How does the SGP know what traffic it is to receive?
> > >
> > > These issues are all related.  Placing the Routing Context in the DATA
> > > message permits the the SGP to screen the DATA messages on the basis
of
> > > valid Routing Contexts.  Breaking the routing label into parameters
> > > permits the SG to screen the routing label without parsing the DATA
> > > payload (after the ASP has just finished packing it).
> > >
> > > Placing the restriction that the ASP can only send messages to an SGP
> > > which have the symmetrical Routing Key associated with the Routing
> > > Context permits the SGP to know what traffic it is expected to process
> > > when a REG REQ is performed and screen the messages per above when the
> > > messages actually arrive.
> > >
> >
> > [Greg2]  Brian, I'm thinking that there are cases where the addressing
will
> > not be symmetrical across the SGP, so this is may be too restrictive.
For
> > ISUP traffic this is probably fine but SCCP traffic may be a problem.  I
> > think there are valid cases where the OPC and DPC may not be simply
inverted
> > by the ASP for the response to a query.  You could have, for example, a
> > message coming in from an SS7 STP (after SCCP GTT) with the OPC of the
STP.
> > This message is directed to an ASP, which addresses the response
directly to
> > an SEP behind the STP, or to the SG (or another SS7 node) for a GTT in
the
> > response direction.  So I think it is too restrictive to enforce this in
the
> > protocol - we should leave this to a decoupled screening function.
>
> Good example!  But...  If the RK (or another RK to the ASP) does not also
> include the OPC of the original sender, a TCP conversation will also fail.
> So, I don't see a problem there, point code reversal is still fine.  I
don't
> think anyone really wants to split transactions across ASPs.
>

[Greg3] Why would the TCAP transaction fail?  I thought that the OPC of the
original sender is handed up to TCAP in the SCCP Calling Party Address.  I
surely agree with you that an SG doesn't want to split transactions across
ASPs in a loadshare group - I'm just not sure that using the MTP OPC in the
RK enforces this.  If a GTT has occured before hitting the SG, then I don't
think that the MTP OPC is useful for keeping transactions together across a
loadshare group.

> >
> > I'm not sure why an SG must currently parse the entire Data Payload to
look
> > at the DPC, OPC etc for the purposes of screening at the SG.  Screening
may
> > be easier if the Routing Label is in separate parameters (your proposal)
but
> > it is certainly possible either way.
> >
>
> To determine which received traffic is suitable (from an ASP) for both
> security and screening purposes, the SG must extract and re-examine the
> Data Payload that the sending ASP just finished packing.
>
> >
> > > >
> > > > >

snip

> > > >
> > > > > 5. Figure for "Routing Key" parameter description can be modified
to
> > > > > indicate the Network Appearance (optional) as first parameter. [To
> > > > > comply with section 3.3.1 stating 'Where the optional Network
> > > > > Appearance parameter is present, it must be the first parameter in
> > > > > the message']
> > > >
> > > > [Greg] Yes this is inconsistent.  I've also had the view expressed
to
> > > > me that the Network Appearance shouldn't be first in the DATA
message
> > > > either as it is technically an optional parameter and the Protocol
> > > > Data parameter is mandatory.  For some people, mandatory parameters
> > > > should come first before any optional parameters (like in SS7).  We
> > > > should sort this out once and for all for Issue 8 - IMHO it should
be
> > > > first in both RK and DATA (when present) as suggested here but I'll
do
> > > > whatever the decoders feel is best.
> > > >
> >
> > [Greg2] I don't see any opinions on which way is best here.  For now I'm
> > assuming we should put the Network Appearance parameter (if present) as
the
> > first one in the RK as per Nitin's suggestion.
>
> I don't see a problem with that.  It is convenient as the first parameter
> when present, because the parser needs it before unpacking the Data
Payload
> anyway.  M3UA bears little to no resemblance to SS7 paraemter formats,
anyway.
> SS7 goes Mandatory Fixed, Mandatory Variable, Optional and Mandatory fixed
> parameters are usually not TLV, but optional fixe are.
>
> I think everyone is fine with the idea of having Network Appearance first.
>
> (On the other hand, I don't think it should be in the message anyway!
> It should be a Routing Context instead.)
>

[Greg3] Yes, we do need to come to a conclusion on that other thread.  2:^0

> >
> > > > Of course there is a proposal from Brian to replace the NA
everywhere
> > > > with an RC - we should sort that idea out as well - see this thread.
> > > >
> > > > >
> > > > > 6. The 'Registration Status' parameter values in REG RSP message
> > > > > need one more type of error value : 'Multiple SI not supported' as
> > > > > none of the existing error value cover this [In case SG optionally
> > > > > support only one SI in a Routing key as per section 1.4.2.2].
> > > > >
> > > >
> > > > [Greg} I can add this. Actually there are a few more error values
that
> > > > probably make sense. - "Invalid SI" , OPC, CIC Range, SSN", for
> > > > example.  Others?
> > >
> > > Let's not get into adding a whole but of error codes here...
> > >
> > > I think that Nitin's example is adequately covered under the "Error -
> > > Invalid Routing Key" per the description in the on Page 79 of M3UA-07:
> > >
> > > "If the SGP determines that the received Routing Key data is
> > > invalid, or contains invalid parameter values, the SGP returns a
> > > Registration Response message to the ASP, containing a
> > > Registration Result "Error - Invalid Routing Key", "Error -
> > > Invalid DPC", "Error - Invalid Network Appearance" as
> > > appropriate."
> > >
> > > Rather than getting into a long list of error results, why not add an
> > > optional INFO String to the Registration Status which can contain
> > > additional implementation specific or diagnostic information.
> > >
> >
> > [Greg]  For REG RESP with multiple Registration Stati(?) this gets messy
in
> > a big hurry (optional INFO String for each Registration Status)?  I
don't
> > see this yet - I'd rather add a few additional failure codes.
>
> But no additional error codes are required in this case: "Invalid Routing
Key"
> will suffice.  There is no point (beyond diagnostics which is the point of
the
> INFO string anyway) in indicating precisely what is wrong with the Routing
> Key: it will take a human to diagnose the problem anyway.
>
> Also, there is no need to add an INFO string to registration status, just
add
> it to the REG RSP message.  If the sender wants to place diagnostics in
the
> INFO string on a per-result basis, it can limit the number of results in
the
> message to a single result.
>

[Greg3] OK, this is certainly simpler than what I was thinking. The Invalid
Routing Key reason was intended as a kind of catch-all anyway so it doesn't
surprise me that it is considered as sufficient in this case.  I'd like to
get a broader consensus on the INFO String idea though - do any others have
some feedback?

Thanks,

  Greg Sidebottom

> snip

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
Date: Thu, 19 Jul 2001 00:13:22 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail3.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [24.2.9.90]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greetings,

In the spirit of compromise, I'd propose leaving the ASP Identifier in ASP
Up as optional, but add a note that it must be used where the IPSP/SGP
cannot identify the ASP by pre-configured address/port number information
(e.g., where an ASP is resident on a Host using dynamic address/port number
assignment).  For an SGP that requires the ASP Id for other cases, we could
add the procedure that Brian proposed.

Cheers,

  Greg Sidebottom

----- Original Message -----
From: "nirmalesh" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Tuesday, July 17, 2001 1:31 PM
Subject: Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up

> Hi ,
>  If you make ASP id as a mandotary field then another issue will
>  pop up "how do you manage ASP Ids" across all ASPs , Same ASP Id could be
used by the
>  different ASPs.
> Solution could be :
>  There has to be some central  authority who will be allocating the ASP
ids across the
> system .
>   But do we really want to do it  ? Can any one suggest making it
automated !!! or get
> rid of the
>  ASP Id ,as one can achieve with the Static IP and Port No.s
>
> cheers,
> Nirmalesh
>
>
> Kurt Kite wrote:
>
> > "Brian F. G. Bidulock" wrote:
> >
> > > Kurt,
> > >
> > > Ok.  I think we're on the same page.
> > >
> > > Do agree that the SGP cannot determine from local UA
> > > configuation data?  That it must rely upon SCTP and IP
> > > configuration data?
> >
> > The SGPs must know the IP addresses and port numbers used
> > by the ASPs.
> >
> > >
> > >
> > > Your position, if I understand it correctly, is that it is
> > > sufficient that the SGP rely upon IP addresses and such to
> > > determine an ASP Id in static IP configurations.
> > >
> > > I agree, getting away without ASP Id is possible (but clumsy)
> > > where:
> >
> > Thanks. I know that must have been hard for you to admit.
> >
> > >
> > >
> > >     1.    (a)   One Host has only one ASP per SGP.
> > >
> > >           or
> > >
> > >           (b)   IP Addresses on ASP Hosts are static or
> > >                 selected from disjoint sets.
> > >
> > >           and
> > >
> > >     2.    (a)   Only one ASP per Host registers per SGP.
> > >
> > >           or
> > >
> > >           (b)   Port numbers for ASPs are static or are
> > >                 selected from disjoint sets.
> > >
> > > Situation 1(a) is uninteresting because is goes against
> > > carrier-grade recommendations.
> > >
> > > Situation 1(b) is possible, but precluded by most RFPs
> > > I've seen which require dynamic addressing... (but wait!)
> >
> > But not by the ones which do not.
> >
> > >
> > >
> > > Situation 2(a) is uninteresting because is reduces the
> > > reliability of the overall model by not allowing full mesh
> > > associations between groups of ASPs and SGPs.
> > >
> > > Situation 2(b) requires that both the SGP and the ASP be
> > > provisioned with static or complex port number assignments
> > > for each ASP in a host and would be as difficult to
> > > coordinate as assigning each ASP an ASP Id (or, more
> > > difficult).
> > >
> > > My position is that the SGP should not provision and rely
> > > on (nor be forced to provision and rely on) layer-below
> > > information (in this case IP addresses and port numbers)
> > > even when it might determine the ASP Id in a few cases.
> > > What I feel that it can be made to rely on is the UA managed
> > > identifier.
> > >
> > > Except in the uninteresting corner cases above, the SGP
> > > will need to require an ASP identifier anyay.  Making the
> > > parameter mandatory is the simple thing to do, covers all
> > > the cases, and relieves both the SGP and ASP from the need
> > > to rely on layer-below dependent configuration information.
> > >
> > > Keeping the separation between configuration of the UA and
> > > SCTP/IP will also IMHO serve to increase interoperability
> > > and portability of the UAs.
> >
> > I understand your position and I don't have a problem with it.
> > I don't have a problem with an ASP Id.
> >
> > >
> > >
> > > Do you have any interesting cases where the ASP can get
> > > away without sending an ASP Id and the ASP would buckle
> > > under the weight of these 8 bytes?
> >
> > I never indicated that an additional 8 bytes of overhead is a
performance
> > concern. My only point, and it is a simple one, is that it is possible
to determine
> > the identity of an ASP without an ASP Id if static IP addressing and
port number
> > assignment are used. So, I don't think it necessary to make ASP Id
mandatory
> > in all cases. But, I agree that it is a fairly trivial thing to do and
if it does
> > become
> > mandatory I am not going to lose any sleep over it.
> >
> > /Kurt
> >
> > >
> > >
> > > --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: Wed, 18 Jul 2001 23:34:43 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA06: Routing Key Management procedure
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.248]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

Go long.... ;)

Greg Sidebottom wrote:                           (Wed, 18 Jul 2001 23:57:46)
> Thanks Brian,
> 
>  More below ...
> 
> ----- Original Message -----
> From: "Brian F. G. Bidulock" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Wednesday, July 18, 2001 6:04 PM
> Subject: Re: M3UA06: Routing Key Management procedure
> 
> 
> > Greg,
> >
> > Please see comments below....
> >
> > Greg Sidebottom wrote:                                       (Wed, 18
Jul
> 2001 17:22:15)
> > > Hi Brian, Nitin,
> > >
> > > I'm attempting to wrap this up. See responses below ...
> > >
> > > ----- Original Message -----
> > > From: "Brian F. G. Bidulock" <[email-masked]>
> > > To: "sigtran" <[email-masked]>
> > > Cc: <[email-masked]>
> > > Sent: Thursday, July 12, 2001 6:24 PM
> > > Subject: Re: M3UA06: Routing Key Management procedure
> > >
> > >
> > > > Nitin, Greg,
> > > >
> > > > Please see comments below...
> > > >
> > > > Tomar, Nitin wrote:                      (Thu, 12 Jul 2001 14:12:23)
> > > >
> > > > [snip]
> > > > > >
> > > > > > Greg,
> > > > > >
> > > > > > I have few queries/comments on Routing key procedure.
> > > > > >
> > > > > > - Nitin.
> > > > > >
> > > > > > 1. Is RKM procedure valid for IPSP-IPSP communication as
> > > > > > well? In either case I think the draft can specify it
> > > > > > clearly in section 3.5.5 and related sections. If RKM is
> > > > > > allowed for IPSP-IPSP scenario, can client and server both
> > > > > > initiate REG-REQ and DEREG-REQ messages, I do not find any
> > > > > > reason they should not do so.
> > > > >
> > > > > [Greg] I agree that RKM should be possible for IPSP-to IPSP
> > > > > but this is not an application that I have an interest.  I'm
> > > > > not sure though that it makes sense to register in both
> > > > > directions point-to-point to set up a two way communication.
> > > > > I see that currently ASPs use the REG REQ to set-up two way
> > > > > traffic with the SG - the SG doesn't need a separate procedure
> > > > > to register for which traffic it wants from the ASP, as it is
> > > > > usually related.  But I suppose there could be an application
> > > > > to Register in both directions to set up two sets of two-way
> > > > > traffic beween IPSPs.  Do people need this described?
> > > > >
> > > > > [Nitin] I may be missing something here, do you mean that with
> > > > > REG REQ message an ASP can specify an SGP that what traffic
> > > > > it'll be sending towards it, if so how an SGP will come to
> > > > > know that the traffic related to the RK specified in REG REQ
> > > > > message is handled by ASP or the ASP wants to send this
> > > > > traffic to SGP.
> > > >
> > > > This is stiking on an SGP issue which has been raised several
> > > > times.  How does the SGP know what traffic it is to receive?
> > > >
> > > > These issues are all related.  Placing the Routing Context in
> > > > the DATA message permits the the SGP to screen the DATA messages
> > > > on the basis of valid Routing Contexts.  Breaking the routing
> > > > label into parameters permits the SG to screen the routing label
> > > > without parsing the DATA payload (after the ASP has just
> > > > finished packing it).
> > > >
> > > > Placing the restriction that the ASP can only send messages to
> > > > an SGP which have the symmetrical Routing Key associated with
> > > > the Routing Context permits the SGP to know what traffic it is
> > > > expected to process when a REG REQ is performed and screen the
> > > > messages per above when the messages actually arrive.
> > > >
> > >
> > > [Greg2]  Brian, I'm thinking that there are cases where the
> > > addressing will not be symmetrical across the SGP, so this is may
> > > be too restrictive.  For ISUP traffic this is probably fine but
> > > SCCP traffic may be a problem.  I think there are valid cases
> > > where the OPC and DPC may not be simply inverted by the ASP for
> > > the response to a query.  You could have, for example, a message
> > > coming in from an SS7 STP (after SCCP GTT) with the OPC of the STP.
> > > This message is directed to an ASP, which addresses the response
> > > directly to an SEP behind the STP, or to the SG (or another SS7
> > > node) for a GTT in the response direction.  So I think it is too
> > > restrictive to enforce this in the protocol - we should leave this
> > > to a decoupled screening function.
> >
> > Good example!  But...  If the RK (or another RK to the ASP) does not
> > also include the OPC of the original sender, a TCP conversation will
> > also fail.  So, I don't see a problem there, point code reversal is
> > still fine.  I don't think anyone really wants to split transactions
> > across ASPs.
> >
> 
> [Greg3] Why would the TCAP transaction fail?  I thought that the OPC
> of the original sender is handed up to TCAP in the SCCP Calling Party
> Address.  I surely agree with you that an SG doesn't want to split
> transactions across ASPs in a loadshare group - I'm just not sure that
> using the MTP OPC in the RK enforces this.  If a GTT has occured
> before hitting the SG, then I don't think that the MTP OPC is useful
> for keeping transactions together across a loadshare group.

For most TCAP trasnsactions in Class 0, GTT is only normally performed on
the TC-BEGIN: the TC-END uses the PC of the CgPA to route the response.  If
there is a conversation as part of the transaction, the TC-CONTINUE is sent
direct in both directions as well.

Consider the following diagram:

                                    SG       ASP

          PC X              PC Z     |       PC Y
                                     |
  (1)     BEGIN ----------> GTT -----------> BEGIN
                                     |
  (2)	  CONT  <--------------------------- CONT
                                     |
  (3)	  CONT  ---------------------------> CONT
                                     |
  (4)     END   <--------------------------- END  
                                     |	

My point was that in the case that you cited, if the ASP is not active for a
routing key that includes PC X, then the SG will never deliver (3) and the
transaction will fail.  Therefore, an ASP will be configured/ registered
against all endpoints and relay points so that it can complete transactions.
Reversal of the point codes works anyways.

But I'm sure this is probably too obscure for most.

Certainly, however, it is not acceptable to just let the ASP pick any old
SGP which has an available route, and SLS values must be honored as well
(not strewn over SGP) to avoid mis-sequencing.

For the sake of interoperability between SG and AS equipment, some rules
must be observed so that the SG can hope to obtain SS7 conformance without
having to be regression tested with every AS implementation that one can
think of...

> 
> 
> > >
> > > I'm not sure why an SG must currently parse the entire Data
> > > Payload to look at the DPC, OPC etc for the purposes of screening
> > > at the SG.  Screening may be easier if the Routing Label is in
> > > separate parameters (your proposal) but it is certainly possible
> > > either way.
> > >
> >
> > To determine which received traffic is suitable (from an ASP) for
> > both security and screening purposes, the SG must extract and
> > re-examine the Data Payload that the sending ASP just finished
> > packing.
> >
> > >
> > > > >
> > > > > >
> 
> 
> snip
> 
> 
> > > > >
> > > > > > 5. Figure for "Routing Key" parameter description can be
> > > > > > modified to indicate the Network Appearance (optional) as
> > > > > > first parameter. [To comply with section 3.3.1 stating
> > > > > > 'Where the optional Network Appearance parameter is present,
> > > > > > it must be the first parameter in the message']
> > > > >
> > > > > [Greg] Yes this is inconsistent.  I've also had the view
> > > > > expressed to me that the Network Appearance shouldn't be first
> > > > > in the DATA message either as it is technically an optional
> > > > > parameter and the Protocol Data parameter is mandatory.  For
> > > > > some people, mandatory parameters should come first before any
> > > > > optional parameters (like in SS7).  We should sort this out
> > > > > once and for all for Issue 8 - IMHO it should be first in both
> > > > > RK and DATA (when present) as suggested here but I'll do
> > > > > whatever the decoders feel is best.
> > > > >
> > >
> > > [Greg2] I don't see any opinions on which way is best here.  For
> > > now I'm assuming we should put the Network Appearance parameter
> > > (if present) as the first one in the RK as per Nitin's suggestion.
> >
> > I don't see a problem with that.  It is convenient as the first
> > parameter when present, because the parser needs it before unpacking
> > the Data Payload anyway.  M3UA bears little to no resemblance to SS7
> > paraemter formats, anyway.  SS7 goes Mandatory Fixed, Mandatory
> > Variable, Optional and Mandatory fixed parameters are usually not
> > TLV, but optional fixe are.
> >
> > I think everyone is fine with the idea of having Network Appearance
> > first.
> >
> > (On the other hand, I don't think it should be in the message
> > anyway!  It should be a Routing Context instead.)
> >
> 
> [Greg3] Yes, we do need to come to a conclusion on that other thread.
2:^0

Just thought I'd keep reminding you... ;)

> 
> 
> > >
> > > > > Of course there is a proposal from Brian to replace the NA
> > > > > everywhere with an RC - we should sort that idea out as well -
> > > > > see this thread.
> > > > >
> > > > > >
> > > > > > 6. The 'Registration Status' parameter values in REG RSP
> > > > > > message need one more type of error value : 'Multiple SI not
> > > > > > supported' as none of the existing error value cover this
> > > > > > [In case SG optionally support only one SI in a Routing key
> > > > > > as per section 1.4.2.2].
> > > > > >
> > > > >
> > > > > [Greg} I can add this. Actually there are a few more error
> > > > > values that probably make sense. - "Invalid SI" , OPC, CIC
> > > > > Range, SSN", for example.  Others?
> > > >
> > > > Let's not get into adding a whole but of error codes here...
> > > >
> > > > I think that Nitin's example is adequately covered under the
> > > > "Error - Invalid Routing Key" per the description in the on Page
> > > > 79 of M3UA-07:
> > > >
> > > > "If the SGP determines that the received Routing Key data is
> > > > invalid, or contains invalid parameter values, the SGP returns a
> > > > Registration Response message to the ASP, containing a
> > > > Registration Result "Error - Invalid Routing Key", "Error -
> > > > Invalid DPC", "Error - Invalid Network Appearance" as
> > > > appropriate."
> > > >
> > > > Rather than getting into a long list of error results, why not
> > > > add an optional INFO String to the Registration Status which can
> > > > contain additional implementation specific or diagnostic
> > > > information.
> > > >
> > >
> > > [Greg]  For REG RESP with multiple Registration Stati(?) this gets
> > > messy in a big hurry (optional INFO String for each Registration
> > > Status)?  I don't see this yet - I'd rather add a few additional
> > > failure codes.
> >
> > But no additional error codes are required in this case: "Invalid
> > Routing Key" will suffice.  There is no point (beyond diagnostics
> > which is the point of the INFO string anyway) in indicating
> > precisely what is wrong with the Routing Key: it will take a human
> > to diagnose the problem anyway.
> >
> > Also, there is no need to add an INFO string to registration status,
> > just add it to the REG RSP message.  If the sender wants to place
> > diagnostics in the INFO string on a per-result basis, it can limit
> > the number of results in the message to a single result.
> >
> 
> [Greg3] OK, this is certainly simpler than what I was thinking. The
> Invalid Routing Key reason was intended as a kind of catch-all anyway
> so it doesn't surprise me that it is considered as sufficient in this
> case.  I'd like to get a broader consensus on the INFO String idea
> though - do any others have some feedback?

It may be more sytle an philosophy than anything else, but I would prefer if
a distinct error code does not exist just to pass more information to
management.  A test of the worthiness of an error value is whether the
receiver of the error must distinguish between cases to know what next
action to perform.  This means that one can usually get away with:  Error -
Permanent Condition and Error - Transient Condition.
Below that, the code should indicate the general functional location of the
error (local, remote, this function, the routing key).  An error code which
says something like: "I didn't like how you set the second bit in the first
word of the tenth field in the third structure" doesn't accomplish much.

[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: Wed, 18 Jul 2001 23:44:30 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: m2ua-09: comment #5
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Harsh,

Let me build on that, if I may...

Figure 2 does not show SGP.  Unlike M3UA, it show associations being formed
between hosts--kinda--, not between ASP/SGP pairs.
The figure, also does not show multiple ASPs per host and does not show
multiple SGP per SG.

Also the lines drawn for the assocations touch the Host boxes and not the
ASP boxes.  This would tend to imply that the Host is an SCTP enpoint and
not the ASP (as is the case in other UAs).

The diagram does not make it clear whether multiple associations can be
formed between as single ASP and a single SGP (which is fairly much implied
as excluded in M3UA).

I agree, the concept needs to be explained in a number of places.

--Brian

[email-masked] wrote:                (Thu, 19 Jul 2001 09:26:22)
> 
> 
> Hi,
> 
> 1. Sec 4.4.1 para 2 states
> " A unique method of Interface Identifier valid
> assignment at the SG/SGP is implementation dependent but must be
> guaranteed to be unique across all SGPs in an SG."
> 
> There is no prior definition of SGP in the draft. Is the concept of SGP
here
> assumed to be the same as in m3ua?
> In any case, the concept should be explained.
> 
> regards,
> Harsh Bhondwe
> Hughes Software Systems

-- 
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, 19 Jul 2001 00:03:06 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
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.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

You don't understand: I don't want to ever have to use address/port number
information to identify an ASP, even if the network *is* statically
configured.  The rationale for this is complexity: it complicates the MIB
and local management at the SG beyond reason just to include a "corner"
case.

Kurt said he wouldn't lose any sleep and I think his argument was more
philosophical (yes, it really is possible in some cases to get away without
ASP Id), but there is no need to complicate the matter for implementations
by making them have to go dig out IP addresses and ports in special
circumstancs.

Certainly there are a number of voices on this thread that thought that it
was ok.

I have other reasons for wanting to do this:  I would like to be able to run
M3UA over SSCOP/AAL5, a PCI bus, a PIPE/FIFO, and I don't want to go digging
out their TSAPs either.

--Brian

Greg Sidebottom wrote:                              (Thu, 19 Jul 2001
00:13:22)
> Greetings,
> 
> In the spirit of compromise, I'd propose leaving the ASP Identifier in ASP
> Up as optional, but add a note that it must be used where the IPSP/SGP
> cannot identify the ASP by pre-configured address/port number information
> (e.g., where an ASP is resident on a Host using dynamic address/port
number
> assignment).  For an SGP that requires the ASP Id for other cases, we
could
> add the procedure that Brian proposed.
> 
> Cheers,
> 
>   Greg Sidebottom
> 
> ----- Original Message -----
> From: "nirmalesh" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Tuesday, July 17, 2001 1:31 PM
> Subject: Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
> 
> 
> > Hi ,
> >  If you make ASP id as a mandotary field then another issue will
> >  pop up "how do you manage ASP Ids" across all ASPs , Same ASP Id could
be used by the
> >  different ASPs.
> > Solution could be :
> >  There has to be some central  authority who will be allocating the ASP
ids across the
> > system .
> >   But do we really want to do it  ? Can any one suggest making it
automated !!! or get
> > rid of the
> >  ASP Id ,as one can achieve with the Static IP and Port No.s
> >
> > cheers,
> > Nirmalesh
> >
> >
> > Kurt Kite wrote:
> >
> > > "Brian F. G. Bidulock" wrote:
> > >
> > > > Kurt,
> > > >
> > > > Ok.  I think we're on the same page.
> > > >
> > > > Do agree that the SGP cannot determine from local UA
> > > > configuation data?  That it must rely upon SCTP and IP
> > > > configuration data?
> > >
> > > The SGPs must know the IP addresses and port numbers used
> > > by the ASPs.
> > >
> > > >
> > > >
> > > > Your position, if I understand it correctly, is that it is
> > > > sufficient that the SGP rely upon IP addresses and such to
> > > > determine an ASP Id in static IP configurations.
> > > >
> > > > I agree, getting away without ASP Id is possible (but clumsy)
> > > > where:
> > >
> > > Thanks. I know that must have been hard for you to admit.
> > >
> > > >
> > > >
> > > >     1.    (a)   One Host has only one ASP per SGP.
> > > >
> > > >           or
> > > >
> > > >           (b)   IP Addresses on ASP Hosts are static or
> > > >                 selected from disjoint sets.
> > > >
> > > >           and
> > > >
> > > >     2.    (a)   Only one ASP per Host registers per SGP.
> > > >
> > > >           or
> > > >
> > > >           (b)   Port numbers for ASPs are static or are
> > > >                 selected from disjoint sets.
> > > >
> > > > Situation 1(a) is uninteresting because is goes against
> > > > carrier-grade recommendations.
> > > >
> > > > Situation 1(b) is possible, but precluded by most RFPs
> > > > I've seen which require dynamic addressing... (but wait!)
> > >
> > > But not by the ones which do not.
> > >
> > > >
> > > >
> > > > Situation 2(a) is uninteresting because is reduces the
> > > > reliability of the overall model by not allowing full mesh
> > > > associations between groups of ASPs and SGPs.
> > > >
> > > > Situation 2(b) requires that both the SGP and the ASP be
> > > > provisioned with static or complex port number assignments
> > > > for each ASP in a host and would be as difficult to
> > > > coordinate as assigning each ASP an ASP Id (or, more
> > > > difficult).
> > > >
> > > > My position is that the SGP should not provision and rely
> > > > on (nor be forced to provision and rely on) layer-below
> > > > information (in this case IP addresses and port numbers)
> > > > even when it might determine the ASP Id in a few cases.
> > > > What I feel that it can be made to rely on is the UA managed
> > > > identifier.
> > > >
> > > > Except in the uninteresting corner cases above, the SGP
> > > > will need to require an ASP identifier anyay.  Making the
> > > > parameter mandatory is the simple thing to do, covers all
> > > > the cases, and relieves both the SGP and ASP from the need
> > > > to rely on layer-below dependent configuration information.
> > > >
> > > > Keeping the separation between configuration of the UA and
> > > > SCTP/IP will also IMHO serve to increase interoperability
> > > > and portability of the UAs.
> > >
> > > I understand your position and I don't have a problem with it.
> > > I don't have a problem with an ASP Id.
> > >
> > > >
> > > >
> > > > Do you have any interesting cases where the ASP can get
> > > > away without sending an ASP Id and the ASP would buckle
> > > > under the weight of these 8 bytes?
> > >
> > > I never indicated that an additional 8 bytes of overhead is a
> performance
> > > concern. My only point, and it is a simple one, is that it is possible
> to determine
> > > the identity of an ASP without an ASP Id if static IP addressing and
> port number
> > > assignment are used. So, I don't think it necessary to make ASP Id
> mandatory
> > > in all cases. But, I agree that it is a fairly trivial thing to do and
> if it does
> > > become
> > > mandatory I am not going to lose any sleep over it.
> > >
> > > /Kurt
> > >
> > > >
> > > >
> > > > --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]

-- 
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: status report
Date: Thu, 19 Jul 2001 08:41:58 +0300
Importance: high
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 Kevin,

> Another issue is the TUA you raised in this email.  We did an internal
> review of SUA and TUA and had a concern that TUA would be required to
> transmit MAP and IANA messages.  We are satisfied with SUA as 
> long as it will handle Map, Cap, Tcap. 

If you find any shortcomings with regard to SUA in order to handle MAP, CAP,
TCAP messages, please let me know ASAP! I am hoping to close all of the
issues by Friday, resubmit the draft and ask for a WG last call.

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA06: Routing Key Management procedure
Date: Thu, 19 Jul 2001 02:02:10 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail1.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail1.rdc1.on.home.com [24.2.9.88]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

One last (?) response below before calling it a night!

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Thursday, July 19, 2001 12:34 AM
Subject: Re: M3UA06: Routing Key Management procedure

> Greg,
>
> Go long.... ;)
>
> Greg Sidebottom wrote:                           (Wed, 18 Jul 2001
23:57:46)
> > Thanks Brian,
> >
> >  More below ...
> >
> > ----- Original Message -----
> > From: "Brian F. G. Bidulock" <[email-masked]>
> > To: "sigtran" <[email-masked]>
> > Sent: Wednesday, July 18, 2001 6:04 PM
> > Subject: Re: M3UA06: Routing Key Management procedure
> >
> >
> > > Greg,
> > >
> > > Please see comments below....
> > >
> > > Greg Sidebottom wrote:                                       (Wed, 18
Jul
> > 2001 17:22:15)
> > > > Hi Brian, Nitin,
> > > >
> > > > I'm attempting to wrap this up. See responses below ...
> > > >
> > > > ----- Original Message -----
> > > > From: "Brian F. G. Bidulock" <[email-masked]>
> > > > To: "sigtran" <[email-masked]>
> > > > Cc: <[email-masked]>
> > > > Sent: Thursday, July 12, 2001 6:24 PM
> > > > Subject: Re: M3UA06: Routing Key Management procedure
> > > >
> > > >
> > > > > Nitin, Greg,
> > > > >
> > > > > Please see comments below...
> > > > >
> > > > > Tomar, Nitin wrote:                      (Thu, 12 Jul 2001
14:12:23)
> > > > >
> > > > > [snip]
> > > > > > >
> > > > > > > Greg,
> > > > > > >
> > > > > > > I have few queries/comments on Routing key procedure.
> > > > > > >
> > > > > > > - Nitin.
> > > > > > >
> > > > > > > 1. Is RKM procedure valid for IPSP-IPSP communication as
> > > > > > > well? In either case I think the draft can specify it
> > > > > > > clearly in section 3.5.5 and related sections. If RKM is
> > > > > > > allowed for IPSP-IPSP scenario, can client and server both
> > > > > > > initiate REG-REQ and DEREG-REQ messages, I do not find any
> > > > > > > reason they should not do so.
> > > > > >
> > > > > > [Greg] I agree that RKM should be possible for IPSP-to IPSP
> > > > > > but this is not an application that I have an interest.  I'm
> > > > > > not sure though that it makes sense to register in both
> > > > > > directions point-to-point to set up a two way communication.
> > > > > > I see that currently ASPs use the REG REQ to set-up two way
> > > > > > traffic with the SG - the SG doesn't need a separate procedure
> > > > > > to register for which traffic it wants from the ASP, as it is
> > > > > > usually related.  But I suppose there could be an application
> > > > > > to Register in both directions to set up two sets of two-way
> > > > > > traffic beween IPSPs.  Do people need this described?
> > > > > >
> > > > > > [Nitin] I may be missing something here, do you mean that with
> > > > > > REG REQ message an ASP can specify an SGP that what traffic
> > > > > > it'll be sending towards it, if so how an SGP will come to
> > > > > > know that the traffic related to the RK specified in REG REQ
> > > > > > message is handled by ASP or the ASP wants to send this
> > > > > > traffic to SGP.
> > > > >
> > > > > This is stiking on an SGP issue which has been raised several
> > > > > times.  How does the SGP know what traffic it is to receive?
> > > > >
> > > > > These issues are all related.  Placing the Routing Context in
> > > > > the DATA message permits the the SGP to screen the DATA messages
> > > > > on the basis of valid Routing Contexts.  Breaking the routing
> > > > > label into parameters permits the SG to screen the routing label
> > > > > without parsing the DATA payload (after the ASP has just
> > > > > finished packing it).
> > > > >
> > > > > Placing the restriction that the ASP can only send messages to
> > > > > an SGP which have the symmetrical Routing Key associated with
> > > > > the Routing Context permits the SGP to know what traffic it is
> > > > > expected to process when a REG REQ is performed and screen the
> > > > > messages per above when the messages actually arrive.
> > > > >
> > > >
> > > > [Greg2]  Brian, I'm thinking that there are cases where the
> > > > addressing will not be symmetrical across the SGP, so this is may
> > > > be too restrictive.  For ISUP traffic this is probably fine but
> > > > SCCP traffic may be a problem.  I think there are valid cases
> > > > where the OPC and DPC may not be simply inverted by the ASP for
> > > > the response to a query.  You could have, for example, a message
> > > > coming in from an SS7 STP (after SCCP GTT) with the OPC of the STP.
> > > > This message is directed to an ASP, which addresses the response
> > > > directly to an SEP behind the STP, or to the SG (or another SS7
> > > > node) for a GTT in the response direction.  So I think it is too
> > > > restrictive to enforce this in the protocol - we should leave this
> > > > to a decoupled screening function.
> > >
> > > Good example!  But...  If the RK (or another RK to the ASP) does not
> > > also include the OPC of the original sender, a TCP conversation will
> > > also fail.  So, I don't see a problem there, point code reversal is
> > > still fine.  I don't think anyone really wants to split transactions
> > > across ASPs.
> > >
> >
> > [Greg3] Why would the TCAP transaction fail?  I thought that the OPC
> > of the original sender is handed up to TCAP in the SCCP Calling Party
> > Address.  I surely agree with you that an SG doesn't want to split
> > transactions across ASPs in a loadshare group - I'm just not sure that
> > using the MTP OPC in the RK enforces this.  If a GTT has occured
> > before hitting the SG, then I don't think that the MTP OPC is useful
> > for keeping transactions together across a loadshare group.
>
> For most TCAP trasnsactions in Class 0, GTT is only normally performed
> on the TC-BEGIN: the TC-END uses the PC of the CgPA to route the
> response.  If there is a conversation as part of the transaction, the
> TC-CONTINUE is sent direct in both directions as well.
>
> Consider the following diagram:
>
>                                     SG       ASP
>
>           PC X              PC Z     |       PC Y
>                                      |
>   (1)     BEGIN ----------> GTT -----------> BEGIN
>                                      |
>   (2)   CONT  <--------------------------- CONT
>                                      |
>   (3)   CONT  ---------------------------> CONT
>                                      |
>   (4)     END   <--------------------------- END
>                                      |
>
> My point was that in the case that you cited, if the ASP is not active
> for a routing key that includes PC X, then the SG will never deliver (3)
> and the transaction will fail.  Therefore, an ASP will be configured/
> registered against all endpoints and relay points so that it can
> complete transactions.  Reversal of the point codes works anyways.
>
> But I'm sure this is probably too obscure for most.

[Greg4]  OK - but now you have me worried  - Are you saying that an Operator
would need to configure/register a Routing Key for each possible endpoint
and relay points that may initiate a transaction with the ASP?  Or would you
agree that a Routing Key in an REG REQ without an OPC would be sufficient to
cause the ASP to be registered against all end-points and relay points so
that it can complete transactions?  The reversal would be "ANY to PCY" and
"PC Y to ANY".

>
> Certainly, however, it is not acceptable to just let the ASP pick any
> old SGP which has an available route, and SLS values must be honored as
> well (not strewn over SGP) to avoid mis-sequencing.
>

[Greg4] I definitely agree in general.  Though there could be some
applications (simple query /response) where the ASP wouldn't care as there
is nothing to mis-sequence.

Cheers

   Greg

> snip

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: asodhi <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: hi all
Date: Thu, 19 Jul 2001 11:44:32 +0530
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-SMTP-HELO: smtp.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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

i am searching the datatypes for the parameter to be specified for the SUA
upper layer primitives( N-connect, N-data, etc), in which i got few.

reply pl.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA v07: Some Comments
Date: Thu, 19 Jul 2001 02:25:24 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail1.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail1.rdc1.on.home.com [24.2.9.88]
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 4.0 Transitional//EN"> <HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"> <META
content="MSHTML 5.50.4207.2601" name=GENERATOR> <STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Thanks Vikas,</FONT></DIV> <DIV><FONT
face=Arial size=2></FONT>&nbsp;</DIV> <DIV><FONT face=Arial size=2>Responses
(finally!) below ...</FONT></DIV> <BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT:
#000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color:
black"><B>From:</B> 
  <A title=[email-masked] 
  href="mailto:[email-masked]">Vikas</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A 
  title=[email-masked] 
  href="mailto:[email-masked]">sigtran</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Wednesday, July 11, 2001 6:12 
  AM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> M3UA v07: Some
Comments</DIV>
  <DIV><BR></DIV>
  <DIV><FONT size=2>
  <DIV><FONT size=2><FONT size=2><FONT size=2>
  <P>hi everybody,</P>
  <P>please&nbsp;consider on following problems and suggestions (in context
of 
  M3UA draft v07):</P>
  <P>&nbsp;</P>
  <P>3.2 Variable-Length Parameter Format</P></FONT><FONT size=2>
  <P>Parameter Tag: 16 bits (unsigned integer)</P></FONT><FONT size=2><FONT 
  size=2>
  <P>"Common parameters used by adaptation layers are in the range of 0x00
to 
  0xff. M3UA-specific parameters </P>
  <P>have Tags in the range 0x80 to 0xbf."</P>
  <P>Problem -&gt; </P>
  <P>The range for M3UA-specific parameters is inside the range for Common 
  parameters.</P>
  <P><FONT face=Arial></FONT>&nbsp;</P>
  <P><FONT face=Arial>[Greg] Ooops - this is a mistake by me.&nbsp; I
intended 
  to give the range for common parameters as 0x00 to 0x3F.&nbsp; This was
part 
  of my plan to divide up the values among the adaptation layers like 
  so:</FONT></P>
  <P><FONT face=Arial>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x00 to 0x3f&nbsp; 
  Common/IUA parameters<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x40 to 0x7f&nbsp;

  M2UA-specific<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x80 to 0xbf&nbsp; 
  M3UA-specific<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0xc0 to 0xff&nbsp;&nbsp; 
  SUA-specific</FONT></P>
  <P><FONT face=Arial>I didn't have time to discuss this with Ken before he 
  re-issued M2UA (or John wrt to SUA) so it probably doesn't line up
yet.&nbsp; 
  In any case it is still just&nbsp;a proposal at this time.</FONT></P>
  <P><FONT face=Arial></FONT>&nbsp;</P>
  <P><FONT face=Arial></FONT>&nbsp;</P>
  <P></P>
  <P>3.2 Variable-Length Parameter Format</P><FONT size=2>
  <P>Parameter Tag: 16 bits (unsigned integer)</P></FONT>
  <P>The parameter Tags defined are as follows:</P></FONT></FONT><FONT
size=2>
  <P>0x88 Registration Result</P>
  <P>0x89 De-registration Result</P>
  <P>........</P><FONT size=2>
  <P>0x90 Registration Results</P>
  <P>0x91 De-Registration Results</P></FONT></FONT><FONT size=2>
  <P>Problem -&gt;</P>
  <P>the parameters&nbsp;"Registration Result" and "De-registration Result"
are 
  defined twice.</P>
  <P>&nbsp;</P>
  <P><FONT face=Arial>[Greg] 0x90 and 0x91 are now deleted based on
discussion 
  in another thread.</FONT></P>
  <P><FONT face=Arial></FONT>&nbsp;</P>
  <P><FONT face=Arial></FONT>&nbsp;</P><FONT size=2>
  <P>3.5.3 ASP Down</P>
  <P>"The ASP Down message is used to indicate to a remote M3UA peer that
the 
  </P>
  <P>adaptation layer is NOT ready to receive DATA, SSNM or ASPTM
messages."</P>
  <P>Suggestion -&gt;</P>
  <P>The above para should be:</P>
  <P>"The ASP Down message is used to indicate to a remote M3UA peer that
the 
  </P>
  <P>adaptation layer is NOT ready to receive DATA, SSNM, RKM&nbsp;or ASPTM 
  messages."</P><FONT size=2><FONT size=2>
  <P>&nbsp;</P>
  <P><FONT face=Arial>[Greg] Sounds correct - I will change for Issue 
  8.</FONT></P>
  <P><FONT face=Arial></FONT>&nbsp;</P>
  <P>4.3.3 ASP Auditing</P>
  <P></FONT>See the 6th line in the&nbsp;6th para:</P>
  <P>"If the SS7 destination is available and </P>
  <P>congested, the SGP responds with an SCON message in addition to the
</P>
  <P>DAVA message."</P>
  <P>Does SCON&nbsp; not mean it is congested and available (afterall, how
can 
  we find out congestion on a route that is unavailable!)? So no need for
the 
  DAVA message here.</P>
  <P><FONT face=Arial></FONT>&nbsp;</P>
  <P><FONT face=Arial>[Greg] There was an earlier thread on this - we agreed
to 
  decouple congestion and availability indications.&nbsp; I&nbsp;think it 
  is&nbsp;possible for an SS7&nbsp;route to be congested and restricted
(where 
  this is supported) so an SCON may not necessarily imply
availability.&nbsp; 
  </FONT></P><FONT size=2><FONT size=2>
  <P><FONT face=Arial></FONT>&nbsp;</P>
  <P><FONT face=Arial></FONT>&nbsp;</P>
  <P>4.2.3.1 ASP Up Procedures</P>
  <P></FONT>"At the ASP, the ASP Up Ack message received is not
acknowledged. 
  Layer </P>
  <P>Management is informed with an M-ASP_UP confirm primitive. When an
ASP</P>
  <P>enters the ASP-Inactive state from the ASP_Down state towards an SGP
</P>
  <P>the M3UA MUST mark all SS7 destinations configured to be reachable via
</P>
  <P>this SGP as available."</P>
  <P>After this how and when the ASP will know the actual status of the SS7 
  network? I think&nbsp;SG, after sending ASP UP ACK message,&nbsp;should
tell 
  ASP about all the Unavailable/congested/Restricted destinations 
  automatically.</P></FONT>
  <P><FONT face=Arial></FONT>&nbsp;</P>
  <P><FONT face=Arial>[Greg] The SG could do this but then there would be a 
  delay in starting traffic (like in an MTP Restart in SS7).&nbsp; The other

  option is to allow response mode management to work, updating the
destination 
  stati as you go.&nbsp; </FONT></P>
  <P><FONT face=Arial></FONT>&nbsp;</P>
  <P><FONT face=Arial></FONT>&nbsp;</P>
  <P></FONT></FONT></FONT>4.2.3.7 Heartbeat Procedures</P>
  <P></FONT>"At the ASP, if no Heartbeat Ack message (or any other M3UA
message) 
  is </P>
  <P>received from the M3UA peer within 2*T(beat), the remote M3UA peer is
</P>
  <P>considered unavailable. Transmission of Heartbeat messages is stopped
</P>
  <P>and the ASP SHOULD attempt to re-establish communication with the SGP
</P>
  <P>M3UA peer."</P>
  <P>Problem -&gt;</P>
  <P>how a ASP can attempt to re-stablish communication with a SGP if it
(ASP) 
  has been configured to behave as server for this SGP?</P>
  <P>Suggestion -&gt;</P>
  <P>The above para should be:</P>
  <P>"At the M3UA (ASP/SGP/IPSP), if no Heartbeat Ack message (or any other
M3UA 
  message) is </P>
  <P>received from the M3UA peer within 2*T(beat), the remote M3UA peer is
</P>
  <P>considered unavailable. Transmission of Heartbeat messages is stopped
</P>
  <P>and the signalling process SHOULD attempt to re-establish communication
if 
  it is configured as client for the disconnected&nbsp;M3UA peer."</P>
  <P><FONT face=Arial></FONT>&nbsp;</P>
  <P><FONT face=Arial>[Greg] OK, I have made the cange with a small
modification 
  - In the current text an SGP doesn't initiate Heartbeat messages so I
think a 
  Heartbeat Ack would only come to an ASP or IPSP, not an SGP.&nbsp; So I
think 
  the first clause should probably be&nbsp; " At the ASP or IPSP, if no 
  Heartbeat Ack message .....</FONT></P>
  <P><FONT face=Arial></FONT>&nbsp;</P>
  <P><FONT face=Arial></FONT>&nbsp;</P></FONT></DIV><FONT size=2><FONT
size=2>
  <P>4.4 MTP3 Restart</P>
  <DIV>In the second para:</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>"<FONT size=2>During the second part of the restart 
  <P>procedure the SGP M3UA layers at the SGPs inform all concerned ASPs in
</P>
  <P>the ASP-ACTIVE, ASP-STANDBY or ASP-INACTIVE states of any unavailable
</P>
  <P>SS7 destinations using the DUNA message."</P>
  <P>should be:</P>
  <P>"<FONT size=2>During the second part of the restart </P>
  <P>procedure the SGP M3UA layers at the SGPs inform all concerned ASPs in
</P>
  <P>the ASP-ACTIVE, ASP-STANDBY or ASP-INACTIVE states of any 
  unavailable/congested/restricted </P>
  <P>SS7 destinations using the DUNA/SCON/DRST message respectively."</P>
  <P><FONT face=Arial></FONT>&nbsp;</P>
  <P><FONT face=Arial>[Greg] I don't think the SGP can determine 
  congested&nbsp;destinations&nbsp;when it is restarting and not sending any

  traffic yet.&nbsp; I added the /restricted and /DRST text as I think that
is 
  correct</FONT></P>
  <P><FONT face=Arial></FONT>&nbsp;</P>
  <P><FONT face=Arial></FONT>&nbsp;</P>
  <P>4.4 MTP3 Restart</P>
  <P>In the last para:</P>
  <P>"<FONT size=2>When the M3UA layer at an ASP receives a DUNA message 
  indicating SS7 </P>
  <P>network isolation at an SG, it will stop any affected traffic via this
</P>
  <P>route. When the M3UA subsequently receives any DUNA messages from an
SGP 
  </P>
  <P>it will mark the affected SS7 destinations as unavailable via that SG. 
"</P>
  <P>Suggestion -&gt;</P>
  <P>Analogus to the MTP restart mechanism, some mechanism should be defined
to 
  consider all routes via the SG to be available and subsequently updated
via 
  DUNA/SCON/DRST messages.</P>
  <P>&nbsp;</P>
  <P><FONT face=Arial>[Greg] This is the way the text used to read but I
think 
  Brian had an issue with it and I made a change.&nbsp; I'll try and dig up
the 
  e-mail tomorrow, unless Brian can remember it first.</FONT></P>
  <P><FONT face=Arial>Thanks again,</FONT></P>
  <P><FONT face=Arial>&nbsp;&nbsp;&nbsp; Greg 
 
Sidebottom</FONT></P></FONT></FONT></FONT></FONT></DIV></FONT></FONT></DIV><
/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>
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
Date: Thu, 19 Jul 2001 09:45:00 +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 Greg,

> In the spirit of compromise, I'd propose leaving the ASP 
> Identifier in ASP Up as optional, but add a note that it must 
> be used where the IPSP/SGP cannot identify the ASP by pre-
> configured address/port number information
> (e.g., where an ASP is resident on a Host using dynamic 
> address/port number assignment).  For an SGP that requires 
> the ASP Id for other cases, we could add the procedure 
> that Brian proposed.

I second this.

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 19 Jul 2001 01:52:34 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: hi all
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

asodhi,

Precise datatypes are implementation dependent, however, if you are looking
for an example implementation of most of the primitives, take a look at the
STREAMS Network Provider Interface Specification which is available at:

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

--Brian

asodhi wrote:                                    (Thu, 19 Jul 2001 11:44:32)
> i am searching the datatypes for the parameter to be specified for the SUA
> upper layer primitives( N-connect, N-data, etc), in which i got few.
> 
> reply pl.
> 

-- 
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, 19 Jul 2001 01:56:49 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

Then may I suggest that we add the errors:

	Error - ASP Identifier Required
	Error - Invalid ASP Identifier

as a valid reponses of an SG to a ASP Up message.

--Brian

John Loughney wrote:                   (Thu, 19 Jul 2001 09:45:00)
> Hi Greg,
> 
> > In the spirit of compromise, I'd propose leaving the ASP 
> > Identifier in ASP Up as optional, but add a note that it must 
> > be used where the IPSP/SGP cannot identify the ASP by pre-
> > configured address/port number information
> > (e.g., where an ASP is resident on a Host using dynamic 
> > address/port number assignment).  For an SGP that requires 
> > the ASP Id for other cases, we could add the procedure 
> > that Brian proposed.
> 
> I second this.
> 
> 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: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
Date: Thu, 19 Jul 2001 10:04:14 +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,

John,
> 
> Then may I suggest that we add the errors:
> 
> 	Error - ASP Identifier Required
> 	Error - Invalid ASP Identifier
> 
> as a valid reponses of an SG to a ASP Up message.

I think I can live with those ...

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 19 Jul 2001 02:05:11 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA06: Routing Key Management procedure
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

Way down to the bottom...

Greg Sidebottom wrote:                                       (Thu, 19 Jul
2001 02:02:10)
> Hi Brian,
> 
> One last (?) response below before calling it a night!
> 
> ----- Original Message -----
> From: "Brian F. G. Bidulock" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Thursday, July 19, 2001 12:34 AM
> Subject: Re: M3UA06: Routing Key Management procedure
> 
> 
> > Greg,
> >
> > Go long.... ;)
> >
> > Greg Sidebottom wrote:                           (Wed, 18 Jul 2001
> 23:57:46)
> > > Thanks Brian,
> > >
> > >  More below ...
> > >
> > > ----- Original Message -----
> > > From: "Brian F. G. Bidulock" <[email-masked]>
> > > To: "sigtran" <[email-masked]>
> > > Sent: Wednesday, July 18, 2001 6:04 PM
> > > Subject: Re: M3UA06: Routing Key Management procedure
> > >
> > >
> > > > Greg,
> > > >
> > > > Please see comments below....
> > > >
> > > > Greg Sidebottom wrote:                                       (Wed,
18
> Jul
> > > 2001 17:22:15)
> > > > > Hi Brian, Nitin,
> > > > >
> > > > > I'm attempting to wrap this up. See responses below ...
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Brian F. G. Bidulock" <[email-masked]>
> > > > > To: "sigtran" <[email-masked]>
> > > > > Cc: <[email-masked]>
> > > > > Sent: Thursday, July 12, 2001 6:24 PM
> > > > > Subject: Re: M3UA06: Routing Key Management procedure
> > > > >
> > > > >
> > > > > > Nitin, Greg,
> > > > > >
> > > > > > Please see comments below...
> > > > > >
> > > > > > Tomar, Nitin wrote:                      (Thu, 12 Jul 2001
> 14:12:23)
> > > > > >
> > > > > > [snip]
> > > > > > > >
> > > > > > > > Greg,
> > > > > > > >
> > > > > > > > I have few queries/comments on Routing key procedure.
> > > > > > > >
> > > > > > > > - Nitin.
> > > > > > > >
> > > > > > > > 1. Is RKM procedure valid for IPSP-IPSP communication as
> > > > > > > > well? In either case I think the draft can specify it
> > > > > > > > clearly in section 3.5.5 and related sections. If RKM is
> > > > > > > > allowed for IPSP-IPSP scenario, can client and server both
> > > > > > > > initiate REG-REQ and DEREG-REQ messages, I do not find any
> > > > > > > > reason they should not do so.
> > > > > > >
> > > > > > > [Greg] I agree that RKM should be possible for IPSP-to IPSP
> > > > > > > but this is not an application that I have an interest.  I'm
> > > > > > > not sure though that it makes sense to register in both
> > > > > > > directions point-to-point to set up a two way communication.
> > > > > > > I see that currently ASPs use the REG REQ to set-up two way
> > > > > > > traffic with the SG - the SG doesn't need a separate procedure
> > > > > > > to register for which traffic it wants from the ASP, as it is
> > > > > > > usually related.  But I suppose there could be an application
> > > > > > > to Register in both directions to set up two sets of two-way
> > > > > > > traffic beween IPSPs.  Do people need this described?
> > > > > > >
> > > > > > > [Nitin] I may be missing something here, do you mean that with
> > > > > > > REG REQ message an ASP can specify an SGP that what traffic
> > > > > > > it'll be sending towards it, if so how an SGP will come to
> > > > > > > know that the traffic related to the RK specified in REG REQ
> > > > > > > message is handled by ASP or the ASP wants to send this
> > > > > > > traffic to SGP.
> > > > > >
> > > > > > This is stiking on an SGP issue which has been raised several
> > > > > > times.  How does the SGP know what traffic it is to receive?
> > > > > >
> > > > > > These issues are all related.  Placing the Routing Context in
> > > > > > the DATA message permits the the SGP to screen the DATA messages
> > > > > > on the basis of valid Routing Contexts.  Breaking the routing
> > > > > > label into parameters permits the SG to screen the routing label
> > > > > > without parsing the DATA payload (after the ASP has just
> > > > > > finished packing it).
> > > > > >
> > > > > > Placing the restriction that the ASP can only send messages to
> > > > > > an SGP which have the symmetrical Routing Key associated with
> > > > > > the Routing Context permits the SGP to know what traffic it is
> > > > > > expected to process when a REG REQ is performed and screen the
> > > > > > messages per above when the messages actually arrive.
> > > > > >
> > > > >
> > > > > [Greg2]  Brian, I'm thinking that there are cases where the
> > > > > addressing will not be symmetrical across the SGP, so this is may
> > > > > be too restrictive.  For ISUP traffic this is probably fine but
> > > > > SCCP traffic may be a problem.  I think there are valid cases
> > > > > where the OPC and DPC may not be simply inverted by the ASP for
> > > > > the response to a query.  You could have, for example, a message
> > > > > coming in from an SS7 STP (after SCCP GTT) with the OPC of the
STP.
> > > > > This message is directed to an ASP, which addresses the response
> > > > > directly to an SEP behind the STP, or to the SG (or another SS7
> > > > > node) for a GTT in the response direction.  So I think it is too
> > > > > restrictive to enforce this in the protocol - we should leave this
> > > > > to a decoupled screening function.
> > > >
> > > > Good example!  But...  If the RK (or another RK to the ASP) does not
> > > > also include the OPC of the original sender, a TCP conversation will
> > > > also fail.  So, I don't see a problem there, point code reversal is
> > > > still fine.  I don't think anyone really wants to split transactions
> > > > across ASPs.
> > > >
> > >
> > > [Greg3] Why would the TCAP transaction fail?  I thought that the OPC
> > > of the original sender is handed up to TCAP in the SCCP Calling Party
> > > Address.  I surely agree with you that an SG doesn't want to split
> > > transactions across ASPs in a loadshare group - I'm just not sure that
> > > using the MTP OPC in the RK enforces this.  If a GTT has occured
> > > before hitting the SG, then I don't think that the MTP OPC is useful
> > > for keeping transactions together across a loadshare group.
> >
> > For most TCAP trasnsactions in Class 0, GTT is only normally performed
> > on the TC-BEGIN: the TC-END uses the PC of the CgPA to route the
> > response.  If there is a conversation as part of the transaction, the
> > TC-CONTINUE is sent direct in both directions as well.
> >
> > Consider the following diagram:
> >
> >                                     SG       ASP
> >
> >           PC X              PC Z     |       PC Y
> >                                      |
> >   (1)     BEGIN ----------> GTT -----------> BEGIN
> >                                      |
> >   (2)   CONT  <--------------------------- CONT
> >                                      |
> >   (3)   CONT  ---------------------------> CONT
> >                                      |
> >   (4)     END   <--------------------------- END
> >                                      |
> >
> > My point was that in the case that you cited, if the ASP is not active
> > for a routing key that includes PC X, then the SG will never deliver (3)
> > and the transaction will fail.  Therefore, an ASP will be configured/
> > registered against all endpoints and relay points so that it can
> > complete transactions.  Reversal of the point codes works anyways.
> >
> > But I'm sure this is probably too obscure for most.
> 
> [Greg4]  OK - but now you have me worried  - Are you saying that an
Operator
> would need to configure/register a Routing Key for each possible endpoint
> and relay points that may initiate a transaction with the ASP?  Or would
you
> agree that a Routing Key in an REG REQ without an OPC would be sufficient
to
> cause the ASP to be registered against all end-points and relay points so
> that it can complete transactions?  The reversal would be "ANY to PCY" and
> "PC Y to ANY".

Looks like.  Unless ASPs configured/registered in different routing contexts
want to share transaction state pretty_much_all_the_time.

> 
> 
> >
> > Certainly, however, it is not acceptable to just let the ASP pick any
> > old SGP which has an available route, and SLS values must be honored as
> > well (not strewn over SGP) to avoid mis-sequencing.
> >
> 
> [Greg4] I definitely agree in general.  Though there could be some
> applications (simple query /response) where the ASP wouldn't care as there
> is nothing to mis-sequence.

I would suggest RPC for that rather than M3UA.

--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, 19 Jul 2001 12:36:17 +0530
From: [email-masked]
Reply-To: [email-masked]
Organization: Wipro Technologies
X-Mailer: Mozilla 4.74 [en] (WinNT; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
CC: "Vydyam, Anil [MDN05:WT13:EXCH]" <[email-masked]>, "Mangalpally,
Narsimuloo [WBNG:WT16:SMTPPART]" 
    <[email-masked]> , [email-masked]
Subject: RE: Status of sigtran protocols
X-SMTP-HELO: wiproecmx1.wipro.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: wiproecmx1.wipro.com [164.164.31.5]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

DUA draft referenced has expired. An updated draft has been re-submitted and
guess will be announced on this list shortly.

Ive attached the same here for your convenience.

Thanks,
Ranjith..

-----Original Message-----
From: Kevin McCandless [SMTP:[email-masked]] Sent: Thursday, July
19, 2001 2:48 AM
To: sigtran
Subject: Status of sigtran protocols

Attached you will find and MS word document that takes the information
Lyndon put together and formats it a little and includes two additional
items SCTP and TUA.  I needed this for my internal tracking.  If you would
like, I can keep this up to date for the group.

Please provide text edits Lyndon...

Sincerely,

Kevin McCandless
Senior Network Planner
Illuminet
913-814-6397
[email-masked]

 << File: ATT00052.html >>  << File: Sigtran-status.doc >>  << File:
ATT00053.txt >>

Internet Engineering Task Force                               A. Vydyam
                                                            R. Mukundan
                                                         N. Mangalpally
                                                        Nortel Networks
                                                          Ken Morneault
                                                          Cisco Systems
Expires in 6 months                                           July 2001

                DPNSS/DASS 2 extensions to the IUA protocol
                      <draft-ietf-sigtran-dua-00.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

Abstract

   This document defines a mechanism for backhauling of DPNSS/DASS2
   messages over IP by extending the ISDN User Adaptation Layer
   Protocol reference RFC3057. This document aims to become an Appendix
   to IUA and to be the base for a DUA implementation.

Table of Contents

      1.0 Introduction ......................................... 3
        1.1  Scope ............................................. 3
        1.2  Terminology ....................................... 3
        1.3  DPNSS Overview .................................... 3
        1.4  Proposed DPNSS Backhaul Architecture .............. 4

Vydyam/Mukundan/Mangalpally/Morneault                                 1 
Internet Draft        draft-ietf-sigtran-dua-00.txt           July 2001

      2.0 Changes from IUA...................................... 4
        2.1  Message Header..................................... 4
        2.2  Adaptation Layer Identifier........................ 5
        2.3  Unit Data Message.................................. 5
        2.4  Status Message..................................... 5
        2.5  Error Message...................................... 6
      3.0 IANA Considerations................................... 6
      4.0 Message Sequence in DUA............................... 6
        4.1  Resetting of single DLC............................ 6
        4.2  Resetting all DLCs in a link....................... 7
        4.3  Information Transfer on a DLC...................... 7
        4.4  Link Takedown(Single DLC).......................... 7
        4.5  Link Takedown(All DLCs)............................ 7
        4.6  Getting link Status................................ 7
        4.7  Error conditions................................... 7
      5.0 References ........................................... 8
      6.0 Author's Addresses.................................... 8

1.0  Introduction

   This document describes a method of implementing DPNSS/DASS 2 back-
   haul messaging over IP using a modified version of the ISDN
   User Adaptation Protocol (IUAP). The DUA builds on top of IUA
   defining the necessary extensions to IUA for a DPNSS/DASS2 
   implementation.

1.1  Scope

   There is a need for Switched Circuit Network (SCN) signaling
   protocol delivery from a DPNSS Signaling Gateway (SG) to a Media
   Gateway Controller (MGC).  The delivery mechanism should support the
   following protocols:

             - DPNSS(Digital Private Network Signaling System)
             - DASS 2 (Digital Access Signaling System No 2)

   Unless specifically mentioned the details in this document are
   applicable to both DPNSS and DASS2.

1.2  Terminology

   Data channel (D-channel) - A 64 kbit/s time slot which functions
   as a common signaling channel on a 2048 kbits/s interface or a
   1544 kbits/s interface which is provisioned to carry DPNSS
   signaling.

   DPNSS channel - Time slots 1 to 15 and 17 to 31 on a 2048
   kbits/s interface or Time slots 1 to 23 on a 1544 kbits/s
   interface are termed as DPNSS channels. These are the
   traffic channels which carry voice or data traffic.

Vydyam/Mukundan/Mangalpally/Morneault                                 2 
Internet Draft        draft-ietf-sigtran-dua-00.txt           July 2001

       - DPNSS supports 60 Channels (30 Real and 30 Virtual)
       - DASS2 supports 30 Channels (All Real)

   Data Link Connection(DLC) - A DLC is the level 2 process that
   controls the transfer of level 3 messages on behalf of one
   DPNSS channel. A DLC uniquely identifies one DPNSS channel.
       - DPNSS supports 60 DLCs (30 Real and 30 Virtual)
       - DASSII supports 30 DLCs (All Real)

   DPNSS Link -  A logical collection of the D-channel and the
   associated DPNSS channels in a 2048 kbits/s interface or a
   1544 kbits/s interface is called a "DPNSS Link".

1.3  DPNSS Overview

   DPNSS is an industry standard interface (reference BTNR 188)
   defined between a PBX and an Access Network (AN).
   DPNSS extends facilities normally only available between
   extensions on a single PBX to all extensions on PBXs that are
   connected together in a private network. DPNSS was originally
   derived from BT's Digital Access Signaling System I (DASS I)
   enhanced where necessary to meet the private network
   requirements. Some of these enhancements were incorporated in
   DASS 2. DPNSS uses a 2048 kbits/s or 1544 kbits/s Digital
   Transmission System Interface as shown in figure 1 below.

           ----------              ----------        o--o
           |        | 2048 kbits/s |        |-------  /\
           |        |--------------|        |         --
           |  PBX   | 1544 kbits/s |  AN    |
           |        |--------------|        |        o--o
           |        |              |        |-------  /\
           ----------              ----------         --
                           Figure 1

   Channel 16 on a 2048 kbits/s interface and channel 24 on a
   1544 kbits/s interface is reserved for data communication
   between LE and AN. The channels reserved for data are called
   "Data Channels" or "D-Channels."

   The D-Channels are the physical media to exchange data
   between the DPNSS protocol peer entities. A logical collection of
   the D-channel and the associated DPNSS channels is called a "DPNSS
   Link".

1.4 Proposed DPNSS Backhaul Architecture

Vydyam/Mukundan/Mangalpally/Morneault                                 3 
Internet Draft        draft-ietf-sigtran-dua-00.txt           July 2001

           ******   DPNSS       ******      IP      *******
           *PBX *---------------* SG *--------------* MGC *
           ******               ******              *******

           +-----+                                  +-----+
           |DPNSS|              (NIF)               |DPNSS|
           | L3  |                                  | L3  |
           +-----+           +----------+           +-----+
           |     |           |     | DUA|           | DUA |
           |DPNSS|           |DPNSS+----+           +-----+
           | L2  |           | L2  |SCTP|           |SCTP |
           |     |           |     +----+           +-----+
           |     |           |     | IP +           | IP  |
           +-----+           +-----+----+           +-----+

      NIF  - Nodal Interworking function
      SCTP - Stream Control Transmission Protocol
      DUA  - DPNSS User Adaptation Layer Protocol

2.0  Changes from IUA

   The following section outlines the differences between DUA and IUA

2.1  Message Header

   IUA Message header has the format as shown in Figure 2 below.

     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 (0x1)           |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Interface Identifier                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            DLCI               |              Spare            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 2 IUA Message Header

   In DUA header DLCI field has a different format in accordance with
   the BTNR 188.

          0                   1
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |   Indicator   |0|Channel No.|1|
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vydyam/Mukundan/Mangalpally/Morneault                                 4 
Internet Draft        draft-ietf-sigtran-dua-00.txt           July 2001

   The indicator field is used to determine whether the message is for
   a particular DLC or it is applicable for all the DLCs in the
   carrier. The possible values of the indicator is mentioned below.

          Value          Description
            0            Action is to be performed on all DLCs
                         Channel number parameter is ignored.
            1            Action is to be performed on a single
                         DLC specified by channel number.

   This indicator value is used only by the Establish and Release
   messages. Data messages should ignore this value. This indicator is
   provided so that a single command can be issued to establish or
   release all the DLCs in one DPNSS Link.

   For channel number the valid values are 0 to 63 for DPNSS and 0 to
   31 for DASS 2. This is because DASS 2 does not support virtual DLCs
   and hence has only 32 DLCs.

2.2 Unit Data Message

   DPNSS layer 2 does not have a unit data primitive and hence the
   Unit Data Messages (Request, Indication) are invalid for a DUA
   application.

2.3  DLC Status Message

   For DUA, a new message is necessary to carry the status of the DLCs.
   This message will be a Management message (i.e. its message class
   will be a value of 0 for Management).  A message type of 0x5 will be
   used for this message.

   The DLC Status messages are exchanged between IUA layer peers to
   request, confirm and indicate the status of the DLCs.  The DLC
   Status messages contain the common message header followed by IUA
   message header as described in section 2.1.

Vydyam/Mukundan/Mangalpally/Morneault                                 5 
Internet Draft        draft-ietf-sigtran-dua-00.txt           July 2001

    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 (0x11)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | D1| D2| D3| D4| D5| D6| D7| D8| D9|D10|D11|D12|D13|D14|D15|D16|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               /
   /                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        ....................               |Dxx|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The parameter carries the status of DLCs using two bits for each
   DLC.

   The possible values for the two bits are shown below:
          Value          Description
            00        Out Of Service
            01        Reset Attempted
            10        Reset Completed
            11        Information Transfer

   For DASS 2 the value 00 (Out Of Service) is invalid since the DASS 2
   DLC does not have this state.

   For DASS 2 there are no virtual DLCs and hence information about
   only 32 DLCs need to be carried. Therefore the status message will
   have a length of 12 for a DASS 2 DLC Status message.

2.4 Error Message

   The ERR message is sent when an invalid value or unrecognized
   message is found in an incoming message.

   The Error Code parameter indicates the reason for the Error Message.
   These are the supported values in IUA.

Vydyam/Mukundan/Mangalpally/Morneault                                 6 
Internet Draft        draft-ietf-sigtran-dua-00.txt           July 2001

         Invalid Version                               0x01
         Invalid Interface Identifier                  0x02
         Unsupported Message Class                     0x03
         Unsupported Message Type                      0x04
         Unsupported Traffic Handling Mode             0x05
         Unexpected Message                            0x06
         Protocol Error                                0x07
         Unsupported Interface Identifier Type         0x08
         Invalid Stream Identifier                     0x09
         Unassigned TEI                                0x0a
         Unrecognized SAPI                             0x0b
         Invalid TEI, SAPI combination                 0x0c

   In DUA the error codes 0x0a to 0x0c are invalid as they are specific
   to ISDN.

   The following additional error codes are supported in DUA.
           Channel Number out of range            0x0d
           Channel Not configured                 0x0e

3.0 IANA Considerations

   A request will be made to IANA to assign a DUA value for the Payload
   Protocol Identifier in SCTP Payload Data chunk. The following SCTP
   Payload Protocol Identifier will be registered:

   The SCTP Payload Protocol Identifier is included in each SCTP Data
   chunk, to indicate which protocol the SCTP is carrying. This Payload
   Protocol Identifier is not directly used by SCTP but may be used by
   certain network entities to identify the type of information being
   carried in a Data chunk.

   The User Adaptation peer may use the Payload Protocol Identifier as
   a way of determining whether the message is for IUA or DUA.

4.0 Message Sequence in DUA

   An example of the message flows for establishing a data link on a
   signaling channel, passing PDUs and releasing a data link on a
   DPNSS channel is shown below. An active association between MGC
   and SG is established prior to the following message flows.

4.1 Resetting of single DLC

      i)  Successful
       PBX                     SG                        MGC
           <----------- SABMR          <----------- Est Req(Ind=1)
       UA   ----------->       Est Cfm -----------> (DLC in RC State)
                                Ind=1)

Vydyam/Mukundan/Mangalpally/Morneault                                 1 
Internet Draft        draft-ietf-sigtran-dua-00.txt           July 2001

      ii) Unsuccessful(Link Failure)
         PBX                     SG                        MGC
           <----------- SABMR         <----------- Est Req(Ind=1)
           Retransmissions over
           NT1 and NT2 expired
                               Rel Ind -----------> (DLC in RA state)
                              (RELEASE_PHYS,Ind=1)

4.2 Resetting all DLCs in a link

        PBX                     SG                    MGC
             <----------- SABMR(1)    <----------- Est Req(Ind=0)
             <----------- SABMR(2)
             <----------- SABMR(3)
            .............
             <----------- SABMR(N)
             In each DLC either
             UA is received or
             NT1/NT2 is expired
                                Est Cfm -----------> (Status of DLCs
                                (Ind=0)               are not updated )
                                        <----------- Status Req
                              Status cfm ---------> (Mark DLC status
                                                      based on
                                                      status bits) 4.3
Information Transfer on a DLC

           PBX                     SG                        MGC
                <----------- UI(C)            <----------- Data Req
           UI(C)----------->         Data Ind ----------->

4.4 Link Takedown(Single DLC)

           PBX                     SG                        MGC
               (For DPNSS, mark DLC as OOS)   <----------- Rel Req
               (For DASSII, mark DLC as RA)              (RELEASE_MGMT,
                                                           Ind=1)
                                     Rel Cfm  ---------->
                                     (Ind=1)

Vydyam/Mukundan/Mangalpally/Morneault                                 7 
Internet Draft        draft-ietf-sigtran-dua-00.txt           July 2001

4.5 Link Takedown(All DLCs)

           PBX                     SG                        MGC
               (For DPNSS, mark all DLCs as OOS) <-------- Rel Req
               (For DASSII, mark DLC as RA)              (RELEASE_MGMT,
                                                           Ind=0)
                                       Rel Cfm  ---------->
                                       (Ind=0) 4.6 Getting link Status

           PBX                     SG                        MGC
                                          <-----------  Stat Req
                                 Stat Res -----------> (Mark DLC status
                                                        based on
                                                        status bits) 4.7
Error conditions

           PBX                     SG                        MGC
                              Invalid Message <-----------
      Est/Rel/Data/Stat Req
                                  Error Ind   ----------->
                                 (Error Code) 5.0 Glossary of terms

          Real channel   : The signalling channel with associated
                           traffic channel (TS).
          Virtual channel: The signalling channel with no
                           associated traffic channel.
          NT1            : Retransmission period of 500msec.
          NT2            : Recommended value is 64.

6.0  References

   [1] Morneault, et al., "ISDN Q.921-User Adaptation Layer", RFC 3057,
   February 2001.

   [2]  BTNR (British Telecom Network Requirements) 188 Issue 6 Digital
   Private Network Signaling System 1.

   [3]  BTNR (British Telecom Network Requirements) 190 Issue 2
   Digital Access Signaling System No 2

   [4]  ETS 300 167 (08/1993) : Transmission and Multiplexing;
   Functional characteristic of 2048 kbits/s interfaces
   (Standard is based on G.704, G.706).

7.0. Acknowledgments

   The authors would like to thank Sudarsan Naganathan, Subhas
   Mondal and Sivaram Subramanian of Nortel Networks for their useful
   suggestions/comments.

Vydyam/Mukundan/Mangalpally/Morneault                                 8 
Internet Draft        draft-ietf-sigtran-dua-00.txt           July 2001

8.0  Author's Addresses

   Authors : Anil Vydyam, Ranjith Mukundan, Narsimuloo Mangalpally and
   Ken Morneault

   All correspondence regarding this draft should be sent to
   the following addresses :

   Mick Dragon                      Phone: +44 (0)1628434388
   Nortel Networks plc              EMail: [email-masked]
   Concorde Road
   Maidenhead
   Berkshire SL6 4AG
   United Kingdom

   Ken Morneault                    Phone: +1-703-484-3323
   Cisco Systems Inc.               EMail: [email-masked]
   13615 Dulles Technology Drive
   Herndon, VA. 20171
   USA

Attachment Converted: "c:\program files\qualcomm\eudora
pro\attach\Wipro_Disclaimer.txt" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 19 Jul 2001 02:26:52 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA v07: Some Comments
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.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

Greg Sidebottom wrote:                        (Thu, 19 Jul 2001 02:25:24)

[snip]
>    4.4 MTP3 Restart
>    
>    In the last para:
>    
>    "When the M3UA layer at an ASP receives a DUNA message indicating SS7
>    
>    network isolation at an SG, it will stop any affected traffic via this
>    
>    route. When the M3UA subsequently receives any DUNA messages from an
>    SGP
>    
>    it will mark the affected SS7 destinations as unavailable via that SG.
>    "
>    
>    Suggestion ->
>    
>    Analogus to the MTP restart mechanism, some mechanism should be
>    defined to consider all routes via the SG to be available and
>    subsequently updated via DUNA/SCON/DRST messages.
>    
>    
>    [Greg] This is the way the text used to read but I think Brian had an
>    issue with it and I made a change.  I'll try and dig up the e-mail
>    tomorrow, unless Brian can remember it first.
>    
[snip]

I believe that is what the text is implying: that a DUNA indicating SS7
network isolation does not mean that the routes are not considered
"unavailable" (i.e., they are considered available, but no traffic is
offered) until they have been updated as unavailable with regular DUNA
messages.

I believe that this *is* analogous to MTP Restart procedures.  I don't have
a problem with the suggested text clarification, with the exception that
because TFCs are not exchanged during MTP Restart, strike SCON from the
list, just DUNA/DRST.

Previously, DUNA with a wildcard was considered literally as all routes
unavailable.  Now it indicates MTP Restart Begins.

One question though, Greg: because routes are manitained on an SGP basis now
instead of just an SG basis, do we have to do a mini-restart when a single
SGP get's isolated from the network?

--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: [email-masked]
To: "sigtran" <[email-masked]>
Subject: (SUA as well) was: M2UAv9: Issue #4 ASP Down Reason Parameter
Date: Thu, 19 Jul 2001 11:04:23 +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 Ken,

> Brian also submitted a comment regarding the Reason parameter
> in the ASP Down message.  Below is a brief discussion to try
> to determine reasons for the Reason parameter.
> 
> Please provide justifications for the Reason parameter or it will
> be removed.

[clip]

> > > Based on previous email discussions, I have no problem with
> > > removing the Reason parameter since there is no specified
> > > purpose for its existence.  I have not removed it from M2UA
> > > because I was waiting for further comments as to whether
> > > or not it should be removed from M2UA/M3UA/SUA.
> > > Unfortunately, there were no comments.
> > >
> > > Greg, John - what do you think?

I don't see a use for it in SUA, so I will remove it.  If anyone has a
problem with this, speak fast :)

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: [M3UA & SUA] Routing Context & Network Appearance
Date: Thu, 19 Jul 2001 11:50:27 +0300
Importance: high
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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi all,

It has been suggest that routing context & network appearance be collapsed
into a single parameter for both M3UA & SUA.  

My suggest is that M3UA and SUA should (MUST) be consistent on this issue.  

I can see that this proposal does make sense, however, I think we need to
get input from the workgroup ASAP!

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Fairlie-Cuninghame, Robert" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M2PA association endpoint addresses.
Date: Thu, 19 Jul 2001 02:26:08 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: exchange1.nuera.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [12.105.228.79]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Tom,

> 
> It may be the case that the hardware does not lend itself to
> multi-homing. So I think we want the ability to use multiple links for
> redundancy.

Right, we definitely want the facility available to be able to implement
Figure 7 & 9 if required or desired but I think we need to discuss in the
draft the pros and cons (or at least acknowledge) the issues of multi-homing
verse multiple layer 2 links. 

> There is nothing in the M2PA protocol to prevent the use of
> multi-homing. The M2PA link corresponds to the SCTP 
> association. If the
> association is multi-homed, M2PA works the same. (Almost. M2PA would
> have to specify the list of addresses instead of just one 
> address.) SCTP
> can use its failover procedure and M2PA does not have to know 
> about it.
> 

An analysis of fail-over times would also be interesting (and apply to M2UA
as well). Using multi-homing (one association  between IPSP's) you are
relying completely on SCTP to detect and recover from failure conditions and
are therefore dependent on SCTP having acceptable failover times. 

In comparison/contrast, when there are two separate layer two
links/associations, you are depending entirely on SCTP to indicate failure
so that Layer 3 can try another layer 2 link.

On a configuration/establishment angle - yes you are right - for
multi-homing to work _reliably_ (and fully reliably is the key word here)
then the association configuration MUST have all transport addresses
available. Additionally, the M2UA/M2UA/M3UA MUST provide some fault-tolerant
behavior because SCTP does not provide a reliable multihoming ASSOCIATE
primitive (which is a mistake/omission in my mind). The draft should be
changed to say that when multiple _remote_ endpoint addresses are provided
for an association, then the adaptation layer must round-robin through the
transport addresses when trying to establish an association. Additionally,
the initial INIT should only be transmitted once for each endpoint address
so that progress through the endpoint addresses occurs in a timely manner. 

It is _NOT_ reliable to only call ASSOCIATE using only one endpoint address
and rely on the remaining endpoint addresses to be returned in the INIT-ACK.
If multiple addresses are known then they must all be tried - otherwise you
have a single point of failure. I will repeat: because SCTP does not provide
an ASSOCIATE primitive accepting multiple transport addresses then the
responsibility falls on the SCTP-user to provide this functionality. I
believe this needs to be addressed in M2UA & M3UA as well (since it is not
addressed in the SCTP draft). 

I'm sure people will disagree with me and say that we are trying to hide the
multi-homing fault-tolerant aspects but I believe you are simply breaking
them by restricting yourself to ASSOCIATE'ing with only one address in a
multi-homing situation. [I discussed this also in my
draft-fairlie-mmusic-sdp-sctp-00.txt] <soapbox mode off> :)

> 
> In configuration 1, say there is a failure at the processor 
> with address
> IPB. This should cause a time-controlled changeover to the other link.
> The time-control allows messages that went to IPB to clear out before
> subsequent messages are sent to IPD. This prevents missequencing.
> 
If SCTP multi-homing is used then SCTP requires that in-order delivery is
maintained (as indicated by Ken).

> If you wanted to use IPSP X as a "protocol converter box", then you
> might want to have an SS7/IP link at IPSP X corresponding to each
> regular SS7 link. 
> 
> I doubt that this will be a popular configuration, but the 
> capability is
> there if anyone needs it. 
> 
Definitely. But I we the draft only provides a couple of examples, then it
should clear say that the examples provided are not trying to infer that
these are most preferable configurations in the real world (and only
provided to show how association endpoint addresses are related).

Robert.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 19 Jul 2001 05:08:14 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: M2PA association endpoint addresses.
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Robert,

Setting up multiple associations and retrying with different primary
addresses on a single multihomed connection is not much different a task,
even if one is parallel and the other serial.

I agree that it is a bit of a bother, but none of the UA's (and M2PA if
current proposals are followed) need to set up associations, except at boot
time.  So, association setup performance is not so critical as it would be
for another application which must set up and tear down associations
rapidly.

Once the association is set up, however, the failover performance of SCTP is
far superior to that of SS7 L2 overlayed over multiple associations.  This
is because SCTP coordinates an end-to-end sequence number and performs
resequencing of messages.  The SCTP implementation can switch destination
addresses whenever one looks a little bad.  SCTP also measures the
performance (RTT) of each destination and an implementation is permitted to
use the "best" desintation on the fly.

On the other hand L2 overlaid over multiple associations cannot come close
to the same anaysis of destination performance and still requires a
coordinated changeover procedure.  With every SS7 L2 changeover and
changeback come the possibiltiy of mis-sequenced messages which is precluded
by SCTP.

Your reliable ASSOCIATE objections aside, multi-homing SCTP should always be
preferred over the multiple association approach from the perspective of
failover and performance.

Jacob Heitz had some very reasonable objections concerning placing multiple
links in stream on the same association due to the lack of per-stream flow
controls, but I believe that is being addressed in current SCTP extension
drafts.

All that said, I think that the diagrams can still be drawn this way, if
only to reduce the ASCII-art effort.

--Brian

Fairlie-Cuninghame, Robert wrote:             (Thu, 19 Jul 2001 02:26:08)
> Tom,
> 
> > 
> > It may be the case that the hardware does not lend itself to
> > multi-homing. So I think we want the ability to use multiple links for
> > redundancy.
> 
> Right, we definitely want the facility available to be able to implement
> Figure 7 & 9 if required or desired but I think we need to discuss in the
> draft the pros and cons (or at least acknowledge) the issues of
multi-homing
> verse multiple layer 2 links. 
> 
> > There is nothing in the M2PA protocol to prevent the use of
> > multi-homing. The M2PA link corresponds to the SCTP 
> > association. If the
> > association is multi-homed, M2PA works the same. (Almost. M2PA would
> > have to specify the list of addresses instead of just one 
> > address.) SCTP
> > can use its failover procedure and M2PA does not have to know 
> > about it.
> > 
> 
> An analysis of fail-over times would also be interesting (and apply to
M2UA
> as well). Using multi-homing (one association  between IPSP's) you are
> relying completely on SCTP to detect and recover from failure conditions
and
> are therefore dependent on SCTP having acceptable failover times. 
> 
> In comparison/contrast, when there are two separate layer two
> links/associations, you are depending entirely on SCTP to indicate failure
> so that Layer 3 can try another layer 2 link.
> 
> On a configuration/establishment angle - yes you are right - for
> multi-homing to work _reliably_ (and fully reliably is the key word here)
> then the association configuration MUST have all transport addresses
> available. Additionally, the M2UA/M2UA/M3UA MUST provide some
fault-tolerant
> behavior because SCTP does not provide a reliable multihoming ASSOCIATE
> primitive (which is a mistake/omission in my mind). The draft should be
> changed to say that when multiple _remote_ endpoint addresses are provided
> for an association, then the adaptation layer must round-robin through the
> transport addresses when trying to establish an association. Additionally,
> the initial INIT should only be transmitted once for each endpoint address
> so that progress through the endpoint addresses occurs in a timely manner.

> 
> It is _NOT_ reliable to only call ASSOCIATE using only one endpoint
address
> and rely on the remaining endpoint addresses to be returned in the
INIT-ACK.
> If multiple addresses are known then they must all be tried - otherwise
you
> have a single point of failure. I will repeat: because SCTP does not
provide
> an ASSOCIATE primitive accepting multiple transport addresses then the
> responsibility falls on the SCTP-user to provide this functionality. I
> believe this needs to be addressed in M2UA & M3UA as well (since it is not
> addressed in the SCTP draft). 
> 
> I'm sure people will disagree with me and say that we are trying to hide
the
> multi-homing fault-tolerant aspects but I believe you are simply breaking
> them by restricting yourself to ASSOCIATE'ing with only one address in a
> multi-homing situation. [I discussed this also in my
> draft-fairlie-mmusic-sdp-sctp-00.txt] <soapbox mode off> :)
> 
> > 
> > In configuration 1, say there is a failure at the processor 
> > with address
> > IPB. This should cause a time-controlled changeover to the other link.
> > The time-control allows messages that went to IPB to clear out before
> > subsequent messages are sent to IPD. This prevents missequencing.
> > 
> If SCTP multi-homing is used then SCTP requires that in-order delivery is
> maintained (as indicated by Ken).
> 
> > If you wanted to use IPSP X as a "protocol converter box", then you
> > might want to have an SS7/IP link at IPSP X corresponding to each
> > regular SS7 link. 
> > 
> > I doubt that this will be a popular configuration, but the 
> > capability is
> > there if anyone needs it. 
> > 
> Definitely. But I we the draft only provides a couple of examples, then it
> should clear say that the examples provided are not trying to infer that
> these are most preferable configurations in the real world (and only
> provided to show how association endpoint addresses are related).
> 
> Robert.
> 
> 
> ---
> 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: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
Date: Thu, 19 Jul 2001 13:19: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 Greg & Brian,

> For an SGP that requires the ASP Id for other 
> cases, we could add the procedure that Brian proposed.

Maybe I'm having trouble reading through all of the replies, etc. - but what
is the procedure that Brian proposed?

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Fairlie-Cuninghame, Robert" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M2PA association endpoint addresses.
Date: Thu, 19 Jul 2001 03:41:33 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: exchange1.nuera.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [12.105.228.79]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Thanks for the reply Brian,

> I agree that it is a bit of a bother, but none of the UA's (and M2PA
> if current proposals are followed) need to set up associations,
> except at boot time.  So, association setup performance is not so
> critical as it would be for another application which must set up
> and tear down associations rapidly.

So what if it powers up (or heaven-forbid, resets) and the configured
interface is down? This requires advanced operator intervention - I don't
imagine it would be easy for an operator who was not highly familiar with
the multi-homed topology of the network (assuming the bad interface cannot
be replaced immediately). I do however agree with your general statement
that is not as critical as say SDP but in my mind the interface should still
support the specification of multiple transport addresses.
 
> Once the association is set up, however, the failover performance of
> SCTP is far superior to that of SS7 L2 overlayed over multiple
> associations.  This is because SCTP coordinates an end-to-end
> sequence number and performs resequencing of messages.  The SCTP
> implementation can switch destination addresses whenever one looks a
> little bad.  SCTP also measures the performance (RTT) of each
> destination and an implementation is permitted to use the "best"
> desintation on the fly.

Definitely agree here - we are basically hiding the changeover from Layer 3.
That was what prompted my comment on the importance that this failure
information be related to the operator (through SCTP layer management). 

> On the other hand L2 overlaid over multiple associations cannot come
> close to the same anaysis of destination performance and still
> requires a coordinated changeover procedure.  With every SS7 L2
> changeover and changeback come the possibiltiy of mis-sequenced
> messages which is precluded by SCTP.

Right, of course the changeover time using SCTP would still be interesting
investigation because the standby layer 2 link may not be IP based (eg
hybrid network).
 
> Your reliable ASSOCIATE objections aside, multi-homing SCTP should
> always be preferred over the multiple association approach from the
> perspective of failover and performance.

Right.
 
> Jacob Heitz had some very reasonable objections concerning placing
> multiple links in stream on the same association due to the lack of
> per-stream flow controls, but I believe that is being addressed in
> current SCTP extension drafts.

I'm partially of the mind that this unneccesarily complicates things since
it probably won't be a widely-deployed configuration anyway. What does it
buy us the multiple association cannot provide? [Bandwidth efficiency issues
aside](dare I open this religious argument again?). 

> All that said, I think that the diagrams can still be drawn this
> way, if only to reduce the ASCII-art effort.

I have no problems with the diagrams but I do think that their reason for
existence should be clarified as showing Link Alignment and not preferred
real-world configurations.

Robert.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 19 Jul 2001 05:51:19 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

I'm not really sure....  I think Greg's talking about this:

Brian F. G. Bidulock wrote:                 (Mon, 16 Jul 2001 16:28:51)
[snip]
> ++++++++
> If you don't want to make the parameter `Mandatory,' how about
> adding another Error Code:
> 
>     	"Refused - ASP Identifier Required         0xc"
> 
> To be sent in response to an ASPUP message which does not
> contain an ASP Id parameter when the SGP requires one.  Then,
> instead of simply adding 8 bytes to ever ASPUP message as
> proposed, the ASP can go around again a second time with an ASP
> Id. ;)
> ++++++++
[snip]

--Brian

John Loughney wrote:                         (Thu, 19 Jul 2001 13:19:59)
> Hi Greg & Brian,
> 
> > For an SGP that requires the ASP Id for other 
> > cases, we could add the procedure that Brian proposed.
> 
> Maybe I'm having trouble reading through all of the replies,
> etc. - but what is the procedure that Brian proposed?
> 
> John
> 
> 
> ---
> 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: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
Date: Thu, 19 Jul 2001 13:55:25 +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 Brian,

> I'm not really sure....  I think Greg's talking about
> this:
> 
> Brian F. G. Bidulock wrote:                 (Mon, 16 Jul 2001 
> 16:28:51)
> [snip]
> > ++++++++
> > If you don't want to make the parameter `Mandatory,' how about
> > adding another Error Code:
> > 
> >     	"Refused - ASP Identifier Required         0xc"
> > 
> > To be sent in response to an ASPUP message which does not
> > contain an ASP Id parameter when the SGP requires one.  Then,
> > instead of simply adding 8 bytes to ever ASPUP message as
> > proposed, the ASP can go around again a second time with an ASP
> > Id. ;)

Sounds like a winner to me.  Consider it done in SUA.

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: SUA Common Parameter Range was: M3UA v07: Some Comments
Date: Thu, 19 Jul 2001 14:00:41 +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]>
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">

<META content="MSHTML 5.50.4611.1300" name=GENERATOR> <STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><SPAN class=072055410-19072001><FONT face=Arial color=#0000ff
size=2>Greg,</FONT></SPAN></DIV>
<DIV><SPAN class=072055410-19072001></SPAN>&nbsp;</DIV> <DIV><FONT
face=Arial><FONT size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x00 to 0x3f&nbsp;
Common/IUA parameters<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x40 to 0x7f&nbsp;
M2UA-specific<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x80 to 0xbf&nbsp;
M3UA-specific<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0xc0 to 0xff&nbsp;&nbsp;
SUA-specific<SPAN class=072055410-19072001><FONT
color=#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></DIV> <DIV><FONT
face=Arial><FONT size=2><SPAN
class=072055410-19072001></SPAN></FONT></FONT>&nbsp;</DIV> <DIV><FONT
face=Arial><FONT size=2><SPAN class=072055410-19072001><FONT
color=#0000ff>If OK with you, I want SUA range to be starting from 0x0100 -
since that is </FONT></SPAN></FONT></FONT></DIV> <DIV><FONT face=Arial><FONT
color=#0000ff size=2><SPAN class=072055410-19072001>what I have already
done!</SPAN></FONT></FONT></DIV> <DIV><FONT face=Arial><FONT color=#0000ff
size=2><SPAN class=072055410-19072001></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial><FONT color=#0000ff size=2><SPAN
class=072055410-19072001>0x0100 to 0x0105f for SUA specific parameters would
be it.</SPAN></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff size=2><SPAN
class=072055410-19072001></SPAN></FONT></FONT>&nbsp;</DIV> <DIV><FONT
face=Arial><FONT color=#0000ff size=2><SPAN
class=072055410-19072001>thanks,</SPAN></FONT></FONT></DIV> <DIV><FONT
face=Arial><FONT color=#0000ff size=2><SPAN
class=072055410-19072001>John</SPAN></FONT></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>
Date: Thu, 19 Jul 2001 06:03:45 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2PA association endpoint addresses.
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Robert,

We are in utter agreement.  But I wouldn't let the RFC's definition of
ASSOCIATE stop you from implementing a multiple address, err.., CONNECT.
Gee, I'd even throw one INIT per destination address immediately and let the
first INIT ACK win.  I don't think that the RFC really precludes such an
implementation.

--Brian

Fairlie-Cuninghame, Robert wrote:             (Thu, 19 Jul 2001 03:41:33)
> Thanks for the reply Brian,
> 
> > I agree that it is a bit of a bother, but none of the UA's (and M2PA
> > if current proposals are followed) need to set up associations,
> > except at boot time.  So, association setup performance is not so
> > critical as it would be for another application which must set up
> > and tear down associations rapidly.
> 
> So what if it powers up (or heaven-forbid, resets) and the configured
> interface is down? This requires advanced operator intervention - I don't
> imagine it would be easy for an operator who was not highly familiar with
> the multi-homed topology of the network (assuming the bad interface cannot
> be replaced immediately). I do however agree with your general statement
> that is not as critical as say SDP but in my mind the interface should
still
> support the specification of multiple transport addresses.
>  
> > Once the association is set up, however, the failover performance of
> > SCTP is far superior to that of SS7 L2 overlayed over multiple
> > associations.  This is because SCTP coordinates an end-to-end
> > sequence number and performs resequencing of messages.  The SCTP
> > implementation can switch destination addresses whenever one looks a
> > little bad.  SCTP also measures the performance (RTT) of each
> > destination and an implementation is permitted to use the "best"
> > desintation on the fly.
> 
> Definitely agree here - we are basically hiding the changeover from Layer
3.
> That was what prompted my comment on the importance that this failure
> information be related to the operator (through SCTP layer management). 
> 
> > On the other hand L2 overlaid over multiple associations cannot come
> > close to the same anaysis of destination performance and still
> > requires a coordinated changeover procedure.  With every SS7 L2
> > changeover and changeback come the possibiltiy of mis-sequenced
> > messages which is precluded by SCTP.
> 
> Right, of course the changeover time using SCTP would still be interesting
> investigation because the standby layer 2 link may not be IP based (eg
> hybrid network).
>  
> > Your reliable ASSOCIATE objections aside, multi-homing SCTP should
> > always be preferred over the multiple association approach from the
> > perspective of failover and performance.
> 
> Right.
>  
> > Jacob Heitz had some very reasonable objections concerning placing
> > multiple links in stream on the same association due to the lack of
> > per-stream flow controls, but I believe that is being addressed in
> > current SCTP extension drafts.
> 
> I'm partially of the mind that this unneccesarily complicates things since
> it probably won't be a widely-deployed configuration anyway. What does it
> buy us the multiple association cannot provide? [Bandwidth efficiency
issues
> aside](dare I open this religious argument again?). 
> 
> > All that said, I think that the diagrams can still be drawn this
> > way, if only to reduce the ASCII-art effort.
> 
> I have no problems with the diagrams but I do think that their reason for
> existence should be clarified as showing Link Alignment and not preferred
> real-world configurations.
> 
> Robert.
> 
> 
> ---
> 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: Shanker Srivastava <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Routing Procedure for SUA
Date: Thu, 19 Jul 2001 16:35:43 +0530
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-SMTP-HELO: smtp.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]

<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.2919.6307" name=GENERATOR> <STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Courier size=2>Hi,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Courier size=2>What is the Routing procedure
for SUE from SAG to AS and AS to SAG?</FONT></DIV> <DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Courier size=2>Thanks</FONT></DIV> <DIV><FONT
color=#0000ff face=Courier size=2>-Shanker</FONT></DIV> <DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Courier 
size=2>***********************************************<BR>Shanker Aryan
Srivastava<BR>Software Engineer,<BR>Convergent Software Ltd.<BR>15, Fifth
Floor, Oxford House,Rust Baugh Road,<BR>Off Airport Road, Ban - 560017 -
INDIA<BR>Phone : 091 80 525 4725 - TX - 230<BR>I-mail :&nbsp; <A
href="mailto:[email-masked]">mailto:[email-masked]</A><B
R>Visit us at <A 
href="http://www.convergsoft.com">http://www.convergsoft.com</A><BR>********
***************************************<BR><FONT
color=#800000><STRONG>Failure is not the worst thing in the world.<BR>The
very worst thing is not to 
try.<BR></STRONG></FONT>***********************************************</FON
T></DIV> <DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Courier 
size=2><BR></FONT>&nbsp;</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>
From: Shanker Srivastava <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Routing Procedure for SUA
Date: Thu, 19 Jul 2001 16:40:47 +0530
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-SMTP-HELO: smtp.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]>
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.2919.6307" name=GENERATOR> <STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Courier size=2>Sorry for previous Question, it
is</FONT></DIV>
<DIV><FONT color=#0000ff face=Courier size=2><FONT color=#0000ff
face=Courier size=2>What is the Routing procedure for SUA from SG to AS and
AS to SG?</FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Courier size=2>Thanks in advance.</FONT></DIV>
<DIV><FONT color=#0000ff face=Courier size=2>Shanker</FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px;
PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color:
black"><B>From:</B> 
  <A href="mailto:[email-masked]" 
  title=[email-masked]>Shanker Srivastava</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A 
  href="mailto:[email-masked]" 
  title=[email-masked]>sigtran</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Thursday, July 19, 2001 4:35 
  PM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> Routing Procedure for
SUA</DIV>
  <DIV><BR></DIV>
  <DIV><FONT color=#0000ff face=Courier size=2>Hi,</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Courier size=2>What is the Routing procedure
for 
  SUE from SAG to AS and AS to SAG?</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Courier size=2>Thanks</FONT></DIV>
  <DIV><FONT color=#0000ff face=Courier size=2>-Shanker</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Courier 
  size=2>***********************************************<BR>Shanker Aryan 
  Srivastava<BR>Software Engineer,<BR>Convergent Software Ltd.<BR>15, Fifth 
  Floor, Oxford House,Rust Baugh Road,<BR>Off Airport Road, Ban - 560017 - 
  INDIA<BR>Phone : 091 80 525 4725 - TX - 230<BR>I-mail :&nbsp; <A 
 
href="mailto:[email-masked]">mailto:[email-masked]</A><B
R>Visit 
  us at <A 
 
href="http://www.convergsoft.com">http://www.convergsoft.com</A><BR>********
***************************************<BR><FONT 
  color=#800000><STRONG>Failure is not the worst thing in the world.<BR>The
very 
  worst thing is not to 
 
try.<BR></STRONG></FONT>***********************************************</FON
T></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Courier
size=2><BR></FONT>&nbsp;</DIV>---<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>
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: Routing Procedure for SUA
Date: Thu, 19 Jul 2001 14:16:07 +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]

<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">

<META content="MSHTML 5.50.4611.1300" name=GENERATOR> <STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><SPAN class=109581011-19072001><FONT face=Arial color=#0000ff size=2>Hi
Shanker,</FONT></SPAN></DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV> <BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
  <DIV><FONT face=Courier><FONT color=#0000ff><FONT size=2>What is the
Routing 
  procedure for SUE from SAG to AS and AS to SAG?<SPAN 
  class=109581011-19072001><FONT 
  face=Arial>&nbsp;</FONT></SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT face=Courier><FONT color=#0000ff><FONT size=2><SPAN 
  class=109581011-19072001></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Courier><SPAN class=109581011-19072001><FONT size=2><FONT 
  face=Arial>What is a 'SAG'?&nbsp; Do you mean SGP?&nbsp; And do you mean
SUE 
  to be SUA?</FONT></FONT></SPAN></FONT></DIV>
  <DIV><FONT face=Courier><SPAN 
  class=109581011-19072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Courier><SPAN class=109581011-19072001><FONT face=Arial 
  size=2>John</FONT>&nbsp;</SPAN></FONT></DIV></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>
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: Routing Procedure for SUA
Date: Thu, 19 Jul 2001 14:31:30 +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]

Shankar,

> Sorry for previous Question, it is
> What is the Routing procedure for SUA from SG to AS and AS to SG?

It should be a point-to-point connection, so that there is no routing
(except at the IP level, of course).  

I would assume, most SGs will setup SUA & SCTP associations to the ASPs
before traffic would flow.  At some point, some traffic would come to the
SG, the SG would realize that the traffic would be destined for a particular
AS, so that it would use (most likely a table) which would 'associate' an AS
to a specific SCTP association, pack the data in a SUA message, pass it down
to the SCTP layer, etc.

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Shanker Srivastava <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Routing Procedure for SUA
Date: Thu, 19 Jul 2001 17:03:38 +0530
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-SMTP-HELO: smtp.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]

<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.2919.6307" name=GENERATOR> <STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Courier size=2></FONT>&nbsp;</DIV> <DIV><FONT
color=#0000ff face=Courier size=2>Hi,</FONT></DIV> <DIV><FONT color=#0000ff
face=Courier size=2>Yes i mean to ask the routing procedure between SEP/STP
to AS</FONT></DIV> <DIV><FONT color=#0000ff face=Courier size=2>and AS to
SEP/STP. Since we do not have any dynamic registration for an
ASP.</FONT></DIV> <DIV><FONT color=#0000ff face=Courier size=2>How can we
setup the association for a SG/AS? </FONT></DIV>
<DIV><FONT color=#0000ff face=Courier size=2>what parameter to be consider
for routing?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Courier size=2>--Shanker</FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px;
PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color:
black"><B>From:</B> 
  <A href="mailto:[email-masked]" 
  title=[email-masked]>[email-masked]</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A 
  href="mailto:[email-masked]" 
  title=[email-masked]>sigtran</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Thursday, July 19, 2001 4:46 
  PM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> RE: Routing Procedure for 
  SUA</DIV>
  <DIV><BR></DIV>
  <DIV><SPAN class=109581011-19072001><FONT color=#0000ff face=Arial
size=2>Hi 
  Shanker,</FONT></SPAN></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2></FONT>&nbsp;</DIV>
  <BLOCKQUOTE 
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT:
5px">
    <DIV><FONT face=Courier><FONT color=#0000ff><FONT size=2>What is the
Routing 
    procedure for SUE from SAG to AS and AS to SAG?<SPAN 
    class=109581011-19072001><FONT 
    face=Arial>&nbsp;</FONT></SPAN></FONT></FONT></FONT></DIV>
    <DIV><FONT face=Courier><FONT color=#0000ff><FONT size=2><SPAN 
    class=109581011-19072001></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
    <DIV><FONT face=Courier><SPAN class=109581011-19072001><FONT
size=2><FONT 
    face=Arial>What is a 'SAG'?&nbsp; Do you mean SGP?&nbsp; And do you mean
SUE 
    to be SUA?</FONT></FONT></SPAN></FONT></DIV>
    <DIV><FONT face=Courier><SPAN 
    class=109581011-19072001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face=Courier><SPAN class=109581011-19072001><FONT face=Arial 
    size=2>John</FONT>&nbsp;</SPAN></FONT></DIV></BLOCKQUOTE>---<BR>You are 
  currently subscribed to sigtran as: <A 
  href="mailto:[email-masked]">[email-masked]</A><BR>To 
  unsubscribe send a blank email to <A 
 
href="mailto:[email-masked]">leave-sigtran-397
[email-masked]</A> </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>
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: NTFY Insufficient ASP resources active in AS
Date: Thu, 19 Jul 2001 14:33:51 +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: [131.228.20.22]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

Which UAs are you targeting this for?  I don't think that this is an
unreasonable issue - let's synch M2UA, M3UA & SUA on this - want to supply
the text?

John

> -----Original Message-----
> From: ext Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 19 July, 2001 05:13
> To: sigtran
> Subject: NTFY Insufficient ASP resources active in AS
> 
> 
> All,
> 
> I still cannot see the point in notifying the ASPs *after*
> there are not enough active ASPs to take the load.  This
> will just force the SG to buffer and possibly fail in all
> cases of inadvertent deactivation of an ASP.
> 
> Why can we not notify *before*.  That is, notify when the
> AS is running with no protection (i.e. the "n+0" case instead
> of the "(n-1)+0" case).  This would permit an inactive ASP
> which has inadvertently gone inactive to bring itself back
> on-line without failure.
> 
> I'm really struggling with this in implementation: because
> it is possible that the ASPs may lose communication with
> each other, they may no longer be aware of the number of
> ASPs which are running in an AS.  The SG(P) has this
> information.  Why can it not communicate the information
> to the ASPs for the AS for which they are configured (as part
> of the ASP Up Ack or a separate NTFY before the ASP Up Ack)
> or for which they are registered (as part of the REG RSP or
> in a separate NTFY before the REG RSP is sent).
> 
> Also, often in telecommunications systems, going to one's
> knees is far preferrable to croaking.  Why cannot the SG
> report insufficient ASPs without shutting down traffic?
> Setting "n=1" is not a solution, because it does not
> indicate to the ASPs when they are vulnerable.
> 
> It makes sense to me that the SG would communicate all the
> state information that it has at its disposal regarding the
> ASs and ASPs to the ASPs with which it communicates.
> 
> 
> --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]
> 

---
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: SUA: DRST
Date: Thu, 19 Jul 2001 15:01:39 +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]

Brian,

I have some mail from you (& Gery) about DRST in SUA.  Now, I have added
that message, but I want to make sure that I add supporting text to meet
your needs.

I suggest that some text go into 

4.1.3 SS7 Signaling Network Management Procedures

and comments how and where DRST would be used.

If you have text ready - I'd be happy to see it ;)

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]>
Cc: [email-masked]
Subject: SUA6: SG Relay Problems
Date: Thu, 19 Jul 2001 15:10: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 Brian,

> > > > 2) Support for N-PCSTATE.  
> > > > 
> > > > I'm not so clear as to what is missing.
> > > > 
> > > Nothing earth-shattering, just an indication of routset
> > > (rather than subsystem) availability and congestion, and
> > > indication of routeset restriction via an SG.
> > 
> > For all DUNA, DAVA, SCON, etc mesages, we mark SSN as optional.
> > Shall I add text to state that when SSN is not present, we 
> > are to interpret that it affects more than just the SSN?
> > 
> > Is this OK?
> 
> I interpreted the section to mean that if the SSN is not provided
> that it is implied by the Routing Context.  Switching that to
> "more than one SSN" is somewhat different behavior.  But, if you
> want to preclude implied SSN by routing context, I have no problem
> with that.

I don't think we closed this.  I can see the problem with my suggestion -
what would meet your needs?

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: draft-ietf-sigtran-sua-06.txt
Date: Thu, 19 Jul 2001 15:19:36 +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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi AWarren,

> Section 3.9.2.3   (Global Title)  of 
> draft-ietf-sigtran-sua-06.txt  no longer
> includes an Odd/Even indicator.  Yet the descriptions  for 
> the conversion of
> Translation type, Numbering Plan and Nature of Address seem 
> to refer Odd/Even indicator. Please see below.

The references to the Odd/Even indicator were left in by mistake.
They have now been removed.

Thanks for catching this.

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 19 Jul 2001 07:46:21 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUA6: 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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

The confusion appears to be one of trying to make the DUNA, DAVA, SCON do
double duty: one for N-STATE, the other for N-PCSTATE.  It is doing pretty
good at N-STATE, I don't know about N-PCSTATE.
Perhaps all that is needed is a description (somewhere) as to how to build
and recognize an N-PCSTATE from a DUNA, DAVA, SCON.  (And add DRST of
course...) And a description of how to distinguish the N-PCSTATE from the
N-STATE versions of these messages.

--Brian

John Loughney wrote:                    (Thu, 19 Jul 2001 15:10:38)
> Hi Brian,
> 
> > > > > 2) Support for N-PCSTATE.  
> > > > > 
> > > > > I'm not so clear as to what is missing.
> > > > > 
> > > > Nothing earth-shattering, just an indication of routset
> > > > (rather than subsystem) availability and congestion, and
> > > > indication of routeset restriction via an SG.
> > > 
> > > For all DUNA, DAVA, SCON, etc mesages, we mark SSN as optional.
> > > Shall I add text to state that when SSN is not present, we 
> > > are to interpret that it affects more than just the SSN?
> > > 
> > > Is this OK?
> > 
> > I interpreted the section to mean that if the SSN is not provided
> > that it is implied by the Routing Context.  Switching that to
> > "more than one SSN" is somewhat different behavior.  But, if you
> > want to preclude implied SSN by routing context, I have no problem
> > with that.
> 
> I don't think we closed this.  I can see the problem with my suggestion - 
> what would meet your needs?
> 
> 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: Thu, 19 Jul 2001 07:49:02 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: SUA: DRST
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

Well no, I didn't have text ready.  However, this section 4.1.3 would also
be a good place to describe the use of the N-PCSTATE versions of DUNA, DAVA
and SCON.

It might be possible to steal some of the descriptive text from M3UA.

I'll have to get back to you on that... ;)

--Brian

John Loughney wrote:               (Thu, 19 Jul 2001 15:01:39)
> Brian,
> 
> I have some mail from you (& Gery) about DRST in SUA.  Now,
> I have added that message, but I want to make sure that I 
> add supporting text to meet your needs.
> 
> I suggest that some text go into 
> 
> 4.1.3 SS7 Signaling Network Management Procedures
> 
> and comments how and where DRST would be used.
> 
> If you have text ready - I'd be happy to see it ;)
> 
> 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: SUA6: SG Relay Problems
Date: Thu, 19 Jul 2001 16:14: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: [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,

> The confusion appears to be one of trying to make the DUNA, DAVA,
> SCON do double duty: one for N-STATE, the other for N-PCSTATE.  It
> is doing pretty good at N-STATE, I don't know about N-PCSTATE.
> Perhaps all that is needed is a description (somewhere) as to how to
> build and recognize an N-PCSTATE from a DUNA, DAVA, SCON.  (And add
> DRST of course...) And a description of how to distinguish the
> N-PCSTATE from the N-STATE versions of these messages.

Right now, the N-TATE text seems OK.  I have added DRST.  We just need to
add to 4.1.3 on how to use SCON, DUNA, DAVA & DRST for N-PCSTATE.

Essentially, it should be handled by the SG/SGP and also by the ASP (in the
case of multiple SG/SGP). Correct?

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 19 Jul 2001 08:35:46 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUA6: 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: [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

John Loughney wrote:                         (Thu, 19 Jul 2001 16:14:45)
> Hi Brian,
> 
> > The confusion appears to be one of trying to make the DUNA, DAVA,
> > SCON do double duty: one for N-STATE, the other for N-PCSTATE.  It
> > is doing pretty good at N-STATE, I don't know about N-PCSTATE.
> > Perhaps all that is needed is a description (somewhere) as to how to
> > build and recognize an N-PCSTATE from a DUNA, DAVA, SCON.  (And add
> > DRST of course...) And a description of how to distinguish the
> > N-PCSTATE from the N-STATE versions of these messages.
> 
> Right now, the N-TATE text seems OK.  I have added DRST.  We just need
> to add to 4.1.3 on how to use SCON, DUNA, DAVA & DRST for N-PCSTATE.
> 
> Essentially, it should be handled by the SG/SGP and also by the
> ASP (in the case of multiple SG/SGP). Correct?
> 

Bingo!

-- 
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: SUA: Section 4.1.3 text
Date: Thu, 19 Jul 2001 16:53:16 +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: [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]

Brian,

Let me know how complete (or incomplete) this text is, with regards to
N-PCSTATE.

thanks,
John

4.1.3 SS7 Signaling Network Management Procedures

When an SCCP Subsystem Management (SCMG) message is received from the SS7
network, the SG needs to determine whether there are concerned Application
Servers interested in subsystem status changes. The SUA management function
is informed with the N-State indication primitive upon which it formats and
transfers the applicable SNM message to the list of concerned ASPs using
stream ID "0".

When MTP-3 Management indications are received (MTP-PAUSE, MTP-RESUME,
MTP-STATUS), SCCP Subsystem Management determines whether there are
concerned local SCCP-users. When these local SCCP-users are in fact
Application Servers, serviced by ASPs, SUA management is informed with the
PC-State indication primitive upon which it formats and transfers the
applicable SNM message (DUNA, DAVA, DRST or SCON) to the list of concerned
ASPs using stream ID "0".  

If an ASP receives a DUNA, DRST or SCON from a SGP, the SUA layer at the ASP
is expected to send traffic to the affected destination via an alternate SGP
of equal priority, but only if such an alternate route exists and is
available. The local ASP SHOULD maintain the status of the possible routes
to the peer endpoint in the SS7 network.  By maintaining the status of the
possible routes, the ASP can determine if the remote peer is unavailable.

When the DAUD message is received at the SG from an ASP, the SG checks the
status of the specified SS7 destination and returns DAVA, DUNA, DRST or SCON
depending on the result of the check. The SG initiates SST (Subsystem Status
Test) procedures by following the SCCP procedures described in Q.714, these
are not triggered by the receipt of a DAUD message.

SCCP Subsystem Management procedures may also be triggered in case of AS
state changes, see chapter 4.4.1.2.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Garnero, Pierre" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA (V7) DRST question
Date: Thu, 19 Jul 2001 15:55:34 +0200
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: zcamail04.zca.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: zcamail04.zca.compaq.com [161.114.32.104]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Thanks Greg and Brian for all you remarks ... but I am still puzzled ... :-)

So I would to submit some simple configurations and scenarios to help me
understand 
the supposed M3UA behavior.  

Scenario 1: 
-----------

|<------------ SS7 Network ------------->|           |<-- IP Network -->|

                                          - - - - - -          - - - - - 
                                         |    SG     |        |    AS   |
                                                                    
                                         |           |        |         |
  +------+      +------+ 1 single route    | +------+  |        | +-----+ |
| SCP  |------| STP  |-------------------  | SGP1 |   --------  | ASP | |
PC=10|      | PC=2 | 1 single channel  | +------+  |        | +-----+ |
+------+      +------+                                               
                                         |           |        |         |
                                                                    
                                         |   PC=1    |        |         |
                                          - - - - - -          - - - - - 

Could you confirm:
  1/ On receipt of a TFR concerning PC=10, SGP sends a DRST concerning
PC=10.
  2/ On receipt of a TFP concerning PC=10, SGP sends a DUNA concerning
PC=10.
  3/ If the single link between the SG and the adjacent (PC=2) breaks, SGP 
     sends a DUNA concerning PC=10.

Scenario 2:
-----------

|<------------ SS7 Network ------------->|           |<-- IP Network -->|

                                          - - - - - -          - - - - - 
                                         |    SG     |        |    AS   |
                                                                    
              +------+         route 1   |           |        |         |
            / | STP  |------------------- +------+  /   | PC=2 |
| +------+  |        | +-----+ | | SCP  |/     +------+
| SGP1 |   --------  | ASP | | PC=10|\     +------+         route 2   |
+------+  |        | +-----+ | +------+  \   | STP  |-------------------

            \ | PC=3 |                   |           |        |         |
              +------+                                              
                                         |   PC=1    |        |         |
                                          - - - - - -          - - - - - 

Could you confirm:
PC=10 is seen accessible (the 2 routes are available) by SG (PC=1).
  1/ SG receives a TFP concerning PC=10 on route 1. The SGP does not have to
     send a DUNA to the ASP: from a SS7 point of view, PC=10 is still
     accessible. Right?
  2/ SG receives a TFP concerning PC=10 on route 2. The SGP send a DUNA to
the
     ASP: from a SS7 point of view, PC=10 is no more available. Right?

PC=10 is seen accessible (the 2 routes are available) by SG (PC=1).
  1/ SG receives a TFR concerning PC=10 on route 1. Does the SGP need to
send
     a DRST message to the ASP?
  2/ SG receives a TFR concerning PC=10 on route 2. At this time, Route 1
and
     route 2 are restricted: Does the SGP need to send a DRST message to the

     ASP?
if yes, what is the semantic of DRST message then?

Scenario 3:
-----------

|<------------ SS7 Network ------------->|           |<-- IP Network -->|

                                          - - - - - -          - - - - - 
                                         |    SG     |        |    AS   |
                                                                    
              +------+         route 1   | +------+  |        |         |
            / | STP  |-------------------  | SGP1 |   \ +------+  /   | PC=2
|                   | +------+  | \-----\| +-----+ | | SCP  |/     +------+
> | ASP | | PC=10|\     +------+         route 2   | +------+  | /-----/|
+-----+ | +------+  \   | STP  |-------------------  | SGP2 |   /

            \ | PC=3 |                   | +------+  |        |         |
              +------+                                              
                                         |   PC=1    |        |         |
                                          - - - - - -          - - - - - 

In this case, what are the differences from the scenario 2 ?
I mean, SGP1 and SGP2 are working in the SAME SS7 point code. I cannot
believe
that SGP1 is in charge of SS7 route 1 and SGP2 is in charge of SS7 route 2
=> it is not 
the responsability of the SGP: it is the responsability of the *common* MTP3
layer.

But anyway, what is supposed to happen (what are the M2UA MGT messages
exchanged) 
when: 
PC=10 is seen accessible (the 2 routes are available) by SG (PC=1).
  1/ SG receives a TFP concerning PC=10 on route 1. 
  2/ and then SG receives a TFP concerning PC=10 on route 2. 

PC=10 is seen accessible (the 2 routes are available) by SG (PC=1).
  1/ SG receives a TFR concerning PC=10 on route 1. 
  2/ and then SG receives a TFR concerning PC=10 on route 2. 

Many thanks in advance.

/Pierre

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, July 19, 2001 1:18 AM
> To: sigtran
> Subject: Re: M3UA (V7) DRST question
> 
> 
> Greg,
> 
> More below...
> 
> Greg Sidebottom wrote:                                       
> (Wed, 18 Jul 2001 18:51:24)
> > Hi Brian,
> > 
> > Response below ...
> > 
> > - Original Message -----
> > From: "Brian F. G. Bidulock" <[email-masked]>
> > To: "sigtran" <[email-masked]>
> > Sent: Wednesday, July 18, 2001 5:49 PM
> > Subject: Re: M3UA (V7) DRST question
> > 
> > 
> > > Greg,
> > >
> > > I did find one problem with what you describe:  In several
> > > places the draft make mention of things which would preclude,
> > > or counter-recommend it:
> > >
> > >     Section 1.1
> > >
> > > "Where an SG contains more than one SGP, the SG is a
> > > logical entity and the contained SGPs must be
> > > coordinated into a signle management view to the SS7
> > > network and to the supported Application Servers."
> > >
> > 
> > [Greg] Do you mean it is contradictory because, for 
> example, if only one SGP
> > in an SG sends a DRST then this is not a single management 
> view from the SG
> > to the supported Application Servers?  Probably true, but I 
> think this is a
> > useful exception - the SGPs are coordinating the traffic 
> flows to make them
> > more efficient.   I think we can get around this by using 
> "should" instead
> > of "must" (i.e., "  .. the contained SGPs should be 
> coordinated ...  ") as
> > in the other sections.
> > 
> > >     Section 1.4.1
> > >
> > > "Where an SG contains more than one SGP, the MTP3
> > > routeset, SPMC and remote AS/ASP states of each SGP
> > > SHOULD be coordinated across all the SGPs.  Re-routing
> > > of traffic between SGPs SHOULD also be supported."
> > >
> > > --Brian
> > 
> > [Greg] I'm not sure yet why this text is contradictory?  
> The SGP states
> > maintained locally can be different but aggregated into a 
> single set of
> > overall SG states, assuming there is no breakdown of inter-SGP
> > communication.
> 
> Well, it is just a question of which thing you are sending
> to the ASP when you send things like DRST for multiple SGP.
> The ASP needs to know whether it is the SG status or the
> SGP status which is being indicated.
> 
>   If all these things (DUNA/DAVA/DRST) are only an
>   indication of the SGP status, then the ASP receives
>   one for each SGP and must derive the SG status from
>   the aggregate of the SGPs--which is contrary to the
>   above statements.
>   
>   If DUNA/DAVA/DRST are indications of SG status, then
>   it must already represent an aggregate view and the
>   ASP needs only receive these from one SGP.
> 
> Unfortunately you can't have it both ways unless we add
> something to these messages: i.e. an indicator as to
> whether the status applies to the SGP or the whole SG.
> 
> I don't have a problem with the ASP keeping track of
> these things on a per-SGP basis.  As a matter of fact I
> think it is quite apt for M3UA.  But text list this
> which recommends otherwise gives the impression that the
> SG is aggregating these things for the ASP when  in the
> per-SGP case, the ASP must do the aggregation.
> 
> 
> > 
> > Thanks,
> > 
> >     Greg
> > 
> 
> -- 
> 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]
Sender: [email-masked]
Date: Thu, 19 Jul 2001 09:32:01 -0500
From: Kurt Kite <[email-masked]>
Reply-To: [email-masked]
Organization: Ericsson North America Inc.
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
X-SMTP-HELO: imr1.ericy.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: imr1.ericy.com [208.237.135.240]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg Sidebottom wrote:

> Greetings,
>
> In the spirit of compromise, I'd propose leaving the ASP Identifier in ASP
> Up as optional, but add a note that it must be used where the IPSP/SGP
> cannot identify the ASP by pre-configured address/port number information
> (e.g., where an ASP is resident on a Host using dynamic address/port
number
> assignment).  For an SGP that requires the ASP Id for other cases, we
could
> add the procedure that Brian proposed.

Ok with me.

/Kurt

>
>
> Cheers,
>
>   Greg Sidebottom
>
> ----- Original Message -----
> From: "nirmalesh" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Tuesday, July 17, 2001 1:31 PM
> Subject: Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
>
> > Hi ,
> >  If you make ASP id as a mandotary field then another issue will
> >  pop up "how do you manage ASP Ids" across all ASPs , Same ASP Id could
be
> used by the
> >  different ASPs.
> > Solution could be :
> >  There has to be some central  authority who will be allocating the ASP
> ids across the
> > system .
> >   But do we really want to do it  ? Can any one suggest making it
> automated !!! or get
> > rid of the
> >  ASP Id ,as one can achieve with the Static IP and Port No.s
> >
> > cheers,
> > Nirmalesh
> >
> >
> > Kurt Kite wrote:
> >
> > > "Brian F. G. Bidulock" wrote:
> > >
> > > > Kurt,
> > > >
> > > > Ok.  I think we're on the same page.
> > > >
> > > > Do agree that the SGP cannot determine from local UA
> > > > configuation data?  That it must rely upon SCTP and IP
> > > > configuration data?
> > >
> > > The SGPs must know the IP addresses and port numbers used
> > > by the ASPs.
> > >
> > > >
> > > >
> > > > Your position, if I understand it correctly, is that it is
> > > > sufficient that the SGP rely upon IP addresses and such to
> > > > determine an ASP Id in static IP configurations.
> > > >
> > > > I agree, getting away without ASP Id is possible (but clumsy)
> > > > where:
> > >
> > > Thanks. I know that must have been hard for you to admit.
> > >
> > > >
> > > >
> > > >     1.    (a)   One Host has only one ASP per SGP.
> > > >
> > > >           or
> > > >
> > > >           (b)   IP Addresses on ASP Hosts are static or
> > > >                 selected from disjoint sets.
> > > >
> > > >           and
> > > >
> > > >     2.    (a)   Only one ASP per Host registers per SGP.
> > > >
> > > >           or
> > > >
> > > >           (b)   Port numbers for ASPs are static or are
> > > >                 selected from disjoint sets.
> > > >
> > > > Situation 1(a) is uninteresting because is goes against
> > > > carrier-grade recommendations.
> > > >
> > > > Situation 1(b) is possible, but precluded by most RFPs
> > > > I've seen which require dynamic addressing... (but wait!)
> > >
> > > But not by the ones which do not.
> > >
> > > >
> > > >
> > > > Situation 2(a) is uninteresting because is reduces the
> > > > reliability of the overall model by not allowing full mesh
> > > > associations between groups of ASPs and SGPs.
> > > >
> > > > Situation 2(b) requires that both the SGP and the ASP be
> > > > provisioned with static or complex port number assignments
> > > > for each ASP in a host and would be as difficult to
> > > > coordinate as assigning each ASP an ASP Id (or, more
> > > > difficult).
> > > >
> > > > My position is that the SGP should not provision and rely
> > > > on (nor be forced to provision and rely on) layer-below
> > > > information (in this case IP addresses and port numbers)
> > > > even when it might determine the ASP Id in a few cases.
> > > > What I feel that it can be made to rely on is the UA managed
> > > > identifier.
> > > >
> > > > Except in the uninteresting corner cases above, the SGP
> > > > will need to require an ASP identifier anyay.  Making the
> > > > parameter mandatory is the simple thing to do, covers all
> > > > the cases, and relieves both the SGP and ASP from the need
> > > > to rely on layer-below dependent configuration information.
> > > >
> > > > Keeping the separation between configuration of the UA and
> > > > SCTP/IP will also IMHO serve to increase interoperability
> > > > and portability of the UAs.
> > >
> > > I understand your position and I don't have a problem with it.
> > > I don't have a problem with an ASP Id.
> > >
> > > >
> > > >
> > > > Do you have any interesting cases where the ASP can get
> > > > away without sending an ASP Id and the ASP would buckle
> > > > under the weight of these 8 bytes?
> > >
> > > I never indicated that an additional 8 bytes of overhead is a
> performance
> > > concern. My only point, and it is a simple one, is that it is possible
> to determine
> > > the identity of an ASP without an ASP Id if static IP addressing and
> port number
> > > assignment are used. So, I don't think it necessary to make ASP Id
> mandatory
> > > in all cases. But, I agree that it is a fairly trivial thing to do and
> if it does
> > > become
> > > mandatory I am not going to lose any sleep over it.
> > >
> > > /Kurt
> > >
> > > >
> > > >
> > > > --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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Thu, 19 Jul 2001 09:36:39 -0500
From: Kurt Kite <[email-masked]>
Reply-To: [email-masked]
Organization: Ericsson North America Inc.
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
X-SMTP-HELO: imr2.ericy.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: imr2.ericy.com [12.34.240.68]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

See below please.

/Kurt

"Brian F. G. Bidulock" wrote:

> Greg,
>
> You don't understand: I don't want to ever have to use address/port
> number information to identify an ASP, even if the network *is*
> statically configured.  The rationale for this is complexity: it
> complicates the MIB and local management at the SG beyond reason
> just to include a "corner" case.
>
> Kurt said he wouldn't lose any sleep and I think his argument was
> more philosophical (yes, it really is possible in some cases to
> get away without ASP Id), but there is no need to complicate the
> matter for implementations by making them have to go dig out IP
> addresses and ports in special circumstancs.

Partly true. However, my implementation does use IP address and port number
to identify the ASP.

>
>
> Certainly there are a number of voices on this thread that thought
> that it was ok.

>
>
> I have other reasons for wanting to do this:  I would like to be
> able to run M3UA over SSCOP/AAL5, a PCI bus, a PIPE/FIFO, and I
> don't want to go digging out their TSAPs either.
>
> --Brian
>
> Greg Sidebottom wrote:                              (Thu, 19 Jul 2001
00:13:22)
> > Greetings,
> >
> > In the spirit of compromise, I'd propose leaving the ASP Identifier in
ASP
> > Up as optional, but add a note that it must be used where the IPSP/SGP
> > cannot identify the ASP by pre-configured address/port number
information
> > (e.g., where an ASP is resident on a Host using dynamic address/port
number
> > assignment).  For an SGP that requires the ASP Id for other cases, we
could
> > add the procedure that Brian proposed.
> >
> > Cheers,
> >
> >   Greg Sidebottom
> >
> > ----- Original Message -----
> > From: "nirmalesh" <[email-masked]>
> > To: "sigtran" <[email-masked]>
> > Sent: Tuesday, July 17, 2001 1:31 PM
> > Subject: Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
> >
> >
> > > Hi ,
> > >  If you make ASP id as a mandotary field then another issue will
> > >  pop up "how do you manage ASP Ids" across all ASPs , Same ASP Id
could be used by the
> > >  different ASPs.
> > > Solution could be :
> > >  There has to be some central  authority who will be allocating the
ASP ids across the
> > > system .
> > >   But do we really want to do it  ? Can any one suggest making it
automated !!! or get
> > > rid of the
> > >  ASP Id ,as one can achieve with the Static IP and Port No.s
> > >
> > > cheers,
> > > Nirmalesh
> > >
> > >
> > > Kurt Kite wrote:
> > >
> > > > "Brian F. G. Bidulock" wrote:
> > > >
> > > > > Kurt,
> > > > >
> > > > > Ok.  I think we're on the same page.
> > > > >
> > > > > Do agree that the SGP cannot determine from local UA
> > > > > configuation data?  That it must rely upon SCTP and IP
> > > > > configuration data?
> > > >
> > > > The SGPs must know the IP addresses and port numbers used
> > > > by the ASPs.
> > > >
> > > > >
> > > > >
> > > > > Your position, if I understand it correctly, is that it is
> > > > > sufficient that the SGP rely upon IP addresses and such to
> > > > > determine an ASP Id in static IP configurations.
> > > > >
> > > > > I agree, getting away without ASP Id is possible (but clumsy)
> > > > > where:
> > > >
> > > > Thanks. I know that must have been hard for you to admit.
> > > >
> > > > >
> > > > >
> > > > >     1.    (a)   One Host has only one ASP per SGP.
> > > > >
> > > > >           or
> > > > >
> > > > >           (b)   IP Addresses on ASP Hosts are static or
> > > > >                 selected from disjoint sets.
> > > > >
> > > > >           and
> > > > >
> > > > >     2.    (a)   Only one ASP per Host registers per SGP.
> > > > >
> > > > >           or
> > > > >
> > > > >           (b)   Port numbers for ASPs are static or are
> > > > >                 selected from disjoint sets.
> > > > >
> > > > > Situation 1(a) is uninteresting because is goes against
> > > > > carrier-grade recommendations.
> > > > >
> > > > > Situation 1(b) is possible, but precluded by most RFPs
> > > > > I've seen which require dynamic addressing... (but wait!)
> > > >
> > > > But not by the ones which do not.
> > > >
> > > > >
> > > > >
> > > > > Situation 2(a) is uninteresting because is reduces the
> > > > > reliability of the overall model by not allowing full mesh
> > > > > associations between groups of ASPs and SGPs.
> > > > >
> > > > > Situation 2(b) requires that both the SGP and the ASP be
> > > > > provisioned with static or complex port number assignments
> > > > > for each ASP in a host and would be as difficult to
> > > > > coordinate as assigning each ASP an ASP Id (or, more
> > > > > difficult).
> > > > >
> > > > > My position is that the SGP should not provision and rely
> > > > > on (nor be forced to provision and rely on) layer-below
> > > > > information (in this case IP addresses and port numbers)
> > > > > even when it might determine the ASP Id in a few cases.
> > > > > What I feel that it can be made to rely on is the UA managed
> > > > > identifier.
> > > > >
> > > > > Except in the uninteresting corner cases above, the SGP
> > > > > will need to require an ASP identifier anyay.  Making the
> > > > > parameter mandatory is the simple thing to do, covers all
> > > > > the cases, and relieves both the SGP and ASP from the need
> > > > > to rely on layer-below dependent configuration information.
> > > > >
> > > > > Keeping the separation between configuration of the UA and
> > > > > SCTP/IP will also IMHO serve to increase interoperability
> > > > > and portability of the UAs.
> > > >
> > > > I understand your position and I don't have a problem with it.
> > > > I don't have a problem with an ASP Id.
> > > >
> > > > >
> > > > >
> > > > > Do you have any interesting cases where the ASP can get
> > > > > away without sending an ASP Id and the ASP would buckle
> > > > > under the weight of these 8 bytes?
> > > >
> > > > I never indicated that an additional 8 bytes of overhead is a
> > performance
> > > > concern. My only point, and it is a simple one, is that it is
possible
> > to determine
> > > > the identity of an ASP without an ASP Id if static IP addressing and
> > port number
> > > > assignment are used. So, I don't think it necessary to make ASP Id
> > mandatory
> > > > in all cases. But, I agree that it is a fairly trivial thing to do
and
> > if it does
> > > > become
> > > > mandatory I am not going to lose any sleep over it.
> > > >
> > > > /Kurt
> > > >
> > > > >
> > > > >
> > > > > --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]
>
> --
> 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: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA (V7) DRST question
Date: Thu, 19 Jul 2001 08:06:18 -0700
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: ztxmail04.ztx.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ztxmail04.ztx.compaq.com [161.114.1.208]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greg, Brian, everybody:

	I have a problem with this discussion.  To it looks like the train
is jumping its track.

	A DRST (& DUNA & DAVA & etc.) must be interrupted as the
status/state that a SG, as a whole, sees for a destination(s), independent
of which one of the SG's SGP sent it.  It CAN NOT be used on an individual
SGP basis.

John Schantz
Compaq Telecom

 -----Original Message-----
From: 	Brian F. G. Bidulock [mailto:[email-masked]] Sent:
Wednesday, July 18, 2001 6:18 PM
To:	sigtran
Subject:	Re: M3UA (V7) DRST question

Greg,

More below...

Greg Sidebottom wrote:                                       (Wed, 18 Jul
2001 18:51:24)
> Hi Brian,
> 
> Response below ...
> 
> - Original Message -----
> From: "Brian F. G. Bidulock" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Wednesday, July 18, 2001 5:49 PM
> Subject: Re: M3UA (V7) DRST question
> 
> 
> > Greg,
> >
> > I did find one problem with what you describe:  In several
> > places the draft make mention of things which would preclude,
> > or counter-recommend it:
> >
> >     Section 1.1
> >
> > "Where an SG contains more than one SGP, the SG is a
> > logical entity and the contained SGPs must be
> > coordinated into a signle management view to the SS7
> > network and to the supported Application Servers."
> >
> 
> [Greg] Do you mean it is contradictory because, for example, if only one
SGP
> in an SG sends a DRST then this is not a single management view from the
SG
> to the supported Application Servers?  Probably true, but I think this is
a
> useful exception - the SGPs are coordinating the traffic flows to make
them
> more efficient.   I think we can get around this by using "should" instead
> of "must" (i.e., "  .. the contained SGPs should be coordinated ...  ") as
> in the other sections.
> 
> >     Section 1.4.1
> >
> > "Where an SG contains more than one SGP, the MTP3
> > routeset, SPMC and remote AS/ASP states of each SGP
> > SHOULD be coordinated across all the SGPs.  Re-routing
> > of traffic between SGPs SHOULD also be supported."
> >
> > --Brian
> 
> [Greg] I'm not sure yet why this text is contradictory?  The SGP states
> maintained locally can be different but aggregated into a single set of
> overall SG states, assuming there is no breakdown of inter-SGP
> communication.

Well, it is just a question of which thing you are sending to the ASP when
you send things like DRST for multiple SGP.
The ASP needs to know whether it is the SG status or the SGP status which is
being indicated.

  If all these things (DUNA/DAVA/DRST) are only an
  indication of the SGP status, then the ASP receives
  one for each SGP and must derive the SG status from
  the aggregate of the SGPs--which is contrary to the
  above statements.
  
  If DUNA/DAVA/DRST are indications of SG status, then
  it must already represent an aggregate view and the
  ASP needs only receive these from one SGP.

Unfortunately you can't have it both ways unless we add something to these
messages: i.e. an indicator as to whether the status applies to the SGP or
the whole SG.

I don't have a problem with the ASP keeping track of these things on a
per-SGP basis.  As a matter of fact I think it is quite apt for M3UA.  But
text list this which recommends otherwise gives the impression that the SG
is aggregating these things for the ASP when  in the per-SGP case, the ASP
must do the aggregation.

> Thanks,
>     Greg

-- 
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: Thu, 19 Jul 2001 11:09:13 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: SUA Common Parameter Range was: M3UA v07: Some Comments
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]

Greg,

I took the range 0x0300 to 0x03ff so that you could have 0x0200 to 0x02ff
for M3UA (since John started from 0x0100).

I'd prefer not change the range since M2UA is in last call.

Ken

At 02:00 PM 7/19/01 +0300, [email-masked] wrote:
>Greg,
>  
>       0x00 to 0x3f  Common/IUA parameters
>       0x40 to 0x7f  M2UA-specific
>       0x80 to 0xbf  M3UA-specific
>       0xc0 to 0xff   SUA-specific 
>  
>If OK with you, I want SUA range to be starting from 0x0100 - since that is

>what I have already done!
>  
>0x0100 to 0x0105f for SUA specific parameters would be 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]
Sender: [email-masked]
Date: Thu, 19 Jul 2001 10:32:31 -0500
From: Kurt Kite <[email-masked]>
Reply-To: [email-masked]
Organization: Ericsson North America Inc.
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
X-SMTP-HELO: imr1.ericy.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [208.237.135.240]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg, John, Brian,

I am going to reverse my position on this issue and recommend Brian's
proposal of making the ASP Id mandatory. Adding another optional parameter
to the protocol and additional error codes just increases the complexity of
the protocol and hinders inter-operability.

Implementations which use static IP addresses and port numbers can simply
ignore the ASP Id until they want to support dynamic IP addressing.

I apologize for wasting so much time and bandwidth on the issue.

/Kurt

"Brian F. G. Bidulock" wrote:

> John,
>
> Then may I suggest that we add the errors:
>
>         Error - ASP Identifier Required
>         Error - Invalid ASP Identifier
>
> as a valid reponses of an SG to a ASP Up message.
>
> --Brian
>
> John Loughney wrote:                   (Thu, 19 Jul 2001 09:45:00)
> > Hi Greg,
> >
> > > In the spirit of compromise, I'd propose leaving the ASP
> > > Identifier in ASP Up as optional, but add a note that it must
> > > be used where the IPSP/SGP cannot identify the ASP by pre-
> > > configured address/port number information
> > > (e.g., where an ASP is resident on a Host using dynamic
> > > address/port number assignment).  For an SGP that requires
> > > the ASP Id for other cases, we could add the procedure
> > > that Brian proposed.
> >
> > I second this.
> >
> > 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]

---
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: M3UA (V7) DRST question
Date: Thu, 19 Jul 2001 08:44:24 -0700
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: zcamail05.zca.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: zcamail05.zca.compaq.com [161.114.32.105]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Pierre,

	I can give you my view of the world.  Comments below.
John

 -----Original Message-----
From: 	Garnero, Pierre  
Sent:	Thursday, July 19, 2001 8:56 AM
To:	sigtran
Subject:	RE: M3UA (V7) DRST question

Thanks Greg and Brian for all you remarks ... but I am still puzzled ... :-)

So I would to submit some simple configurations and scenarios to help me
understand the supposed M3UA behavior.  

Scenario 1: 
-----------

|<------------ SS7 Network ------------->|           |<-- IP Network -->|

                                          - - - - - -          - - - - - 
                                         |    SG     |        |    AS   |
                                                                    
                                         |           |        |         |
  +------+      +------+ 1 single route    | +------+  |        | +-----+ |
| SCP  |------| STP  |-------------------  | SGP1 |   --------  | ASP | |
PC=10|      | PC=2 | 1 single channel  | +------+  |        | +-----+ |
+------+      +------+                                               
                                         |           |        |         |
                                                                    
                                         |   PC=1    |        |         |
                                          - - - - - -          - - - - - 

Could you confirm:
  1/ On receipt of a TFR concerning PC=10, SGP sends a DRST concerning
PC=10.
  2/ On receipt of a TFP concerning PC=10, SGP sends a DUNA concerning
PC=10.
  3/ If the single link between the SG and the adjacent (PC=2) breaks, SGP 
     sends a DUNA concerning PC=10.

[John] Since the SG has a single route to the SS7 network (STP) it would
"relay" the management messages to any AS it is connected to.

Scenario 2:
-----------

|<------------ SS7 Network ------------->|           |<-- IP Network -->|

                                          - - - - - -          - - - - - 
                                         |    SG     |        |    AS   |
                                                                    
              +------+         route 1   |           |        |         |
            / | STP  |------------------- +------+  /   | PC=2 |
| +------+  |        | +-----+ | | SCP  |/     +------+
| SGP1 |   --------  | ASP | | PC=10|\     +------+         route 2   |
+------+  |        | +-----+ | +------+  \   | STP  |-------------------

            \ | PC=3 |                   |           |        |         |
              +------+                                              
                                         |   PC=1    |        |         |
                                          - - - - - -          - - - - - 

Could you confirm:
PC=10 is seen accessible (the 2 routes are available) by SG (PC=1).
  1/ SG receives a TFP concerning PC=10 on route 1. The SGP does not 
          have to send a DUNA to the ASP: from a SS7 point of view, PC=10 is

          still accessible. Right?
[John]  Right, since route 2 is still available to PC=10, the SG still sees
PC=10 as available and does not send a DUNA to the AS.
  2/ SG receives a TFP concerning PC=10 on route 2. The SGP send a DUNA to
     the ASP: from a SS7 point of view, PC=10 is no more available. Right?
[John]  Right, since all of the SG's routes to PC=10 are prohibited, the SG
sees PC=10 as being unavailable and must send a DUNA to the AS.

PC=10 is seen accessible (the 2 routes are available) by SG (PC=1).
  1/ SG receives a TFR concerning PC=10 on route 1. Does the SGP need to
          send a DRST message to the ASP?
[John]  NO, the SG does not send a DRST to the AS.  The TFR only means that
if the SG has another route available to for PC=10, it should use it as the
primary route.  Since route 2 is available, the SG should send all traffic
for PC=10 on it.
  2/ SG receives a TFR concerning PC=10 on route 2. At this time, Route 1
     and route 2 are restricted: Does the SGP need to send a DRST message
	          to the ASP? if yes, what is the semantic of DRST message
then?
[John]  Since all the routes that the SG has for PC=10 are restricted, the
SG should send a DRST to the AS in case it has alternate routes that it can
use to reach PC=10.

Scenario 3:
-----------

|<------------ SS7 Network ------------->|           |<-- IP Network -->|

                                          - - - - - -          - - - - - 
                                         |    SG     |        |    AS   |
                                                                    
              +------+         route 1   | +------+  |        |         |
            / | STP  |-------------------  | SGP1 |   \ +------+  /   | PC=2
|                   | +------+  | \-----\| +-----+ | | SCP  |/     +------+
> | ASP | | PC=10|\     +------+         route 2   | +------+  | /-----/|
+-----+ | +------+  \   | STP  |-------------------  | SGP2 |   /

            \ | PC=3 |                   | +------+  |        |         |
              +------+                                              
                                         |   PC=1    |        |         |
                                          - - - - - -          - - - - - 

In this case, what are the differences from the scenario 2 ?
I mean, SGP1 and SGP2 are working in the SAME SS7 point code. I cannot
Believe that SGP1 is in charge of SS7 route 1 and SGP2 is in charge of SS7
route 2 => it is not the responsibility of the SGP: it is the responsibility
of the *common* MTP3 layer.
[John]  I agree with your view.  There is no difference.  PC/route states
are on a SG level not a SGP level.

But anyway, what is supposed to happen (what are the M2UA MGT messages
exchanged) when: 
PC=10 is seen accessible (the 2 routes are available) by SG (PC=1).
  1/ SG receives a TFP concerning PC=10 on route 1. 
  2/ and then SG receives a TFP concerning PC=10 on route 2. 
[John]  I would say that a TFP is sent from the SG to the AS since all of
the SG's routes to PC=10 are prohibited (PC=10 is unavailable).

PC=10 is seen accessible (the 2 routes are available) by SG (PC=1).
  1/ SG receives a TFR concerning PC=10 on route 1. 
  2/ and then SG receives a TFR concerning PC=10 on route 2. 
[John]  I would say that a TFR is sent from the SG to the AS since all of
the SG's routes to PC=10 are restricted.  If the AS only has the route to
this SG for PC=10, it would still send its traffic for PC=10 to this SG.
The same is true for the SG, it would still send traffic for PC=10 to this
pair of STPs.

Many thanks in advance.

/Pierre

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, July 19, 2001 1:18 AM
> To: sigtran
> Subject: Re: M3UA (V7) DRST question
> 
> 
> Greg,
> 
> More below...
> 
> Greg Sidebottom wrote:                                       
> (Wed, 18 Jul 2001 18:51:24)
> > Hi Brian,
> > 
> > Response below ...
> > 
> > - Original Message -----
> > From: "Brian F. G. Bidulock" <[email-masked]>
> > To: "sigtran" <[email-masked]>
> > Sent: Wednesday, July 18, 2001 5:49 PM
> > Subject: Re: M3UA (V7) DRST question
> > 
> > 
> > > Greg,
> > >
> > > I did find one problem with what you describe:  In several
> > > places the draft make mention of things which would preclude,
> > > or counter-recommend it:
> > >
> > >     Section 1.1
> > >
> > > "Where an SG contains more than one SGP, the SG is a
> > > logical entity and the contained SGPs must be
> > > coordinated into a signle management view to the SS7
> > > network and to the supported Application Servers."
> > >
> > 
> > [Greg] Do you mean it is contradictory because, for 
> example, if only one SGP
> > in an SG sends a DRST then this is not a single management 
> view from the SG
> > to the supported Application Servers?  Probably true, but I 
> think this is a
> > useful exception - the SGPs are coordinating the traffic 
> flows to make them
> > more efficient.   I think we can get around this by using 
> "should" instead
> > of "must" (i.e., "  .. the contained SGPs should be 
> coordinated ...  ") as
> > in the other sections.
> > 
> > >     Section 1.4.1
> > >
> > > "Where an SG contains more than one SGP, the MTP3
> > > routeset, SPMC and remote AS/ASP states of each SGP
> > > SHOULD be coordinated across all the SGPs.  Re-routing
> > > of traffic between SGPs SHOULD also be supported."
> > >
> > > --Brian
> > 
> > [Greg] I'm not sure yet why this text is contradictory?  
> The SGP states
> > maintained locally can be different but aggregated into a 
> single set of
> > overall SG states, assuming there is no breakdown of inter-SGP
> > communication.
> 
> Well, it is just a question of which thing you are sending
> to the ASP when you send things like DRST for multiple SGP.
> The ASP needs to know whether it is the SG status or the
> SGP status which is being indicated.
> 
>   If all these things (DUNA/DAVA/DRST) are only an
>   indication of the SGP status, then the ASP receives
>   one for each SGP and must derive the SG status from
>   the aggregate of the SGPs--which is contrary to the
>   above statements.
>   
>   If DUNA/DAVA/DRST are indications of SG status, then
>   it must already represent an aggregate view and the
>   ASP needs only receive these from one SGP.
> 
> Unfortunately you can't have it both ways unless we add
> something to these messages: i.e. an indicator as to
> whether the status applies to the SGP or the whole SG.
> 
> I don't have a problem with the ASP keeping track of
> these things on a per-SGP basis.  As a matter of fact I
> think it is quite apt for M3UA.  But text list this
> which recommends otherwise gives the impression that the
> SG is aggregating these things for the ASP when  in the
> per-SGP case, the ASP must do the aggregation.
> 
> 
> > 
> > Thanks,
> > 
> >     Greg
> > 
> 
> -- 
> 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]
From: Satish K <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: AS Identification Issue
Date: Sun, 20 May 2001 13:00:54 +0530
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-SMTP-HELO: smtp.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 All,
    We generally Identify the ASP messages at SGP using either Routing key
or Association ID. Is there a way how we can identify the AS to which this
ASP message is associated with.
     Is this AS Identification Implementation dependent ie logical
separation or there is a field in the message body by which we can identify
from which AS it is comming. Like if u want to know to which AS this ASPUP
message of a ASP is associated with.
Thanks
Satish

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA v07: Some Comments
Date: Thu, 19 Jul 2001 11:19:14 -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]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

A reply below...

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Thursday, July 19, 2001 3:26 AM
Subject: Re: M3UA v07: Some Comments

> Greg,
>
> Greg Sidebottom wrote:                        (Thu, 19 Jul 2001 02:25:24)
>
> [snip]
> >    4.4 MTP3 Restart
> >
> >    In the last para:
> >
> >    "When the M3UA layer at an ASP receives a DUNA message indicating SS7
> >
> >    network isolation at an SG, it will stop any affected traffic via
this
> >
> >    route. When the M3UA subsequently receives any DUNA messages from an
> >    SGP
> >
> >    it will mark the affected SS7 destinations as unavailable via that
SG.
> >    "
> >
> >    Suggestion ->
> >
> >    Analogus to the MTP restart mechanism, some mechanism should be
> >    defined to consider all routes via the SG to be available and
> >    subsequently updated via DUNA/SCON/DRST messages.
> >
> >
> >    [Greg] This is the way the text used to read but I think Brian had an
> >    issue with it and I made a change.  I'll try and dig up the e-mail
> >    tomorrow, unless Brian can remember it first.
> >
> [snip]
>
> I believe that is what the text is implying: that a DUNA indicating
> SS7 network isolation does not mean that the routes are not considered
> "unavailable" (i.e., they are considered available, but no traffic
> is offered) until they have been updated as unavailable with regular
> DUNA messages.
>
> I believe that this *is* analogous to MTP Restart procedures.  I don't
> have a problem with the suggested text clarification, with the exception
> that because TFCs are not exchanged during MTP Restart, strike SCON from
> the list, just DUNA/DRST.
>
> Previously, DUNA with a wildcard was considered literally as all routes
> unavailable.  Now it indicates MTP Restart Begins.
>

[Greg2] I need to think about this a little.  Aren't there valid cases where
all routes become unavailable but the SG will not do a restart.  Or are you
saying that independent of whether the SG does a restart, the M3UA will send
all DUNAs/DRSTs for all unavailable and restricted routes before sending
traffic.  Wouldn't this be a problem as there is no end-of-restart
indication?  I'm probably missing somethig here  2:^)

>
> One question though, Greg: because routes are manitained on an SGP basis
> now instead of just an SG basis, do we have to do a mini-restart when
> a single SGP get's isolated from the network?
>
>
> --Brian
>
>
[Greg2] I hope that a "network isolation" DUNA would not be sent by an SGP
that has routes to the SS7 network via another SGP in the SG - it is not
really isolated.  What I mean is if one of two SGPs in an SG loses network
connectivity, it still has routes to the SS7 network via the other SGP
(inter-SGP communication) and can continue to send SSNM messaging.

Cheers,

  Greg Sidebottom

---
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: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
Date: Thu, 19 Jul 2001 09:38:14 -0700
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: zcamail05.zca.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [161.114.32.105]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Everybody,

	I can not agree with this.  You guys are coming at this from the
wrong direction.  From an SS7 network's and SS7 vendor's point-of-view,
static IP addresses will be used for ASPs and SGPs.  DHCP will NOT even be
considered as a viable option.  Traditional SS7 networks like things that
are concrete and secure.  I think the probability of DHCP and 'home
addresses' being used for an IP-capable SS7 node is 0.000000000.  These are
network security issues.  DHCP and 'changing IP addresses on the fly (in
SCTP)' are tools being made available for hackers and they will not be
supported/implemented.  We will not consider them in our implementation.

	We are planning to function both as a client and server.  In either
case, all IP addresses must be predefined and configured.  If we are
functioning as a server to any node, each of the remote node's static IP
addresses, those to be used for establishing an association, must be
pre-configured before the association attempt can be made from the remote
node.  Any attempt to establish an association from an unknown IP address
will be discarded.

	To us, an association only defines an SS7 link (or links).
Associations/links to the same node are grouped into a traditional SS7
linkset.  These linksets are used to define traditional SS7 routes.
Destinations/PCs are then assigned to route.  

	We see no need for an ASP identifier at all!  Even Brian's proposal
is not acceptable because it is just an indirect way of having a mandatory
ASP identifier.

John

 -----Original Message-----
From: 	Kurt Kite [mailto:[email-masked]] Sent:	Thursday,
July 19, 2001 10:33 AM
To:	sigtran
Subject:	Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up

Greg, John, Brian,

I am going to reverse my position on this issue and recommend Brian's
proposal of making the ASP Id mandatory. Adding another optional parameter
to the protocol and additional error codes just increases the complexity of
the protocol and hinders inter-operability.

Implementations which use static IP addresses and port numbers can simply
ignore the ASP Id until they want to support dynamic IP addressing.

I apologize for wasting so much time and bandwidth on the issue.

/Kurt

"Brian F. G. Bidulock" wrote:

> John,
>
> Then may I suggest that we add the errors:
>
>         Error - ASP Identifier Required
>         Error - Invalid ASP Identifier
>
> as a valid reponses of an SG to a ASP Up message.
>
> --Brian
>
> John Loughney wrote:                   (Thu, 19 Jul 2001 09:45:00)
> > Hi Greg,
> >
> > > In the spirit of compromise, I'd propose leaving the ASP
> > > Identifier in ASP Up as optional, but add a note that it must
> > > be used where the IPSP/SGP cannot identify the ASP by pre-
> > > configured address/port number information
> > > (e.g., where an ASP is resident on a Host using dynamic
> > > address/port number assignment).  For an SGP that requires
> > > the ASP Id for other cases, we could add the procedure
> > > that Brian proposed.
> >
> > I second this.
> >
> > 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]

---
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: Thu, 19 Jul 2001 12:08:00 -0500
From: Kurt Kite <[email-masked]>
Reply-To: [email-masked]
Organization: Ericsson North America Inc.
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: M3UA version 7 comments
X-SMTP-HELO: imr2.ericy.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: imr2.ericy.com [12.34.240.68]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hi,

Here are some comments on version 7. I have tried not to raise any issues
already posted to the list.

Issues Raised at the Interoperability Test in Madrid
----------------------------------------------------

The following issues were raised an the interoperability test in Madrid and
have not been addressed in version 7.
I have not included the issue of sending SCON from an ASP to an SGP because
you have already indicated that this was intentionally not addressed.

1.  One of the issues raised at the interoperability test in
    Madrid was a lack of procedures for when an AS loses
    connectivity with an SGP, similar to the MTP restart
    procedures. It was also felt that the MTP restart
    procedures would need to be coordinated with the "AS
    restart" procedures.

2.  One of the issues raised at the interoperability test
    in Madrid was multiple occurances of the same parameter
    in a message. My recollection is that most participants
    were not in favor of supporting this featuer. The draft
    should clearly state whether this feature MUST, SHOULD,
    or MUST NOT, be supported.

3.  One of the issues raised at the interoperability test
    in Madrid was correlation of error messages. Version 7
    has partially addressed the concerns by mandating
    diagnostic information in some cases, e.g., invalid
    network appearance. However, it does not mandate the
    format of the diagnostic information. The draft should
    clearly indicate the contents of the diagnostics
    information. One proposal is that the error message always
    includes the diagnostics which contains the offending
    message (not just the first 40 bytes) and the offending
    parameter when necessary. Here is some sample text:

    The Error message contains the following parameters:

         Error Code                 Mandatory
         Offending Message          Mandatory
         Offending Parameter        Optional
         Diagnostic Information     Optional

    The format for the Error 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 = 0x0c           |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Error Code                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Tag = 0x??           |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       \                                                               \
       /                     Offending Message                         /
       \                                                               \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Tag = 0x??           |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Offending Parameter Value                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Tag = 0x07           |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       \                                                               \
       /                     Diagnostic Information                    /
       \                                                               \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Offending Message: variable length

       The Offending Message parameter contains the entire erroneous
       message.

    Offending Parameter Value: 32-bits (unsigned integer)

       The optional Offending Parameter Value parameter
       contains the value of the erroneous parameter. The
       Offending Parameter Value must be included when the
       erroneous parameter can contain multiple values,
       e.g., routing context.

    Diagnostic Information: variable length

       When included, the optional Diagnostic information can be any
       information germane to the error condition, to assist in
       identification of the error condition.

Comments on Specific Sections
-----------------------------

Page 72, Section 4.2.3.1 ASP Up Procedures:

    The draft states:

    If an ASP Up message is received and internally the
    remote ASP is in the ASP-ACTIVE or ASP-STANDBY state, an
    ASP-Up Ack message is returned, as well as an Error
    message ("Unexpected Message), and the remote ASP state
    is changed to ASP-INACTIVE in all relevant Application
    Servers.

    What is the purpose of sending an Error message in the
    above case? The SGP seems to be expecting the ASP Up
    message because it changed the state of the ASP. I don't
    believe that an Error message is appropriate in this
    situation.

Non-technical Comments
----------------------

General:

    In some cases the length of a tag is specified in the
    message formats and in other cases it is not, even
    though the tag length is fixed. The draft should
    be consistent.

Page 6, lines 308-324, Network Appearance definition:

    This partitioning is necessary where an SG is logically
    partitioned to appear as end node elements in multiple
    separate SS7 networks, in which case there is a separate
    network appearance for each point code in the SS7
    networks.

    Change "appear as end node" to "appear as an end node".

    It is also necessary when an SG is configured as an STP
    hosting multiple point codes, or when configured as
    multiple end nodes within the same network, in which
    case each point code is a separate network
    appearance.between the SG and the Application Server
    Processes over a common SCTP Association.

    Looks like the text after the first period can be
    deleted or otherwise corrected.

Page 73, line 4175:

    Section 4.2.3.4 ASP-Active Procedures should be numbered
    4.2.3.3.

Page 74, line 4196:

    For the Application Servers that the ASP can be
    successfully activated, he SGP or IPSP responds with
    one or more ASP Active Ack messages, including the
    associated Routing Context and Traffic Mode Type
    values.

    Change "he SGP" to "the SGP".

/Kurt

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Thu, 19 Jul 2001 10:12:38 -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: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
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]

A voice of reason booms out over the playground.
Well said, John.

"Schantz, John" wrote:
> 
> Everybody,
> 
>         I can not agree with this.  You guys are coming at this from the
> wrong direction.  From an SS7 network's and SS7 vendor's point-of-view,
> static IP addresses will be used for ASPs and SGPs.  DHCP will NOT even be
> considered as a viable option.  Traditional SS7 networks like things that
> are concrete and secure.  I think the probability of DHCP and 'home
> addresses' being used for an IP-capable SS7 node is 0.000000000.  These
are
> network security issues.  DHCP and 'changing IP addresses on the fly (in
> SCTP)' are tools being made available for hackers and they will not be
> supported/implemented.  We will not consider them in our implementation.
> 
>         We are planning to function both as a client and server.  In
either
> case, all IP addresses must be predefined and configured.  If we are
> functioning as a server to any node, each of the remote node's static IP
> addresses, those to be used for establishing an association, must be
> pre-configured before the association attempt can be made from the remote
> node.  Any attempt to establish an association from an unknown IP address
> will be discarded.
> 
>         To us, an association only defines an SS7 link (or links).
> Associations/links to the same node are grouped into a traditional SS7
> linkset.  These linksets are used to define traditional SS7 routes.
> Destinations/PCs are then assigned to route.
> 
>         We see no need for an ASP identifier at all!  Even Brian's
proposal
> is not acceptable because it is just an indirect way of having a mandatory
> ASP identifier.
> 
> John
> 
>  -----Original Message-----
> From:   Kurt Kite [mailto:[email-masked]]
> Sent:   Thursday, July 19, 2001 10:33 AM
> To:     sigtran
> Subject:        Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
> 
> Greg, John, Brian,
> 
> I am going to reverse my position on this issue and recommend
> Brian's proposal of making the ASP Id mandatory. Adding another
> optional parameter to the protocol and additional error codes just
> increases the complexity of the protocol and hinders inter-operability.
> 
> Implementations which use static IP addresses and port numbers can simply
> ignore the ASP Id until they want to support dynamic IP addressing.
> 
> I apologize for wasting so much time and bandwidth on the issue.
> 
> /Kurt
> 
> "Brian F. G. Bidulock" wrote:
> 
> > John,
> >
> > Then may I suggest that we add the errors:
> >
> >         Error - ASP Identifier Required
> >         Error - Invalid ASP Identifier
> >
> > as a valid reponses of an SG to a ASP Up message.
> >
> > --Brian
> >
> > John Loughney wrote:                   (Thu, 19 Jul 2001 09:45:00)
> > > Hi Greg,
> > >
> > > > In the spirit of compromise, I'd propose leaving the ASP
> > > > Identifier in ASP Up as optional, but add a note that it must
> > > > be used where the IPSP/SGP cannot identify the ASP by pre-
> > > > configured address/port number information
> > > > (e.g., where an ASP is resident on a Host using dynamic
> > > > address/port number assignment).  For an SGP that requires
> > > > the ASP Id for other cases, we could add the procedure
> > > > that Brian proposed.
> > >
> > > I second this.
> > >
> > > John
> > >
> >

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Kumar, Rajiv" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA (V7) DRST question
Date: Thu, 19 Jul 2001 10:35:48 -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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Greg/Pierre,

I agree with Pierre that in case of DRST message ASP should not send the
traffic to other SGPs in the same 
SG (represented with multiple SGPs)if it has available route through another
SG
(represented with multiple SGPs) route. 

But I think this condition will be taken care of automatically in the
following way:

1) SG gets a TFR from SS7 Network for a particular point code.

2) All the SGPs in this SG get STATUS as restricted for this point code
   through NIF.

3) All SGPs send DRST message to the Associated ASPs.

4) Now ASP  know that the SS7 destination is  restricted through all 
   the SGPs in a particular  SG as it has rceived DRST message form all the
   SGPs of that SG. So the traffic will not be routed further in the
   direction of SG itself, as it happens in case of other SSNM messages (e.g
DUNA) .

In case we don't have any route available through an alternate SG we will
have to
send traffic to SGP of the same SG which sent DRST message.

I think the reason of confusion is the following text in section 3.4.6

" The DRST message is optionally sent from the SGP to all concerned ASPs"

I think it should be changed as -

"The DRST message is optionally sent from all the SGPs in an SG to all
concerned ASPs"

This is similar to what is mentioned in case of DUNA messages in section
3.4.1.

Is that acceptable to all ?

cheers,
Rajiv

Hi Pierre,

	I can give you my view of the world.  Comments below.
John

 -----Original Message-----
From: 	Garnero, Pierre  
Sent:	Thursday, July 19, 2001 8:56 AM
To:	sigtran
Subject:	RE: M3UA (V7) DRST question

Thanks Greg and Brian for all you remarks ... but I am still puzzled ... :-)

So I would to submit some simple configurations and scenarios to help me
understand the supposed M3UA behavior.  

Scenario 1: 
-----------

|<------------ SS7 Network ------------->|           |<-- IP Network -->|

                                          - - - - - -          - - - - - 
                                         |    SG     |        |    AS   |
                                                                    
                                         |           |        |         |
  +------+      +------+ 1 single route    | +------+  |        | +-----+ |
| SCP  |------| STP  |-------------------  | SGP1 |   --------  | ASP | |
PC=10|      | PC=2 | 1 single channel  | +------+  |        | +-----+ |
+------+      +------+                                               
                                         |           |        |         |
                                                                    
                                         |   PC=1    |        |         |
                                          - - - - - -          - - - - - 

Could you confirm:
  1/ On receipt of a TFR concerning PC=10, SGP sends a DRST concerning
PC=10.
  2/ On receipt of a TFP concerning PC=10, SGP sends a DUNA concerning
PC=10.
  3/ If the single link between the SG and the adjacent (PC=2) breaks, SGP 
     sends a DUNA concerning PC=10.

[John] Since the SG has a single route to the SS7 network (STP) it would
"relay" the management messages to any AS it is connected to.

Scenario 2:
-----------

|<------------ SS7 Network ------------->|           |<-- IP Network -->|

                                          - - - - - -          - - - - - 
                                         |    SG     |        |    AS   |
                                                                    
              +------+         route 1   |           |        |         |
            / | STP  |------------------- +------+  /   | PC=2 |
| +------+  |        | +-----+ | | SCP  |/     +------+
| SGP1 |   --------  | ASP | | PC=10|\     +------+         route 2   |
+------+  |        | +-----+ | +------+  \   | STP  |-------------------

            \ | PC=3 |                   |           |        |         |
              +------+                                              
                                         |   PC=1    |        |         |
                                          - - - - - -          - - - - - 

Could you confirm:
PC=10 is seen accessible (the 2 routes are available) by SG (PC=1).
  1/ SG receives a TFP concerning PC=10 on route 1. The SGP does not 
          have to send a DUNA to the ASP: from a SS7 point of view, PC=10 is

          still accessible. Right?
[John]  Right, since route 2 is still available to PC=10, the SG still sees
PC=10 as available and does not send a DUNA to the AS.
  2/ SG receives a TFP concerning PC=10 on route 2. The SGP send a DUNA to
     the ASP: from a SS7 point of view, PC=10 is no more available. Right?
[John]  Right, since all of the SG's routes to PC=10 are prohibited, the SG
sees PC=10 as being unavailable and must send a DUNA to the AS.

PC=10 is seen accessible (the 2 routes are available) by SG (PC=1).
  1/ SG receives a TFR concerning PC=10 on route 1. Does the SGP need to
          send a DRST message to the ASP?
[John]  NO, the SG does not send a DRST to the AS.  The TFR only means that
if the SG has another route available to for PC=10, it should use it as the
primary route.  Since route 2 is available, the SG should send all traffic
for PC=10 on it.
  2/ SG receives a TFR concerning PC=10 on route 2. At this time, Route 1
     and route 2 are restricted: Does the SGP need to send a DRST message
	          to the ASP? if yes, what is the semantic of DRST message
then?
[John]  Since all the routes that the SG has for PC=10 are restricted, the
SG should send a DRST to the AS in case it has alternate routes that it can
use to reach PC=10.

Scenario 3:
-----------

|<------------ SS7 Network ------------->|           |<-- IP Network -->|

                                          - - - - - -          - - - - - 
                                         |    SG     |        |    AS   |
                                                                    
              +------+         route 1   | +------+  |        |         |
            / | STP  |-------------------  | SGP1 |   \ +------+  /   | PC=2
|                   | +------+  | \-----\| +-----+ | | SCP  |/     +------+
> | ASP | | PC=10|\     +------+         route 2   | +------+  | /-----/|
+-----+ | +------+  \   | STP  |-------------------  | SGP2 |   /

            \ | PC=3 |                   | +------+  |        |         |
              +------+                                              
                                         |   PC=1    |        |         |
                                          - - - - - -          - - - - - 

In this case, what are the differences from the scenario 2 ?
I mean, SGP1 and SGP2 are working in the SAME SS7 point code. I cannot
Believe that SGP1 is in charge of SS7 route 1 and SGP2 is in charge of SS7
route 2 => it is not the responsibility of the SGP: it is the responsibility
of the *common* MTP3 layer.
[John]  I agree with your view.  There is no difference.  PC/route states
are on a SG level not a SGP level.

But anyway, what is supposed to happen (what are the M2UA MGT messages
exchanged) when: 
PC=10 is seen accessible (the 2 routes are available) by SG (PC=1).
  1/ SG receives a TFP concerning PC=10 on route 1. 
  2/ and then SG receives a TFP concerning PC=10 on route 2. 
[John]  I would say that a TFP is sent from the SG to the AS since all of
the SG's routes to PC=10 are prohibited (PC=10 is unavailable).

PC=10 is seen accessible (the 2 routes are available) by SG (PC=1).
  1/ SG receives a TFR concerning PC=10 on route 1. 
  2/ and then SG receives a TFR concerning PC=10 on route 2. 
[John]  I would say that a TFR is sent from the SG to the AS since all of
the SG's routes to PC=10 are restricted.  If the AS only has the route to
this SG for PC=10, it would still send its traffic for PC=10 to this SG.
The same is true for the SG, it would still send traffic for PC=10 to this
pair of STPs.

Many thanks in advance.

/Pierre

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, July 19, 2001 1:18 AM
> To: sigtran
> Subject: Re: M3UA (V7) DRST question
> 
> 
> Greg,
> 
> More below...
> 
> Greg Sidebottom wrote:                                       
> (Wed, 18 Jul 2001 18:51:24)
> > Hi Brian,
> > 
> > Response below ...
> > 
> > - Original Message -----
> > From: "Brian F. G. Bidulock" <[email-masked]>
> > To: "sigtran" <[email-masked]>
> > Sent: Wednesday, July 18, 2001 5:49 PM
> > Subject: Re: M3UA (V7) DRST question
> > 
> > 
> > > Greg,
> > >
> > > I did find one problem with what you describe:  In several
> > > places the draft make mention of things which would preclude,
> > > or counter-recommend it:
> > >
> > >     Section 1.1
> > >
> > > "Where an SG contains more than one SGP, the SG is a
> > > logical entity and the contained SGPs must be
> > > coordinated into a signle management view to the SS7
> > > network and to the supported Application Servers."
> > >
> > 
> > [Greg] Do you mean it is contradictory because, for 
> example, if only one SGP
> > in an SG sends a DRST then this is not a single management 
> view from the SG
> > to the supported Application Servers?  Probably true, but I 
> think this is a
> > useful exception - the SGPs are coordinating the traffic 
> flows to make them
> > more efficient.   I think we can get around this by using 
> "should" instead
> > of "must" (i.e., "  .. the contained SGPs should be 
> coordinated ...  ") as
> > in the other sections.
> > 
> > >     Section 1.4.1
> > >
> > > "Where an SG contains more than one SGP, the MTP3
> > > routeset, SPMC and remote AS/ASP states of each SGP
> > > SHOULD be coordinated across all the SGPs.  Re-routing
> > > of traffic between SGPs SHOULD also be supported."
> > >
> > > --Brian
> > 
> > [Greg] I'm not sure yet why this text is contradictory?  
> The SGP states
> > maintained locally can be different but aggregated into a 
> single set of
> > overall SG states, assuming there is no breakdown of inter-SGP
> > communication.
> 
> Well, it is just a question of which thing you are sending
> to the ASP when you send things like DRST for multiple SGP.
> The ASP needs to know whether it is the SG status or the
> SGP status which is being indicated.
> 
>   If all these things (DUNA/DAVA/DRST) are only an
>   indication of the SGP status, then the ASP receives
>   one for each SGP and must derive the SG status from
>   the aggregate of the SGPs--which is contrary to the
>   above statements.
>   
>   If DUNA/DAVA/DRST are indications of SG status, then
>   it must already represent an aggregate view and the
>   ASP needs only receive these from one SGP.
> 
> Unfortunately you can't have it both ways unless we add
> something to these messages: i.e. an indicator as to
> whether the status applies to the SGP or the whole SG.
> 
> I don't have a problem with the ASP keeping track of
> these things on a per-SGP basis.  As a matter of fact I
> think it is quite apt for M3UA.  But text list this
> which recommends otherwise gives the impression that the
> SG is aggregating these things for the ASP when  in the
> per-SGP case, the ASP must do the aggregation.
> 
> 
> > 
> > Thanks,
> > 
> >     Greg
> > 
> 
> -- 
> 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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 19 Jul 2001 10:49:43 -0700
From: nirmalesh <[email-masked]>
Subject: Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
Sender: root@nodots-daemon
To: "sigtran" <[email-masked]>
Organization: TeleSys
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
X-SMTP-HELO: snfc21.pbi.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [206.13.28.240]
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>
Hi,
<br>&nbsp;Another Error is needed ..
<br>[email-masked] wrote:
<blockquote TYPE=CITE>Hi Brian,
<p>John,
<br>>
<br>> Then may I suggest that we add the errors: <br>>
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Error - ASP Identifier Required
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Error - Invalid ASP
Identifier</blockquote>
<b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Error - Duplicate
ASP Id</b>
<blockquote TYPE=CITE>&nbsp;
<br>>
<br>> as a valid reponses of an SG to a ASP Up message.
<p>I think I can live with those ...
<p>John
<p>---
<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] </html>

</x-html>
To: "sigtran" <[email-masked]>
Date: Thu, 19 Jul 2001 11:00:59 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Mailer: MailCity Service
Subject: RE: M3UA schedule
X-Sender-Ip: 63.96.78.21
Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80)
X-SMTP-HELO: shared1-mail.whowhere.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.185.123.82]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Folks,

A reminder, we need to get the next version of M3UA out by tomorrow or IETF
will be closed to updated drafts for 3 weeks pending the London IETF
meeting.  There are a number of issues still under discussion, so please
let's try to wrap things up in at least good enough shape to go to IESG
review.

Thanks,

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]
Date: Thu, 19 Jul 2001 13:28:50 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: M3UA v07: Some Comments
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

Please see additional comments below...

Greg Sidebottom wrote:                                       (Thu, 19 Jul
2001 11:19:14)
> Hi Brian,
> 
> A reply below...
> 
> ----- Original Message -----
> From: "Brian F. G. Bidulock" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Thursday, July 19, 2001 3:26 AM
> Subject: Re: M3UA v07: Some Comments
> 
> 
> > Greg,
> >
> > Greg Sidebottom wrote:                        (Thu, 19 Jul 2001
02:25:24)
> >
> > [snip]
> > >    4.4 MTP3 Restart
> > >
> > >    In the last para:
> > >
> > >    "When the M3UA layer at an ASP receives a DUNA message indicating
SS7
> > >
> > >    network isolation at an SG, it will stop any affected traffic via
> this
> > >
> > >    route. When the M3UA subsequently receives any DUNA messages from
an
> > >    SGP
> > >
> > >    it will mark the affected SS7 destinations as unavailable via that
> SG.
> > >    "
> > >
> > >    Suggestion ->
> > >
> > >    Analogus to the MTP restart mechanism, some mechanism should be
> > >    defined to consider all routes via the SG to be available and
> > >    subsequently updated via DUNA/SCON/DRST messages.
> > >
> > >
> > >    [Greg] This is the way the text used to read but I think Brian had
an
> > >    issue with it and I made a change.  I'll try and dig up the e-mail
> > >    tomorrow, unless Brian can remember it first.
> > >
> > [snip]
> >
> > I believe that is what the text is implying: that a DUNA indicating
> > SS7 network isolation does not mean that the routes are not considered
> > "unavailable" (i.e., they are considered available, but no traffic
> > is offered) until they have been updated as unavailable with regular
> > DUNA messages.
> >
> > I believe that this *is* analogous to MTP Restart procedures.  I don't
> > have a problem with the suggested text clarification, with the exception
> > that because TFCs are not exchanged during MTP Restart, strike SCON from
> > the list, just DUNA/DRST.
> >
> > Previously, DUNA with a wildcard was considered literally as all routes
> > unavailable.  Now it indicates MTP Restart Begins.
> >
> 
> [Greg2] I need to think about this a little.  Aren't there valid cases
where
> all routes become unavailable but the SG will not do a restart.  Or are
you
> saying that independent of whether the SG does a restart, the M3UA will
send
> all DUNAs/DRSTs for all unavailable and restricted routes before sending
> traffic.  Wouldn't this be a problem as there is no end-of-restart
> indication?  I'm probably missing somethig here  2:^)

Yes there are such cases.  A network operator could manually block all
routes to inhibit traffic without it being the restart case (i.e., the node
is not isolated from the SS7 network and thus has fully updated routing with
no need to restart).

The trick is to not try to make this message do double duty.  MTP Restart
Begins means that all routes are considered available, but stop traffic.

Perhaps the only way around this might be to add a separate MTP Restart
Begins and MTP Restart Ends messages to the protocol.

> 
> >
> > One question though, Greg: because routes are manitained on an SGP basis
> > now instead of just an SG basis, do we have to do a mini-restart when
> > a single SGP get's isolated from the network?
> >
> >
> > --Brian
> >
> >
> [Greg2] I hope that a "network isolation" DUNA would not be sent by an SGP
> that has routes to the SS7 network via another SGP in the SG - it is not
> really isolated.  What I mean is if one of two SGPs in an SG loses network
> connectivity, it still has routes to the SS7 network via the other SGP
> (inter-SGP communication) and can continue to send SSNM messaging.

I was considering an SGP which had also lost inter-SGP communication.

-- 
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, 19 Jul 2001 13:59:47 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA (V7) DRST question
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Pierre,

Please see below...

Garnero, Pierre wrote:                                   (Thu, 19 Jul 2001
15:55:34)
> Thanks Greg and Brian for all you remarks ... but I am still puzzled ...
:-)
> 
> So I would to submit some simple configurations and scenarios to help me
> understand 
> the supposed M3UA behavior.  
> 
> Scenario 1: 
> -----------
> 
> 
> |<------------ SS7 Network ------------->|           |<-- IP Network -->|
> 
>                                           - - - - - -          - - - - - 
>                                          |    SG     |        |    AS   |
>                                                                     
>                                          |           |        |         |
>                                                                     
> +------+      +------+ 1 single route    | +------+  |        | +-----+ |
> | SCP  |------| STP  |-------------------  | SGP1 |   --------  | ASP |  
> | PC=10|      | PC=2 | 1 single channel  | +------+  |        | +-----+ |
> +------+      +------+                                               
>                                          |           |        |         |
>                                                                     
>                                          |   PC=1    |        |         |
>                                           - - - - - -          - - - - - 
> 
> Could you confirm:
>   1/ On receipt of a TFR concerning PC=10, SGP sends a DRST concerning
> PC=10.

For this network configuration the SG should never receive TFR per SS7
specifications.

>   2/ On receipt of a TFP concerning PC=10, SGP sends a DUNA concerning
> PC=10.

This is correct, assuming that the SG has no other route to PC 10 (i.e.,
other than that drawn here.

>   3/ If the single link between the SG and the adjacent (PC=2) breaks, SGP

>      sends a DUNA concerning PC=10.

If this is the SG's only link to the SS7 network, then I believe it should
send DUNA with PC=* indicating that SS7 network isolation has occured.

> 
> 
> 
> Scenario 2:
> -----------
> 
> |<------------ SS7 Network ------------->|           |<-- IP Network -->|
> 
>                                           - - - - - -          - - - - - 
>                                          |    SG     |        |    AS   |
>                                                                     
>               +------+         route 1   |           |        |         |
>             / | STP  |-------------------                           
> +------+  /   | PC=2 |                   | +------+  |        | +-----+ |
> | SCP  |/     +------+                     | SGP1 |   --------  | ASP |  
> | PC=10|\     +------+         route 2   | +------+  |        | +-----+ |
> +------+  \   | STP  |-------------------                            
>             \ | PC=3 |                   |           |        |         |
>               +------+                                              
>                                          |   PC=1    |        |         |
>                                           - - - - - -          - - - - - 
> 
> Could you confirm:
> PC=10 is seen accessible (the 2 routes are available) by SG (PC=1).
>   1/ SG receives a TFP concerning PC=10 on route 1. The SGP does not have
to
>      send a DUNA to the ASP: from a SS7 point of view, PC=10 is still
>      accessible. Right?

Correct.  If the SG offers a route to PC=10 via STP PC=3 on route 2 then it
is still available, and this would be the normal case for what you have
drawn here.

>   2/ SG receives a TFP concerning PC=10 on route 2. The SGP send a DUNA to
> the ASP: from a SS7 point of view, PC=10 is no more available. Right?
> PC=10 is seen accessible (the 2 routes are available) by SG (PC=1).

Correct.

>   1/ SG receives a TFR concerning PC=10 on route 1. Does the SGP need to
> send a DRST message to the ASP?

No.  The SGP should attempt to redirect traffic itself onto route 2 and does
not need to inform the ASP of this.

>   2/ SG receives a TFR concerning PC=10 on route 2. At this time, Route 1
> and route 2 are restricted: Does the SGP need to send a DRST message to
the
> ASP?  if yes, what is the semantic of DRST message then?

Yes.  The DRST message would be for PC=10.  The ASP in this case would not
redirect or stop any traffic because it has no other equal priority routes
via an alternate SG.

> 
> 
> Scenario 3:
> -----------
> 
> |<------------ SS7 Network ------------->|           |<-- IP Network -->|
> 
>                                           - - - - - -          - - - - - 
>                                          |    SG     |        |    AS   |
>                                                                     
>               +------+         route 1   | +------+  |        |         |
>             / | STP  |-------------------  | SGP1 |   \             
> +------+  /   | PC=2 |                   | +------+  | \-----\| +-----+ |
> | SCP  |/     +------+                                        > | ASP |  
> | PC=10|\     +------+         route 2   | +------+  | /-----/| +-----+ |
> +------+  \   | STP  |-------------------  | SGP2 |   /              
>             \ | PC=3 |                   | +------+  |        |         |
>               +------+                                              
>                                          |   PC=1    |        |         |
>                                           - - - - - -          - - - - - 
> 
> In this case, what are the differences from the scenario 2 ?

> I mean, SGP1 and SGP2 are working in the SAME SS7 point code. I cannot
> believe that SGP1 is in charge of SS7 route 1 and SGP2 is in charge of SS7
> route 2 => it is not the responsability of the SGP: it is the
responsability
> of the *common* MTP3 layer.

In many real SS7 architectures, it is truly the case that the processor
running SGP1 may be responsible for route 1 and the processor running SGP2
may be responsible for route 2.  SGP1 and 2 may lose inter-SGP
communications as well.

This is precisely the crux of what we are discussing: whether the ASP sees
an aggregate view of the SG, or whether it sees the SG as a "partitioned"
MTP stack.

Should a DUNA or DRST (as in the previous cases) be sent from both SGP?
Should it only need to be sent by one?

> 
> But anyway, what is supposed to happen (what are the M2UA MGT messages
> exchanged) when: 

> PC=10 is seen accessible (the 2 routes are available) by SG (PC=1).
>   1/ SG receives a TFP concerning PC=10 on route 1. 
>   2/ and then SG receives a TFP concerning PC=10 on route 2. 

The same DUNA as in the previous case will be sent.  The question is which
SGPs send it.  As the draft stands, both SGP would have to each send a DUNA
message to the ASP.

> 
> PC=10 is seen accessible (the 2 routes are available) by SG (PC=1).
>   1/ SG receives a TFR concerning PC=10 on route 1. 
>   2/ and then SG receives a TFR concerning PC=10 on route 2. 

Again the same DUNA as in the previous case will be sent.  The question is
which SGPs send it.  As the draft stands, both SGP would have to each send a
DRST message to the ASP.

The question becomes, what if the ASP receives DRST or DUNA from only one of
the SGP?  Does it apply it to an aggregate view of the SG, or does it act on
it individually per-SGP.  In the current draft, the answer is confusing:
whereas there is text saying that the SGP must present a signle SG view
towards the ASP, there is other text saying that the ASP must keep track of
DUNA/DAVA/DRST on a per-SGP basis.

--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, 19 Jul 2001 14:01:27 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA (V7) DRST question
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

Then I take it that you have problem with the wording of the text in the
current draft which requires that an ASP keep track of the
availability/congestion/restricted status on a per-SGP basis?

--Brian

Schantz, John wrote:                                     (Thu, 19 Jul 2001
08:06:18)
> Greg, Brian, everybody:
> 
> 	I have a problem with this discussion.  To it looks like the train
> is jumping its track.
> 
> 	A DRST (& DUNA & DAVA & etc.) must be interrupted as the
> status/state that a SG, as a whole, sees for a destination(s), independent
> of which one of the SG's SGP sent it.  It CAN NOT be used on an individual
> SGP basis.
> 
> John Schantz
> Compaq Telecom
> 
>  -----Original Message-----
> From: 	Brian F. G. Bidulock [mailto:[email-masked]] 
> Sent:	Wednesday, July 18, 2001 6:18 PM
> To:	sigtran
> Subject:	Re: M3UA (V7) DRST question
> 
> Greg,
> 
> More below...
> 
> Greg Sidebottom wrote:                                       (Wed, 18 Jul
> 2001 18:51:24)
> > Hi Brian,
> > 
> > Response below ...
> > 
> > - Original Message -----
> > From: "Brian F. G. Bidulock" <[email-masked]>
> > To: "sigtran" <[email-masked]>
> > Sent: Wednesday, July 18, 2001 5:49 PM
> > Subject: Re: M3UA (V7) DRST question
> > 
> > 
> > > Greg,
> > >
> > > I did find one problem with what you describe:  In several
> > > places the draft make mention of things which would preclude,
> > > or counter-recommend it:
> > >
> > >     Section 1.1
> > >
> > > "Where an SG contains more than one SGP, the SG is a
> > > logical entity and the contained SGPs must be
> > > coordinated into a signle management view to the SS7
> > > network and to the supported Application Servers."
> > >
> > 
> > [Greg] Do you mean it is contradictory because, for example, if only one
> SGP
> > in an SG sends a DRST then this is not a single management view from the
> SG
> > to the supported Application Servers?  Probably true, but I think this
is
> a
> > useful exception - the SGPs are coordinating the traffic flows to make
> them
> > more efficient.   I think we can get around this by using "should"
instead
> > of "must" (i.e., "  .. the contained SGPs should be coordinated ...  ")
as
> > in the other sections.
> > 
> > >     Section 1.4.1
> > >
> > > "Where an SG contains more than one SGP, the MTP3
> > > routeset, SPMC and remote AS/ASP states of each SGP
> > > SHOULD be coordinated across all the SGPs.  Re-routing
> > > of traffic between SGPs SHOULD also be supported."
> > >
> > > --Brian
> > 
> > [Greg] I'm not sure yet why this text is contradictory?  The SGP states
> > maintained locally can be different but aggregated into a single set of
> > overall SG states, assuming there is no breakdown of inter-SGP
> > communication.
> 
> Well, it is just a question of which thing you are sending
> to the ASP when you send things like DRST for multiple SGP.
> The ASP needs to know whether it is the SG status or the
> SGP status which is being indicated.
> 
>   If all these things (DUNA/DAVA/DRST) are only an
>   indication of the SGP status, then the ASP receives
>   one for each SGP and must derive the SG status from
>   the aggregate of the SGPs--which is contrary to the
>   above statements.
>   
>   If DUNA/DAVA/DRST are indications of SG status, then
>   it must already represent an aggregate view and the
>   ASP needs only receive these from one SGP.
> 
> Unfortunately you can't have it both ways unless we add
> something to these messages: i.e. an indicator as to
> whether the status applies to the SGP or the whole SG.
> 
> I don't have a problem with the ASP keeping track of
> these things on a per-SGP basis.  As a matter of fact I
> think it is quite apt for M3UA.  But text list this
> which recommends otherwise gives the impression that the
> SG is aggregating these things for the ASP when  in the
> per-SGP case, the ASP must do the aggregation.
> 
> 
> > 
> > Thanks,
> > 
> >     Greg
> > 
> 
> -- 
> 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
[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, 19 Jul 2001 14:17:00 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA (V7) DRST question
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Rajiv,

I think that what you describe here is the normal manner of things given
that there are no internal restrictions or failures within the SG.

Should, however, the SGP within the SG be restricted in the inter-SGP
communications, or should a failure occur between SGP, it might not be the
case that all SGP send DRST.  It is surely not advisable to shut down the
whole SG just because it has become internally partitioned.

MTP as a protocol is such that it can be partitioned and still operate.
Just because one SGP has lost a route to the SS7 network does not mean that
the others have.  If the ASP responds on a per-SGP basis, the resulting
system can accomodate paritioning failures and continue to operate.
The SGP which has lost the route merely sends DUNA to concerned AS.

The same is true if internal restrictions or failures causes inefficiency
for one SGP handling specific routes.
If it sends DRST with respect to those routes, an ASP can increase the
efficiency by using alternate (unrestricted) SGP for those routes.

Many existing SS7 STP architectures take advantage of this characteristic of
MTP to partition the stack over multiple processors (i.e., SGP).

Permitting ASPs to perform these routing functions on a per-SGP basis
results in a more robust system in these cases.

On the other hand, for more simpler applications (such as where the SG is
not acting as an STP) and there are no SGP to SGP restrictions or
partitioning (e.g. the SG is implemented on a monolithic processor), it
merely adds to the complexity of the ASP implementation.

--Brian

Kumar, Rajiv wrote:                               (Thu, 19 Jul 2001
10:35:48)
> Hi Greg/Pierre,
> 
> I agree with Pierre that in case of DRST message ASP should not send the
> traffic to other SGPs in the same SG (represented with multiple SGPs)if it
> has available route through another SG (represented with multiple SGPs)
> route. 
> 
> But I think this condition will be taken care of automatically in the
> following way:
> 
> 1) SG gets a TFR from SS7 Network for a particular point code.
> 
> 2) All the SGPs in this SG get STATUS as restricted for this point code
>    through NIF.
> 
> 3) All SGPs send DRST message to the Associated ASPs.
> 
> 4) Now ASP  know that the SS7 destination is  restricted through all 
>    the SGPs in a particular  SG as it has rceived DRST message form all
the
>    SGPs of that SG. So the traffic will not be routed further in the
>    direction of SG itself, as it happens in case of other SSNM messages
(e.g
>    DUNA) .
> 
> In case we don't have any route available through an alternate SG we will
> have to send traffic to SGP of the same SG which sent DRST message.
> 
> I think the reason of confusion is the following text in section 3.4.6
> 
> " The DRST message is optionally sent from the SGP to all concerned ASPs"
> 
> I think it should be changed as -
> 
> "The DRST message is optionally sent from all the SGPs in an SG to all
> concerned ASPs"
> 
> This is similar to what is mentioned in case of DUNA messages in section
> 3.4.1.
> 
> Is that acceptable to all ?
> 
> cheers,
> Rajiv
> 

-- 
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, 19 Jul 2001 14:25:22 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

I think that your restricted view of implementating systems with static IP
addresses and port numbers will equally restrict the number of applications
(and markets) that your implementation can address.

That aside, I don't see how ASP Id will stop or hamper you from implementing
a static configuration.  Yet, removing it would preclude anything but a
static configuration.

The error procedure is merely intended to be used by those SGP which are
configured to require ASP Id.  Since your implementation will never connect
to one, I don't see your problem.  Could you explain what you find so
unacceptable about the procedure?

--Brian

Schantz, John wrote:                           (Thu, 19 Jul 2001 09:38:14)
> Everybody,
> 
> 	I can not agree with this.  You guys are coming at this from the
> wrong direction.  From an SS7 network's and SS7 vendor's point-of-view,
> static IP addresses will be used for ASPs and SGPs.  DHCP will NOT even be
> considered as a viable option.  Traditional SS7 networks like things that
> are concrete and secure.  I think the probability of DHCP and 'home
> addresses' being used for an IP-capable SS7 node is 0.000000000.  These
are
> network security issues.  DHCP and 'changing IP addresses on the fly (in
> SCTP)' are tools being made available for hackers and they will not be
> supported/implemented.  We will not consider them in our implementation.
> 
> 	We are planning to function both as a client and server.  In either
> case, all IP addresses must be predefined and configured.  If we are
> functioning as a server to any node, each of the remote node's static IP
> addresses, those to be used for establishing an association, must be
> pre-configured before the association attempt can be made from the remote
> node.  Any attempt to establish an association from an unknown IP address
> will be discarded.
> 
> 	To us, an association only defines an SS7 link (or links).
> Associations/links to the same node are grouped into a traditional SS7
> linkset.  These linksets are used to define traditional SS7 routes.
> Destinations/PCs are then assigned to route.  
> 
> 	We see no need for an ASP identifier at all!  Even Brian's proposal
> is not acceptable because it is just an indirect way of having a mandatory
> ASP identifier.
> 
> 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: Thu, 19 Jul 2001 14:26:27 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

nirmalesh,

I though that Invalid could do double duty for Duplicate. ;)

nirmalesh wrote:                                        (Thu, 19 Jul 2001
10:49:43)
> 
>    Hi,
>     Another Error is needed ..
>    [email-masked] wrote:
>    
>      Hi Brian,
>      
>      John,
>      >
>      > Then may I suggest that we add the errors:
>      >
>      >       Error - ASP Identifier Required
>      >       Error - Invalid ASP Identifier
>      
>              Error - Duplicate ASP Id
>    
>      
>      >
>      > as a valid reponses of an SG to a ASP Up message.
>      
>      I think I can live with those ...
>      
>      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]

-- 
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, 19 Jul 2001 15:41:20 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: m2ua-09: comment #5
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]

As has been noted, the current M2UA draft does not define a SG Process.  

I would propose using the SG Process definition from M3UA but it would be
necessary to limit the SG to a single SGP given the current draft.  Then,
figure 2 could be updated to show associations between ASP/SGP pairs.

Regards,

Ken

At 11:44 PM 7/18/01 -0500, you wrote:
>Harsh,
>
>Let me build on that, if I may...
>
>Figure 2 does not show SGP.  Unlike M3UA, it show associations
>being formed between hosts--kinda--, not between ASP/SGP pairs.
>The figure, also does not show multiple ASPs per host and does
>not show multiple SGP per SG.
>
>Also the lines drawn for the assocations touch the Host boxes
>and not the ASP boxes.  This would tend to imply that the Host
>is an SCTP enpoint and not the ASP (as is the case in other
>UAs).
>
>The diagram does not make it clear whether multiple associations
>can be formed between as single ASP and a single SGP (which is
>fairly much implied as excluded in M3UA).
>
>I agree, the concept needs to be explained in a number of
>places.
>
>--Brian
>
>[email-masked] wrote:                (Thu, 19 Jul 2001 09:26:22)
> > 
> > 
> > Hi,
> > 
> > 1. Sec 4.4.1 para 2 states
> > " A unique method of Interface Identifier valid
> > assignment at the SG/SGP is implementation dependent but must be
> > guaranteed to be unique across all SGPs in an SG."
> > 
> > There is no prior definition of SGP in the draft. Is the concept of SGP
here
> > assumed to be the same as in m3ua?
> > In any case, the concept should be explained.
> > 
> > regards,
> > Harsh Bhondwe
> > Hughes Software Systems
>
>-- 
>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: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA (V7) DRST question
Date: Thu, 19 Jul 2001 15:48:38 -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]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Pierre, John,

Additional comments below ...

----- Original Message -----
From: "Schantz, John" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Thursday, July 19, 2001 11:44 AM
Subject: RE: M3UA (V7) DRST question

> Hi Pierre,
>
> I can give you my view of the world.  Comments below.
> John
>
>  -----Original Message-----
> From: Garnero, Pierre
> Sent: Thursday, July 19, 2001 8:56 AM
> To: sigtran
> Subject: RE: M3UA (V7) DRST question
>
> Thanks Greg and Brian for all you remarks ... but I am still puzzled ...
:-)
>
> So I would to submit some simple configurations and scenarios to help me
> understand the supposed M3UA behavior.
>
> Scenario 1:
> -----------
>
>
> |<------------ SS7 Network ------------->|           |<-- IP Network -->|
>
>                                           - - - - - -          - - - - -
>                                          |    SG     |        |    AS   |
>
>                                          |           |        |         |
>
> +------+      +------+ 1 single route    | +------+  |        | +-----+ |
> | SCP  |------| STP  |-------------------  | SGP1 |   --------  | ASP |
> | PC=10|      | PC=2 | 1 single channel  | +------+  |        | +-----+ |
> +------+      +------+
>                                          |           |        |         |
>
>                                          |   PC=1    |        |         |
>                                           - - - - - -          - - - - -
>
> Could you confirm:
>   1/ On receipt of a TFR concerning PC=10, SGP sends a DRST concerning
> PC=10.
>   2/ On receipt of a TFP concerning PC=10, SGP sends a DUNA concerning
> PC=10.
>   3/ If the single link between the SG and the adjacent (PC=2) breaks, SGP
>      sends a DUNA concerning PC=10.
>
> [John] Since the SG has a single route to the SS7 network (STP) it would
> "relay" the management messages to any AS it is connected to.

[Greg] I agree with John (of course).   But it is not really a useful
architecture for an Operator.

>
> Scenario 2:
> -----------
>
> |<------------ SS7 Network ------------->|           |<-- IP Network -->|
>
>                                           - - - - - -          - - - - -
>                                          |    SG     |        |    AS   |
>
>               +------+         route 1   |           |        |         |
>             / | STP  |-------------------
> +------+  /   | PC=2 |                   | +------+  |        | +-----+ |
> | SCP  |/     +------+                     | SGP1 |   --------  | ASP |
> | PC=10|\     +------+         route 2   | +------+  |        | +-----+ |
> +------+  \   | STP  |-------------------
>             \ | PC=3 |                   |           |        |         |
>               +------+
>                                          |   PC=1    |        |         |
>                                           - - - - - -          - - - - -
>
> Could you confirm:
> PC=10 is seen accessible (the 2 routes are available) by SG (PC=1).
>   1/ SG receives a TFP concerning PC=10 on route 1. The SGP does not
>           have to send a DUNA to the ASP: from a SS7 point of view, PC=10
is
>
>           still accessible. Right?
> [John]  Right, since route 2 is still available to PC=10, the SG still
sees
> PC=10 as available and does not send a DUNA to the AS.
>   2/ SG receives a TFP concerning PC=10 on route 2. The SGP send a DUNA to
>      the ASP: from a SS7 point of view, PC=10 is no more available. Right?
> [John]  Right, since all of the SG's routes to PC=10 are prohibited, the
SG
> sees PC=10 as being unavailable and must send a DUNA to the AS.
>
> PC=10 is seen accessible (the 2 routes are available) by SG (PC=1).
>   1/ SG receives a TFR concerning PC=10 on route 1. Does the SGP need to
>           send a DRST message to the ASP?
> [John]  NO, the SG does not send a DRST to the AS.  The TFR only means
that
> if the SG has another route available to for PC=10, it should use it as
the
> primary route.  Since route 2 is available, the SG should send all traffic
> for PC=10 on it.
>   2/ SG receives a TFR concerning PC=10 on route 2. At this time, Route 1
>      and route 2 are restricted: Does the SGP need to send a DRST message
>           to the ASP? if yes, what is the semantic of DRST message
> then?
> [John]  Since all the routes that the SG has for PC=10 are restricted, the
> SG should send a DRST to the AS in case it has alternate routes that it
can
> use to reach PC=10.

[Greg] John's "view of the world" looks fine to me  2;^)

>
> Scenario 3:
> -----------
>
> |<------------ SS7 Network ------------->|           |<-- IP Network -->|
>
>                                           - - - - - -          - - - - -
>                                          |    SG     |        |    AS   |
>
>               +------+         route 1   | +------+  |        |         |
>             / | STP  |-------------------  | SGP1 |   \
> +------+  /   | PC=2 |                   | +------+  | \-----\| +-----+ |
> | SCP  |/     +------+                                        > | ASP |
> | PC=10|\     +------+         route 2   | +------+  | /-----/| +-----+ |
> +------+  \   | STP  |-------------------  | SGP2 |   /
>             \ | PC=3 |                   | +------+  |        |         |
>               +------+
>                                          |   PC=1    |        |         |
>                                           - - - - - -          - - - - -
>
> In this case, what are the differences from the scenario 2 ?
> I mean, SGP1 and SGP2 are working in the SAME SS7 point code. I cannot
> Believe that SGP1 is in charge of SS7 route 1 and SGP2 is in charge of SS7
> route 2 => it is not the responsibility of the SGP: it is the
responsibility
> of the *common* MTP3 layer.
> [John]  I agree with your view.  There is no difference.  PC/route states
> are on a SG level not a SGP level.

[Greg] (Note that there is a built in assumption on how links would be
allocated to the SGPs - route 1 and 2 look like linksets here.  I'm not sure
if this will always be the case.)  Anyway, I think there are a couple of
differences from Scenario 2 that I think we need to make clear.  First the
ASP now has two "routes" to the SG instead of one.  Also SGP1 and SGP2 are
also "connected - I think that there is really a "route 3" not shown from
SGP1 to SGP2.  While I don't think I would go so far as to say that SGP1 is
"in charge of" route 1, it does need to maintain local knowledge of the
availability of routes 1 and 3 and report changes to the SG level for
consideration of the overall PC/route.   Now, if the SGP1 gets a Data
message from the ASP destined for PC=10, and route 1 is down  (or route 1 is
prohibited for PC=10), it should re-route to route 3.  So in effect it has a
local alternate higher cost route to PC=10 via SGP2.  If the SG only sends
DUNA/DAVA/DRST wrt to the overall MTP3 Routeset status to DPC=10 it will not
tell the ASP that anything is amiss.  The ASP will happily use both its
routes to the SG even though the traffic to DPC-10 via SGP1 is actually
re-directed to SGP2 via route 3.

I'm not proposing this right now but I think SGP1 could send a locally
calculated DRST in this case to improve the routing.  When the routing issue
dissappears, a "local" DAVA could be sent to remove the restriction.  I'm
not sure if this is what SGP vendors want to do but I think it is possible.

>
> But anyway, what is supposed to happen (what are the M2UA MGT messages
> exchanged) when:
> PC=10 is seen accessible (the 2 routes are available) by SG (PC=1).
>   1/ SG receives a TFP concerning PC=10 on route 1.
>   2/ and then SG receives a TFP concerning PC=10 on route 2.
> [John]  I would say that a TFP is sent from the SG to the AS since all of
> the SG's routes to PC=10 are prohibited (PC=10 is unavailable).
>

[Greg] Again a possibility is reception of the first TFP could cause a
"local" DRST.  Reception of the second TFP could result in a DUNA from both
SGPs.  I'm probably going to make John crazy by saying that, but I think it
works from the perspective of the ASP.  On the down side this does mean that
any SG-level routeset status changes would need to be sent from both SGPs,
instead of just from one of them.  The plus side is that the ASP doesn't
really need to care if/how the SGPs are grouped into SGs.

> PC=10 is seen accessible (the 2 routes are available) by SG (PC=1).
>   1/ SG receives a TFR concerning PC=10 on route 1.
>   2/ and then SG receives a TFR concerning PC=10 on route 2.
> [John]  I would say that a TFR is sent from the SG to the AS since all of
> the SG's routes to PC=10 are restricted.  If the AS only has the route to
> this SG for PC=10, it would still send its traffic for PC=10 to this SG.
> The same is true for the SG, it would still send traffic for PC=10 to this
> pair of STPs.
>

[Greg] Hmmm - I not sure here.  The ASP really can't do anything much unless
it has an other equal cost route to another SG.  I think it might make sense
to send the DRST from both SGPs per my previous test logic  2;^)

> Many thanks in advance.
> /Pierre

[Greg] Good questions Pierre.
>
>
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Thursday, July 19, 2001 1:18 AM
> > To: sigtran
> > Subject: Re: M3UA (V7) DRST question
> >
> >
> > Greg,
> >
> > More below...
> >
> > Greg Sidebottom wrote:
> > (Wed, 18 Jul 2001 18:51:24)
> > > Hi Brian,
> > >
> > > Response below ...
> > >
> > > - Original Message -----
> > > From: "Brian F. G. Bidulock" <[email-masked]>
> > > To: "sigtran" <[email-masked]>
> > > Sent: Wednesday, July 18, 2001 5:49 PM
> > > Subject: Re: M3UA (V7) DRST question
> > >
> > >
> > > > Greg,
> > > >
> > > > I did find one problem with what you describe:  In several
> > > > places the draft make mention of things which would preclude,
> > > > or counter-recommend it:
> > > >
> > > >     Section 1.1
> > > >
> > > > "Where an SG contains more than one SGP, the SG is a
> > > > logical entity and the contained SGPs must be
> > > > coordinated into a signle management view to the SS7
> > > > network and to the supported Application Servers."
> > > >
> > >
> > > [Greg] Do you mean it is contradictory because, for
> > example, if only one SGP
> > > in an SG sends a DRST then this is not a single management
> > view from the SG
> > > to the supported Application Servers?  Probably true, but I
> > think this is a
> > > useful exception - the SGPs are coordinating the traffic
> > flows to make them
> > > more efficient.   I think we can get around this by using
> > "should" instead
> > > of "must" (i.e., "  .. the contained SGPs should be
> > coordinated ...  ") as
> > > in the other sections.
> > >
> > > >     Section 1.4.1
> > > >
> > > > "Where an SG contains more than one SGP, the MTP3
> > > > routeset, SPMC and remote AS/ASP states of each SGP
> > > > SHOULD be coordinated across all the SGPs.  Re-routing
> > > > of traffic between SGPs SHOULD also be supported."
> > > >
> > > > --Brian
> > >
> > > [Greg] I'm not sure yet why this text is contradictory?
> > The SGP states
> > > maintained locally can be different but aggregated into a
> > single set of
> > > overall SG states, assuming there is no breakdown of inter-SGP
> > > communication.
> >
> > Well, it is just a question of which thing you are sending
> > to the ASP when you send things like DRST for multiple SGP.
> > The ASP needs to know whether it is the SG status or the
> > SGP status which is being indicated.
> >
> >   If all these things (DUNA/DAVA/DRST) are only an
> >   indication of the SGP status, then the ASP receives
> >   one for each SGP and must derive the SG status from
> >   the aggregate of the SGPs--which is contrary to the
> >   above statements.
> >
> >   If DUNA/DAVA/DRST are indications of SG status, then
> >   it must already represent an aggregate view and the
> >   ASP needs only receive these from one SGP.
> >
> > Unfortunately you can't have it both ways unless we add
> > something to these messages: i.e. an indicator as to
> > whether the status applies to the SGP or the whole SG.
> >
> > I don't have a problem with the ASP keeping track of
> > these things on a per-SGP basis.  As a matter of fact I
> > think it is quite apt for M3UA.  But text list this
> > which recommends otherwise gives the impression that the
> > SG is aggregating these things for the ASP when  in the
> > per-SGP case, the ASP must do the aggregation.
> >
> >
> > >
> > > Thanks,
> > >
> > >     Greg
> > >
> >
> > --
> > 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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 19 Jul 2001 14:51:34 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUA: Section 4.1.3 text
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

Excellent!

Now, the only other thing that I would like clarified is the format of the
Destination Address parameter in the DUNA, DAVA, DRST or SCON messages.  I
suggest that the following be added to "Note 1" in the DUNA, DAVA, DRST and
SCON sections in Section 3.4:

    When the SSN is included in the Destination Address parameter,
    the DUNA/DAVA/DRST/SCON message corresponds to the SCCP N-STATE
    primitive.  When SSN is not included in the Destination Address
    paraemter, the DUNA/DAVA/DRST/SCON message corresponds to the
    SCCP N-PCSTATE primitive.

But this brings up another question regarding N-STATE:  Why is there no
Subsystem Multiplicity Indicator in the DUNA/DAVA/SCON messages?

--Brian

John Loughney wrote:                              (Thu, 19 Jul 2001
16:53:16)
> Brian,
> 
> Let me know how complete (or incomplete) this text is, with regards to
> N-PCSTATE.
> 
> thanks,
> John
> 
> 4.1.3 SS7 Signaling Network Management Procedures
> 
> When an SCCP Subsystem Management (SCMG) message is received from the SS7
> network, the SG needs to determine whether there are concerned Application
> Servers interested in subsystem status changes. The SUA management
function
> is informed with the N-State indication primitive upon which it formats
and
> transfers the applicable SNM message to the list of concerned ASPs using
> stream ID "0".
> 
> When MTP-3 Management indications are received (MTP-PAUSE, MTP-RESUME,
> MTP-STATUS), SCCP Subsystem Management determines whether there are
> concerned local SCCP-users. When these local SCCP-users are in fact
> Application Servers, serviced by ASPs, SUA management is informed with the
> PC-State indication primitive upon which it formats and transfers the
> applicable SNM message (DUNA, DAVA, DRST or SCON) to the list of concerned
> ASPs using stream ID "0".  
> 
> If an ASP receives a DUNA, DRST or SCON from a SGP, the SUA layer at the
ASP
> is expected to send traffic to the affected destination via an alternate
SGP
> of equal priority, but only if such an alternate route exists and is
> available. The local ASP SHOULD maintain the status of the possible routes
> to the peer endpoint in the SS7 network.  By maintaining the status of the
> possible routes, the ASP can determine if the remote peer is unavailable.
> 
> When the DAUD message is received at the SG from an ASP, the SG checks the
> status of the specified SS7 destination and returns DAVA, DUNA, DRST or
SCON
> depending on the result of the check. The SG initiates SST (Subsystem
Status
> Test) procedures by following the SCCP procedures described in Q.714,
these
> are not triggered by the receipt of a DAUD message.
> 
> SCCP Subsystem Management procedures may also be triggered in case of AS
> state changes, see chapter 4.4.1.2.
> 
> 
> ---
> 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, 19 Jul 2001 15:02:33 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: m2ua-09: comment #5
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

Why is it necessary to limit the SG to a single SGP?

--Brian

Ken Morneault wrote:                    (Thu, 19 Jul 2001 15:41:20)
> 
> 
> As has been noted, the current M2UA draft does not define a SG 
> Process.  
> 
> I would propose using the SG Process definition from M3UA but it
> would be necessary to limit the SG to a single SGP given
> the current draft.  Then, figure 2 could be updated to show 
> associations between ASP/SGP pairs.
> 
> 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]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA (V7) DRST question
Date: Thu, 19 Jul 2001 16:04:07 -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]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Rajiv,

See below ...

----- Original Message -----
From: "Kumar, Rajiv" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Thursday, July 19, 2001 1:35 PM
Subject: RE: M3UA (V7) DRST question

> Hi Greg/Pierre,
>
> I agree with Pierre that in case of DRST message ASP should not send the
> traffic to other SGPs in the same
> SG (represented with multiple SGPs)if it has available route through
another
> SG
> (represented with multiple SGPs) route.
>
> But I think this condition will be taken care of automatically in the
> following way:
>
> 1) SG gets a TFR from SS7 Network for a particular point code.
>
> 2) All the SGPs in this SG get STATUS as restricted for this point code
>    through NIF.
>

[Greg] It really depends on the Routeset Data - a TFR on one route does not
neccessaily mark a point code (routeset) as restricted. The SG Routeset
state may not change.  You really need to show the architecture and the
routeset data to decide if this is true.

> 3) All SGPs send DRST message to the Associated ASPs.

[Greg] Per my previous comment - maybe not.  But I think I agree with your
conclusion that if the overall SG MTP3 Routeset state changes, the
indication should be sent from all SGPs.

Cheers,

  Greg

>
> 4) Now ASP  know that the SS7 destination is  restricted through all
>    the SGPs in a particular  SG as it has rceived DRST message form all
the
>    SGPs of that SG. So the traffic will not be routed further in the
>    direction of SG itself, as it happens in case of other SSNM messages
(e.g
> DUNA) .
>
> In case we don't have any route available through an alternate SG we will
> have to
> send traffic to SGP of the same SG which sent DRST message.
>
> I think the reason of confusion is the following text in section 3.4.6
>
> " The DRST message is optionally sent from the SGP to all concerned ASPs"
>
> I think it should be changed as -
>
> "The DRST message is optionally sent from all the SGPs in an SG to all
> concerned ASPs"
>
> This is similar to what is mentioned in case of DUNA messages in section
> 3.4.1.
>
> Is that acceptable to all ?
>
> cheers,
> Rajiv
>
>
>
> Hi Pierre,
>
> I can give you my view of the world.  Comments below.
> John
>
>  -----Original Message-----
> From: Garnero, Pierre
> Sent: Thursday, July 19, 2001 8:56 AM
> To: sigtran
> Subject: RE: M3UA (V7) DRST question
>
> Thanks Greg and Brian for all you remarks ... but I am still puzzled ...
:-)
>
> So I would to submit some simple configurations and scenarios to help me
> understand the supposed M3UA behavior.
>
> Scenario 1:
> -----------
>
>
> |<------------ SS7 Network ------------->|           |<-- IP Network -->|
>
>                                           - - - - - -          - - - - -
>                                          |    SG     |        |    AS   |
>
>                                          |           |        |         |
>
> +------+      +------+ 1 single route    | +------+  |        | +-----+ |
> | SCP  |------| STP  |-------------------  | SGP1 |   --------  | ASP |
> | PC=10|      | PC=2 | 1 single channel  | +------+  |        | +-----+ |
> +------+      +------+
>                                          |           |        |         |
>
>                                          |   PC=1    |        |         |
>                                           - - - - - -          - - - - -
>
> Could you confirm:
>   1/ On receipt of a TFR concerning PC=10, SGP sends a DRST concerning
> PC=10.
>   2/ On receipt of a TFP concerning PC=10, SGP sends a DUNA concerning
> PC=10.
>   3/ If the single link between the SG and the adjacent (PC=2) breaks, SGP
>      sends a DUNA concerning PC=10.
>
> [John] Since the SG has a single route to the SS7 network (STP) it would
> "relay" the management messages to any AS it is connected to.
>
> Scenario 2:
> -----------
>
> |<------------ SS7 Network ------------->|           |<-- IP Network -->|
>
>                                           - - - - - -          - - - - -
>                                          |    SG     |        |    AS   |
>
>               +------+         route 1   |           |        |         |
>             / | STP  |-------------------
> +------+  /   | PC=2 |                   | +------+  |        | +-----+ |
> | SCP  |/     +------+                     | SGP1 |   --------  | ASP |
> | PC=10|\     +------+         route 2   | +------+  |        | +-----+ |
> +------+  \   | STP  |-------------------
>             \ | PC=3 |                   |           |        |         |
>               +------+
>                                          |   PC=1    |        |         |
>                                           - - - - - -          - - - - -
>
> Could you confirm:
> PC=10 is seen accessible (the 2 routes are available) by SG (PC=1).
>   1/ SG receives a TFP concerning PC=10 on route 1. The SGP does not
>           have to send a DUNA to the ASP: from a SS7 point of view, PC=10
is
>
>           still accessible. Right?
> [John]  Right, since route 2 is still available to PC=10, the SG still
sees
> PC=10 as available and does not send a DUNA to the AS.
>   2/ SG receives a TFP concerning PC=10 on route 2. The SGP send a DUNA to
>      the ASP: from a SS7 point of view, PC=10 is no more available. Right?
> [John]  Right, since all of the SG's routes to PC=10 are prohibited, the
SG
> sees PC=10 as being unavailable and must send a DUNA to the AS.
>
> PC=10 is seen accessible (the 2 routes are available) by SG (PC=1).
>   1/ SG receives a TFR concerning PC=10 on route 1. Does the SGP need to
>           send a DRST message to the ASP?
> [John]  NO, the SG does not send a DRST to the AS.  The TFR only means
that
> if the SG has another route available to for PC=10, it should use it as
the
> primary route.  Since route 2 is available, the SG should send all traffic
> for PC=10 on it.
>   2/ SG receives a TFR concerning PC=10 on route 2. At this time, Route 1
>      and route 2 are restricted: Does the SGP need to send a DRST message
>           to the ASP? if yes, what is the semantic of DRST message
> then?
> [John]  Since all the routes that the SG has for PC=10 are restricted, the
> SG should send a DRST to the AS in case it has alternate routes that it
can
> use to reach PC=10.
>
>
>
> Scenario 3:
> -----------
>
> |<------------ SS7 Network ------------->|           |<-- IP Network -->|
>
>                                           - - - - - -          - - - - -
>                                          |    SG     |        |    AS   |
>
>               +------+         route 1   | +------+  |        |         |
>             / | STP  |-------------------  | SGP1 |   \
> +------+  /   | PC=2 |                   | +------+  | \-----\| +-----+ |
> | SCP  |/     +------+                                        > | ASP |
> | PC=10|\     +------+         route 2   | +------+  | /-----/| +-----+ |
> +------+  \   | STP  |-------------------  | SGP2 |   /
>             \ | PC=3 |                   | +------+  |        |         |
>               +------+
>                                          |   PC=1    |        |         |
>                                           - - - - - -          - - - - -
>
> In this case, what are the differences from the scenario 2 ?
> I mean, SGP1 and SGP2 are working in the SAME SS7 point code. I cannot
> Believe that SGP1 is in charge of SS7 route 1 and SGP2 is in charge of SS7
> route 2 => it is not the responsibility of the SGP: it is the
responsibility
> of the *common* MTP3 layer.
> [John]  I agree with your view.  There is no difference.  PC/route states
> are on a SG level not a SGP level.
>
> But anyway, what is supposed to happen (what are the M2UA MGT messages
> exchanged) when:
> PC=10 is seen accessible (the 2 routes are available) by SG (PC=1).
>   1/ SG receives a TFP concerning PC=10 on route 1.
>   2/ and then SG receives a TFP concerning PC=10 on route 2.
> [John]  I would say that a TFP is sent from the SG to the AS since all of
> the SG's routes to PC=10 are prohibited (PC=10 is unavailable).
>
> PC=10 is seen accessible (the 2 routes are available) by SG (PC=1).
>   1/ SG receives a TFR concerning PC=10 on route 1.
>   2/ and then SG receives a TFR concerning PC=10 on route 2.
> [John]  I would say that a TFR is sent from the SG to the AS since all of
> the SG's routes to PC=10 are restricted.  If the AS only has the route to
> this SG for PC=10, it would still send its traffic for PC=10 to this SG.
> The same is true for the SG, it would still send traffic for PC=10 to this
> pair of STPs.
>
>
> Many thanks in advance.
>
> /Pierre
>
>
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Thursday, July 19, 2001 1:18 AM
> > To: sigtran
> > Subject: Re: M3UA (V7) DRST question
> >
> >
> > Greg,
> >
> > More below...
> >
> > Greg Sidebottom wrote:
> > (Wed, 18 Jul 2001 18:51:24)
> > > Hi Brian,
> > >
> > > Response below ...
> > >
> > > - Original Message -----
> > > From: "Brian F. G. Bidulock" <[email-masked]>
> > > To: "sigtran" <[email-masked]>
> > > Sent: Wednesday, July 18, 2001 5:49 PM
> > > Subject: Re: M3UA (V7) DRST question
> > >
> > >
> > > > Greg,
> > > >
> > > > I did find one problem with what you describe:  In several
> > > > places the draft make mention of things which would preclude,
> > > > or counter-recommend it:
> > > >
> > > >     Section 1.1
> > > >
> > > > "Where an SG contains more than one SGP, the SG is a
> > > > logical entity and the contained SGPs must be
> > > > coordinated into a signle management view to the SS7
> > > > network and to the supported Application Servers."
> > > >
> > >
> > > [Greg] Do you mean it is contradictory because, for
> > example, if only one SGP
> > > in an SG sends a DRST then this is not a single management
> > view from the SG
> > > to the supported Application Servers?  Probably true, but I
> > think this is a
> > > useful exception - the SGPs are coordinating the traffic
> > flows to make them
> > > more efficient.   I think we can get around this by using
> > "should" instead
> > > of "must" (i.e., "  .. the contained SGPs should be
> > coordinated ...  ") as
> > > in the other sections.
> > >
> > > >     Section 1.4.1
> > > >
> > > > "Where an SG contains more than one SGP, the MTP3
> > > > routeset, SPMC and remote AS/ASP states of each SGP
> > > > SHOULD be coordinated across all the SGPs.  Re-routing
> > > > of traffic between SGPs SHOULD also be supported."
> > > >
> > > > --Brian
> > >
> > > [Greg] I'm not sure yet why this text is contradictory?
> > The SGP states
> > > maintained locally can be different but aggregated into a
> > single set of
> > > overall SG states, assuming there is no breakdown of inter-SGP
> > > communication.
> >
> > Well, it is just a question of which thing you are sending
> > to the ASP when you send things like DRST for multiple SGP.
> > The ASP needs to know whether it is the SG status or the
> > SGP status which is being indicated.
> >
> >   If all these things (DUNA/DAVA/DRST) are only an
> >   indication of the SGP status, then the ASP receives
> >   one for each SGP and must derive the SG status from
> >   the aggregate of the SGPs--which is contrary to the
> >   above statements.
> >
> >   If DUNA/DAVA/DRST are indications of SG status, then
> >   it must already represent an aggregate view and the
> >   ASP needs only receive these from one SGP.
> >
> > Unfortunately you can't have it both ways unless we add
> > something to these messages: i.e. an indicator as to
> > whether the status applies to the SGP or the whole SG.
> >
> > I don't have a problem with the ASP keeping track of
> > these things on a per-SGP basis.  As a matter of fact I
> > think it is quite apt for M3UA.  But text list this
> > which recommends otherwise gives the impression that the
> > SG is aggregating these things for the ASP when  in the
> > per-SGP case, the ASP must do the aggregation.
> >
> >
> > >
> > > Thanks,
> > >
> > >     Greg
> > >
> >
> > --
> > 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]
>
>
>
> ---
> 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, 19 Jul 2001 16:25:15 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: m2ua-09: comment #5
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]

It is not necessary, but the current draft does not support  >1 SGP in a SG.
So far, no one has felt that it is important to support the concept of SGPs,
and, thus, >1 SGP in a SG.

Ken

At 03:02 PM 7/19/01 -0500, you wrote:
>Ken,
>
>Why is it necessary to limit the SG to a single SGP?
>
>--Brian
>
>Ken Morneault wrote:                    (Thu, 19 Jul 2001 15:41:20)
> > 
> > 
> > As has been noted, the current M2UA draft does not define a SG 
> > Process.  
> > 
> > I would propose using the SG Process definition from M3UA but it
> > would be necessary to limit the SG to a single SGP given
> > the current draft.  Then, figure 2 could be updated to show 
> > associations between ASP/SGP pairs.
> > 
> > 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] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA (V7) DRST question
Date: Thu, 19 Jul 2001 16:34:05 -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: [24.2.9.91]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

All,

I think Brian has hit the nail on the head about the inconsistency.  When I
updated Issue 7 I took was the agreed list view that an ASP should see
routes to a set of SGPs and not care how they are grouped into SGs, although
this is allowed.  This required that any change in the SG-level view of SS7
Destinations should result in any DUNAs/DAVAs/DRSTs to be sent from all SGPs
in an SG.  It also opened the door that these SSNM messages could be sent
from one SGP and it wouldn't apply to the entire SG.  So I think this can be
exploited in some cases to make the routing more efficient (e.g., DRST to
avoid inter-SGP routing).

There was some older text in the beginning of the document Brian pointed out
that is not really consistent with this new view, which I can now see not
quite right.

Now I see some views from John that go back to the pre-Issue 7 view that the
ASP needs to know which ASPs are in each SG and reception of a DUNA (for
example) would be interpreted as applying to the SG.  I have no problem with
either approach as long as it is just one, mostly because I have never been
involved in implementing SGPs to operate together.

So I think it comes down to some binary decisions.

1) Is it worthwhile to have an SGP-level indications to make the routing
more efficient at the SGPs?  If not then we just can restrict SSNM messages
to the SG-level changes.   The SGPs can take care of any internal routing
issues, like current STPs do.

2) Is it worthwhile to have the ASPs maintain knowledge of the SG/SGP
configuration?  If not then we need to have the SG send these SSNM messages
from all SGPs.  If so, then one message is sufficient.

Hope this helps,

Cheers,

     Greg

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Thursday, July 19, 2001 3:01 PM
Subject: Re: M3UA (V7) DRST question

> John,
>
> Then I take it that you have problem with the wording of the text
> in the current draft which requires that an ASP keep track of the
> availability/congestion/restricted status on a per-SGP basis?
>
> --Brian
>
> Schantz, John wrote:                                     (Thu, 19 Jul 2001
08:06:18)
> > Greg, Brian, everybody:
> >
> > I have a problem with this discussion.  To it looks like the train
> > is jumping its track.
> >
> > A DRST (& DUNA & DAVA & etc.) must be interrupted as the
> > status/state that a SG, as a whole, sees for a destination(s),
independent
> > of which one of the SG's SGP sent it.  It CAN NOT be used on an
individual
> > SGP basis.
> >
> > John Schantz
> > Compaq Telecom
> >
> >  -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Wednesday, July 18, 2001 6:18 PM
> > To: sigtran
> > Subject: Re: M3UA (V7) DRST question
> >
> > Greg,
> >
> > More below...
> >
> > Greg Sidebottom wrote:                                       (Wed, 18
Jul
> > 2001 18:51:24)
> > > Hi Brian,
> > >
> > > Response below ...
> > >
> > > - Original Message -----
> > > From: "Brian F. G. Bidulock" <[email-masked]>
> > > To: "sigtran" <[email-masked]>
> > > Sent: Wednesday, July 18, 2001 5:49 PM
> > > Subject: Re: M3UA (V7) DRST question
> > >
> > >
> > > > Greg,
> > > >
> > > > I did find one problem with what you describe:  In several
> > > > places the draft make mention of things which would preclude,
> > > > or counter-recommend it:
> > > >
> > > >     Section 1.1
> > > >
> > > > "Where an SG contains more than one SGP, the SG is a
> > > > logical entity and the contained SGPs must be
> > > > coordinated into a signle management view to the SS7
> > > > network and to the supported Application Servers."
> > > >
> > >
> > > [Greg] Do you mean it is contradictory because, for example, if only
one
> > SGP
> > > in an SG sends a DRST then this is not a single management view from
the
> > SG
> > > to the supported Application Servers?  Probably true, but I think this
is
> > a
> > > useful exception - the SGPs are coordinating the traffic flows to make
> > them
> > > more efficient.   I think we can get around this by using "should"
instead
> > > of "must" (i.e., "  .. the contained SGPs should be coordinated ...
") as
> > > in the other sections.
> > >
> > > >     Section 1.4.1
> > > >
> > > > "Where an SG contains more than one SGP, the MTP3
> > > > routeset, SPMC and remote AS/ASP states of each SGP
> > > > SHOULD be coordinated across all the SGPs.  Re-routing
> > > > of traffic between SGPs SHOULD also be supported."
> > > >
> > > > --Brian
> > >
> > > [Greg] I'm not sure yet why this text is contradictory?  The SGP
states
> > > maintained locally can be different but aggregated into a single set
of
> > > overall SG states, assuming there is no breakdown of inter-SGP
> > > communication.
> >
> > Well, it is just a question of which thing you are sending
> > to the ASP when you send things like DRST for multiple SGP.
> > The ASP needs to know whether it is the SG status or the
> > SGP status which is being indicated.
> >
> >   If all these things (DUNA/DAVA/DRST) are only an
> >   indication of the SGP status, then the ASP receives
> >   one for each SGP and must derive the SG status from
> >   the aggregate of the SGPs--which is contrary to the
> >   above statements.
> >
> >   If DUNA/DAVA/DRST are indications of SG status, then
> >   it must already represent an aggregate view and the
> >   ASP needs only receive these from one SGP.
> >
> > Unfortunately you can't have it both ways unless we add
> > something to these messages: i.e. an indicator as to
> > whether the status applies to the SGP or the whole SG.
> >
> > I don't have a problem with the ASP keeping track of
> > these things on a per-SGP basis.  As a matter of fact I
> > think it is quite apt for M3UA.  But text list this
> > which recommends otherwise gives the impression that the
> > SG is aggregating these things for the ASP when  in the
> > per-SGP case, the ASP must do the aggregation.
> >
> >
> > >
> > > Thanks,
> > >
> > >     Greg
> > >
> >
> > --
> > 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
> [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: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA (V7) DRST question
Date: Thu, 19 Jul 2001 13:41:44 -0700
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: zcamail05.zca.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [161.114.32.105]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,
	I will need to read what the changes are but availability and
congestion would show up in the status of the 'links/associations', hence it
is already taken care of.  There is no parallel for restricted for an
interface.

	If you look at the definition of a SG from the M3UA document:

Signalling Gateway - An SG is a signaling agent that receives/sends SCN
native signaling at the edge of the IP network [1].  An SG appears to the
SS7 network as an SS7 Signalling Point.  An SG contains a set of one or more
unique Signalling Gateway Processes, of which one or more is normally
actively processing traffic.  Where an SG contains more than one SGP, the SG
is a logical entity and the contained SGPs must be coordinated into a single
management view to the SS7 network and to the supported Application Servers.

	Notice the highlighted "single management view", this states to me
that the SG has a single management function even if it is composed of
multiple SGPs.  We will be supporting multiple ASPs and we will also have a
single management view of the system and it interfaces.  Therefore, if a PC
is prohibited, allowed, congested, or restricted, only single management
message should be sent to its adjacent nodes.  You can not use DUNA, DAVA,
SCON, DRST, etc. to manage a single SGP, they are the "single management
view" of the SG for destinations.

John

 -----Original Message-----
From: 	Brian F. G. Bidulock [mailto:[email-masked]] Sent:
Thursday, July 19, 2001 2:01 PM
To:	sigtran
Subject:	Re: M3UA (V7) DRST question

John,

Then I take it that you have problem with the wording of the text in the
current draft which requires that an ASP keep track of the
availability/congestion/restricted status on a per-SGP basis?

--Brian

Schantz, John wrote:                                     (Thu, 19 Jul 2001
08:06:18)
> Greg, Brian, everybody:
> 
> 	I have a problem with this discussion.  To it looks like the train
> is jumping its track.
> 
> 	A DRST (& DUNA & DAVA & etc.) must be interrupted as the
> status/state that a SG, as a whole, sees for a destination(s), independent
> of which one of the SG's SGP sent it.  It CAN NOT be used on an individual
> SGP basis.
> 
> John Schantz
> Compaq Telecom
> 
>  -----Original Message-----
> From: 	Brian F. G. Bidulock [mailto:[email-masked]] 
> Sent:	Wednesday, July 18, 2001 6:18 PM
> To:	sigtran
> Subject:	Re: M3UA (V7) DRST question
> 
> Greg,
> 
> More below...
> 
> Greg Sidebottom wrote:                                       (Wed, 18 Jul
> 2001 18:51:24)
> > Hi Brian,
> > 
> > Response below ...
> > 
> > - Original Message -----
> > From: "Brian F. G. Bidulock" <[email-masked]>
> > To: "sigtran" <[email-masked]>
> > Sent: Wednesday, July 18, 2001 5:49 PM
> > Subject: Re: M3UA (V7) DRST question
> > 
> > 
> > > Greg,
> > >
> > > I did find one problem with what you describe:  In several
> > > places the draft make mention of things which would preclude,
> > > or counter-recommend it:
> > >
> > >     Section 1.1
> > >
> > > "Where an SG contains more than one SGP, the SG is a
> > > logical entity and the contained SGPs must be
> > > coordinated into a signle management view to the SS7
> > > network and to the supported Application Servers."
> > >
> > 
> > [Greg] Do you mean it is contradictory because, for example, if only one
> SGP
> > in an SG sends a DRST then this is not a single management view from the
> SG
> > to the supported Application Servers?  Probably true, but I think this
is
> a
> > useful exception - the SGPs are coordinating the traffic flows to make
> them
> > more efficient.   I think we can get around this by using "should"
instead
> > of "must" (i.e., "  .. the contained SGPs should be coordinated ...  ")
as
> > in the other sections.
> > 
> > >     Section 1.4.1
> > >
> > > "Where an SG contains more than one SGP, the MTP3
> > > routeset, SPMC and remote AS/ASP states of each SGP
> > > SHOULD be coordinated across all the SGPs.  Re-routing
> > > of traffic between SGPs SHOULD also be supported."
> > >
> > > --Brian
> > 
> > [Greg] I'm not sure yet why this text is contradictory?  The SGP states
> > maintained locally can be different but aggregated into a single set of
> > overall SG states, assuming there is no breakdown of inter-SGP
> > communication.
> 
> Well, it is just a question of which thing you are sending
> to the ASP when you send things like DRST for multiple SGP.
> The ASP needs to know whether it is the SG status or the
> SGP status which is being indicated.
> 
>   If all these things (DUNA/DAVA/DRST) are only an
>   indication of the SGP status, then the ASP receives
>   one for each SGP and must derive the SG status from
>   the aggregate of the SGPs--which is contrary to the
>   above statements.
>   
>   If DUNA/DAVA/DRST are indications of SG status, then
>   it must already represent an aggregate view and the
>   ASP needs only receive these from one SGP.
> 
> Unfortunately you can't have it both ways unless we add
> something to these messages: i.e. an indicator as to
> whether the status applies to the SGP or the whole SG.
> 
> I don't have a problem with the ASP keeping track of
> these things on a per-SGP basis.  As a matter of fact I
> think it is quite apt for M3UA.  But text list this
> which recommends otherwise gives the impression that the
> SG is aggregating these things for the ASP when  in the
> per-SGP case, the ASP must do the aggregation.
> 
> 
> > 
> > Thanks,
> > 
> >     Greg
> > 
> 
> -- 
> 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
[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: Thu, 19 Jul 2001 16:02:41 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: m2ua-09: comment #5
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

Well.  That's the issue, isn't it?

I feel that it is important to support the concept of multiple SGP,
particularly because I have multiple processors which all have access to the
same pool of IIDs directly in line with the draft's original "SG/SGP" text.
It is hard to conceive of a large scale SG implementation which does not
have multiple processors and which does not have backplane TDM or packet
switching to assign HDLC or ATM cell processors (in SS7 terms, a pool of SDT
which have access to a pool of SDLs).  That was the purpose of the SDT
procedures: to permit the association of an SDT with an SDL.

I don't think that it is all that difficult.  As per the original post, all
that is really required is a definition of SGP and some selective choice of
how SG and SGP are used throughout the text.

I can put together the text, if you'd like.

--Brian

Ken Morneault wrote:                      (Thu, 19 Jul 2001 16:25:15)
> 
> 
> It is not necessary, but the current draft does not support
>  >1 SGP in a SG.  So far, no one has felt that it is important
> to support the concept of SGPs, and, thus, >1 SGP in a SG.
> 
> Ken
> 
> At 03:02 PM 7/19/01 -0500, you wrote:
> >Ken,
> >
> >Why is it necessary to limit the SG to a single SGP?
> >
> >--Brian
> >
> >Ken Morneault wrote:                    (Thu, 19 Jul 2001 15:41:20)
> > > 
> > > 
> > > As has been noted, the current M2UA draft does not define a SG 
> > > Process.  
> > > 
> > > I would propose using the SG Process definition from M3UA but it
> > > would be necessary to limit the SG to a single SGP given
> > > the current draft.  Then, figure 2 could be updated to show 
> > > associations between ASP/SGP pairs.
> > > 
> > > 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] 
> 
> 
> 
> ---
> 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, 19 Jul 2001 14:13:29 -0700
From: nirmalesh <[email-masked]>
Subject: Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
Sender: root@nodots-daemon
To: "sigtran" <[email-masked]>
Organization: TeleSys
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
X-SMTP-HELO: snfc21.pbi.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [206.13.28.240]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,
 I hope you agreed on that error case !!.
 More the information stronger will be the protocol.
 My intention is to give the right reason.
 Otherwise one needs to run around without knowing the actual cause.
 I opened "duplicate" error as  ASP Id assignment is not clear, any one can
pick it up randomly .
 Definitely there will be even more error cases !!! Your invalid case can do
the duty of double , triple..or Fou ...          :-)

cheers,
Nirmalesh
"Brian F. G. Bidulock" wrote:

> nirmalesh,
>
> I though that Invalid could do double duty for Duplicate. ;)
>
> nirmalesh wrote:                                        (Thu, 19 Jul 2001
10:49:43)
> >
> >    Hi,
> >     Another Error is needed ..
> >    [email-masked] wrote:
> >
> >      Hi Brian,
> >
> >      John,
> >      >
> >      > Then may I suggest that we add the errors:
> >      >
> >      >       Error - ASP Identifier Required
> >      >       Error - Invalid ASP Identifier
> >
> >              Error - Duplicate ASP Id
> >
> >
> >      >
> >      > as a valid reponses of an SG to a ASP Up message.
> >
> >      I think I can live with those ...
> >
> >      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]
>
> --
> 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: Thu, 19 Jul 2001 17:22:52 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: m2ua-09: comment #5
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]

Brian,

If you have time in the next couple of days to generate the text changes
that would be fine.  Otherwise, I'll send out proposed changes early next
week.

Regards,

Ken

At 04:02 PM 7/19/01 -0500, you wrote:
>Ken,
>
>Well.  That's the issue, isn't it?
>
>I feel that it is important to support the concept of multiple SGP,
>particularly because I have multiple processors which all have
>access to the same pool of IIDs directly in line with the draft's
>original "SG/SGP" text.  It is hard to conceive of a large scale SG
>implementation which does not have multiple processors and which
>does not have backplane TDM or packet switching to assign HDLC or
>ATM cell processors (in SS7 terms, a pool of SDT which have access
>to a pool of SDLs).  That was the purpose of the SDT procedures:
>to permit the association of an SDT with an SDL.
>
>I don't think that it is all that difficult.  As per the original
>post, all that is really required is a definition of SGP and some
>selective choice of how SG and SGP are used throughout the text.
>
>I can put together the text, if you'd like.
>
>--Brian
>
>
>Ken Morneault wrote:                      (Thu, 19 Jul 2001 16:25:15)
> > 
> > 
> > It is not necessary, but the current draft does not support
> >  >1 SGP in a SG.  So far, no one has felt that it is important
> > to support the concept of SGPs, and, thus, >1 SGP in a SG.
> > 
> > Ken
> > 
> > At 03:02 PM 7/19/01 -0500, you wrote:
> > >Ken,
> > >
> > >Why is it necessary to limit the SG to a single SGP?
> > >
> > >--Brian
> > >
> > >Ken Morneault wrote:                    (Thu, 19 Jul 2001 15:41:20)
> > > > 
> > > > 
> > > > As has been noted, the current M2UA draft does not define a SG 
> > > > Process.  
> > > > 
> > > > I would propose using the SG Process definition from M3UA but it
> > > > would be necessary to limit the SG to a single SGP given
> > > > the current draft.  Then, figure 2 could be updated to show 
> > > > associations between ASP/SGP pairs.
> > > > 
> > > > 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] 
> > 
> > 
> > 
> > ---
> > 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]
Date: Thu, 19 Jul 2001 16:37:42 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA (V7) DRST question
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

I think that you are reading alot into the "single management view"
statement, as it is not really defined what this means; but, I understand
what you are getting at.  Certainly the fact that it is possible that an ASP
may receive conflicting information from individual SGP, it does not
preclude building a system which assumes this single management view.

Perhaps a resolution to the situation, for the sake of interoperability, is
to say the the SG SHOULD present such a single view of availability/
congestion/restriction status, but that the ASP SHOULD keep track of that
status on a per-SGP basis.

Then, if an ASP implementation chooses to rely heavily on a single
management view from the SG, it must do so with the full understanding that
it might not interoperate as well with a partionable SG implementation.
And, if the SGP implementation chooses to not present such a single
management view to the ASP, that it might not interoperate as well with ASPs
which rely upon it.

That way due warning is given, nothing is precluded, and maximum
interoperability may result.  Let the implementations solve the details.

Plus, this takes the least amount of text changes, right Greg?

Comments?

--Brian

Schantz, John wrote:                           (Thu, 19 Jul 2001 13:41:44)
> Brian,
> 	I will need to read what the changes are but availability and
> congestion would show up in the status of the 'links/associations', hence
it
> is already taken care of.  There is no parallel for restricted for an
> interface.
> 
> 	If you look at the definition of a SG from the M3UA document:
> 
> Signalling Gateway - An SG is a signaling agent that receives/sends SCN 
> native signaling at the edge of the IP network [1].  An SG appears to 
> the SS7 network as an SS7 Signalling Point.  An SG contains a set of one 
> or more unique Signalling Gateway Processes, of which one or more is 
> normally actively processing traffic.  Where an SG contains more than 
> one SGP, the SG is a logical entity and the contained SGPs must be 
> coordinated into a single management view to the SS7 network and to the 
> supported Application Servers.
> 
> 	Notice the highlighted "single management view", this states to me
> that the SG has a single management function even if it is composed of
> multiple SGPs.  We will be supporting multiple ASPs and we will also have
a
> single management view of the system and it interfaces.  Therefore, if a
PC
> is prohibited, allowed, congested, or restricted, only single management
> message should be sent to its adjacent nodes.  You can not use DUNA, DAVA,
> SCON, DRST, etc. to manage a single SGP, they are the "single management
> view" of the SG for destinations.
> 
> 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: Thu, 19 Jul 2001 16:50:57 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
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.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Nirmalesh,

I am a proponent of not including errors for which there is no action.
Actually, these three could probably be collapsed into one:  "Error -
Missing, Duplicate or Invalid ASP Identifier" Any additional information
could be included in the INFO string.
Really all the ASP needs to know is that it has messed up somehow with
regard to ASP Id, not to expect an ASPUP Ack, to cancel T(ack), and to
expect the same treatment on a repeat attempt.

If you want detailed diagnotic information, I'm sure that the SG will be
capable of collecting it for you, and even placing it in the INFO string;
however, what is the ASP going to do differenly in response to these error
messages?

I hate writing case statements like this:

	switch ( error_type )
	{
		case M2UA_ERR_MGMT_BLOCKING:
			/*
			 *  do something
			 */
			 break;

		case M2UA_ERR_MISSING_ASPID:
		case M2UA_ERR_INVALID_ASPID:
		case M2UA_ERR_DUPLICATE_ASPID:
		case M2UA_ERR_TOO_MANY_ASPIDS_IN_MESSAGE:
		case M2UA_ERR_OTHER_ASPID_RESOURCE_FAILURE:
			/*
			 *  do the same thing in all cases anyway
			 */
			 break;

		 default:
			/*
			 *  do nothing
			 */
			 break;
	}

They just hamper performance.  If you want to inform management differenly
for each case, place it in the INFO string which this code can just ignore
and pass transparently to management.

--Brian

nirmalesh wrote:                                        (Thu, 19 Jul 2001
14:13:29)
> Brian,
>  I hope you agreed on that error case !!.
>  More the information stronger will be the protocol.
>  My intention is to give the right reason.
>  Otherwise one needs to run around without knowing the actual cause.
>  I opened "duplicate" error as  ASP Id assignment is not clear, any one
can pick it up
> randomly .
>  Definitely there will be even more error cases !!! Your invalid case can
do the duty
> of double , triple..or Fou ...          :-)
> 
> cheers,
> Nirmalesh
> "Brian F. G. Bidulock" wrote:
> 
> > nirmalesh,
> >
> > I though that Invalid could do double duty for Duplicate. ;)
> >
> > nirmalesh wrote:                                        (Thu, 19 Jul
2001 10:49:43)
> > >
> > >    Hi,
> > >     Another Error is needed ..
> > >    [email-masked] wrote:
> > >
> > >      Hi Brian,
> > >
> > >      John,
> > >      >
> > >      > Then may I suggest that we add the errors:
> > >      >
> > >      >       Error - ASP Identifier Required
> > >      >       Error - Invalid ASP Identifier
> > >
> > >              Error - Duplicate ASP Id
> > >
> > >
> > >      >
> > >      > as a valid reponses of an SG to a ASP Up message.
> > >
> > >      I think I can live with those ...
> > >
> > >      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]
> >
> > --
> > 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
[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: Thu, 19 Jul 2001 16:57:11 -0500
From: Kurt Kite <[email-masked]>
Reply-To: [email-masked]
Organization: Ericsson North America Inc.
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: One more comment version 7
X-SMTP-HELO: imr1.ericy.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: imr1.ericy.com [208.237.135.240]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Page 68, Figure 4: ASP State Transition Diagram

It is now possible to transition from ASP-ACTIVE or ASP-STANDBY to
ASP-INACTIVE due to an ASP UP message.

/Kurt

---
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, 19 Jul 2001 22:16:58 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: M2UA - Issue #7 - ASP Active 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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Note:  This issue also impacts M3UA.  Just replace Interface Identifier with
Routing Context.

If an SG receives an ASP Active message (at the proper time) which has some
Interface Ids indicating AS for which the ASP is not configured/registered,
how does the SG respond?  The draft only allows for two situations that I
can see:

   1.  ASP Active is unexpected:  Error - Unexpected Message
   2.  ASP Active is expected:    Must return ASP Active Ack.

We need a procedure to tell the ASP that an interface id is incorrect or
that some other failure has occured and which describes the disposition of
valid IIDs in the ASP Active.

The use of ERR (Invalid Interface Identifier) is appropriate, however, it
should be mentioned in the ASP Active procedures section.

Also, the disposition of other non-errored IIDs in the ASPAC needs to be
addressed for interoperability sake.

For example, the ASP sends an ASPAC with 5 IIDs which are representative of
5 ASs.  Two of them are invalid (i.e., there is no configured/registered AS
which has these two IIDs on the SG).  The SG could respond with an ERR
(Invalid Interface Identifier) and an ASPAC Ack for the 3 successful IIDs,
but then how does the ASP know which IIDs the ERR corresponds to.

Perhaps it is a general correspondence of ERR message problem similar to
that posted for M3UA today.  The proposal there was to include a message and
parameter diagnostic in the ERR message to permit the error to be correlated
with the message and parameter causing the error.  If this proposal were to
be adopted for M2UA, it would permit an ERR (Invalid Interface Identifier)
with a parameter diagnostic listing the two IIDs which were at fault.  Then
the ASP would know to stop any T(ack) timers with regard to those IIDs.

Another approach would be to fail all 5 IIDs and only send one ERR message
(and no ASPAC Ack).  This would be a better approach because the ASP may not
want to start receiving traffic for a partly unsuccessful activation
attempt.

It gets worse for IID ranges.

Otherwise, to get expected behavior, the ASP will need to send each IID in
an individual ASPAC and wait for the ASPAC Ack or ERR message on each before
sending the next and will have to be prepared to start messaging on a
partially built group of AS.  This would severly reduce the value and
usability of placing multiple IID in the ASPAC message at all.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUA Common Parameter Range was: M3UA v07: Some Comments
Date: Thu, 19 Jul 2001 22:22:30 -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]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

No problem!

I'll move to the M3UA-specific range to 0x0200 to 0x02ff for Issue 8 from
the current 0x0080 to 0x00bf.  The change in Issue 7 is only two weeks old
so I don't think its too bad.  Better now than later.

Cheers,

   Greg

----- Original Message -----
From: "Ken Morneault" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Thursday, July 19, 2001 11:09 AM
Subject: Re: SUA Common Parameter Range was: M3UA v07: Some Comments

>
>
> Greg,
>
> I took the range 0x0300 to 0x03ff so that you could have 0x0200 to 0x02ff
> for M3UA (since John started from 0x0100).
>
> I'd prefer not change the range since M2UA is in last call.
>
> Ken
>
> At 02:00 PM 7/19/01 +0300, [email-masked] wrote:
> >Greg,
> >
> >       0x00 to 0x3f  Common/IUA parameters
> >       0x40 to 0x7f  M2UA-specific
> >       0x80 to 0xbf  M3UA-specific
> >       0xc0 to 0xff   SUA-specific
> >
> >If OK with you, I want SUA range to be starting from 0x0100 - since that
is
> >what I have already done!
> >
> >0x0100 to 0x0105f for SUA specific parameters would be 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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Lotus-FromDomain: HSS
From: [email-masked]
To: "sigtran" <[email-masked]>
Date: Fri, 20 Jul 2001 09:15:26 +0530
Subject: M2UA-09: comment #6
X-SMTP-HELO: hindon.hss.co.in
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [202.54.26.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi,

1.Some typos: M3UA being used instead of M2UA(such as in 3.3.1.1). And
vice-versa in sec 3.1.2
2.The Correlation ID is optional in the Data message. In which case, it
implies that the Data Ack
need not be sent if this parameter is not received in the Data msg.Is that
correct?
If so, this can be mentioned in sec 3.3.3 Also, what should/may be done if
the ack is not received (or received for that matter)? A mention can be made
about this.

thanks
Harsh Bhondwe
Hughes Software Systems

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Thu, 19 Jul 2001 23:16:18 -0500
From: Kurt Kite <[email-masked]>
Reply-To: [email-masked]
Organization: Ericsson North America Inc.
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M2UA - Issue #7 - ASP Active procedures
X-SMTP-HELO: imr2.ericy.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: imr2.ericy.com [12.34.240.68]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hi Ken,

Some comments below, which only pertain to M3UA draft, but I assume can be
applied to M2UA as well.

/Kurt

Ken Morneault wrote:

> Note:  This issue also impacts M3UA.  Just replace Interface Identifier
> with Routing Context.
>
> If an SG receives an ASP Active message (at the proper time)
> which has some Interface Ids indicating AS for which the ASP
> is not configured/registered, how does the SG respond?  The
> draft only allows for two situations that I can see:
>
>    1.  ASP Active is unexpected:  Error - Unexpected Message
>    2.  ASP Active is expected:    Must return ASP Active Ack.

If the ASP Active is received at the proper time then I think the proper
error code is "Invalid Routing Context."

>
>
> We need a procedure to tell the ASP that an interface id is
> incorrect or that some other failure has occured and which
> describes the disposition of valid IIDs in the ASP Active.
>
> The use of ERR (Invalid Interface Identifier) is appropriate, however,
> it should be mentioned in the ASP Active procedures section.

I agree. In M3UA this is mentioned in the "ASP Inactive Procedures" section,
but not explicitly in the "ASP Active Procedures" section. The text reads:

     Multiple ASP Inactive Ack messages MAY be used in response to an ASP
     Inactive message containing multiple Routing Contexts, allowing the SGP
     or IPSP to independently acknowledge for different (sets of) Routing
     Contexts.  The SGP or IPSP sends an Error message ("Invalid Routing
     Context") message for each invalid or un-configured Routing Context
     value in a received ASP Inactive message message.

>
>
> Also, the disposition of other non-errored IIDs in the ASPAC
> needs to be addressed for interoperability sake.
>
> For example, the ASP sends an ASPAC with 5 IIDs which are
> representative of 5 ASs.  Two of them are invalid (i.e., there
> is no configured/registered AS which has these two IIDs on the
> SG).  The SG could respond with an ERR (Invalid Interface
> Identifier) and an ASPAC Ack for the 3 successful IIDs, but
> then how does the ASP know which IIDs the ERR corresponds to.
>
> Perhaps it is a general correspondence of ERR message problem
> similar to that posted for M3UA today.  The proposal there was
> to include a message and parameter diagnostic in the ERR
> message to permit the error to be correlated with the message
> and parameter causing the error.  If this proposal were to be
> adopted for M2UA, it would permit an ERR (Invalid Interface
> Identifier) with a parameter diagnostic listing the two IIDs
> which were at fault.  Then the ASP would know to stop any
> T(ack) timers with regard to those IIDs.

This is almost the way that I interpret the M3UA draft, with the exception
that an Error message would be sent for each erroneous Identifier.

>
>
> Another approach would be to fail all 5 IIDs and only send
> one ERR message (and no ASPAC Ack).  This would be a better
> approach because the ASP may not want to start receiving
> traffic for a partly unsuccessful activation attempt.

I don't know if it is necessarily better. From an implementation point of
view I think it is more complicated. You would have to ensure that you could
guarantee the success of each IID activation at the start or you would have
to back out activated IIDs when you encountered an error.

>
>
> It gets worse for IID ranges.

Agreed.

>
>
> Otherwise, to get expected behavior, the ASP will need to send
> each IID in an individual ASPAC and wait for the ASPAC Ack or
> ERR message on each before sending the next and will have to
> be prepared to start messaging on a partially built group of
> AS.  This would severly reduce the value and usability of placing
> multiple IID in the ASPAC message at all.

This is the approach we have taken. It's simple. It's easy to correlate
errors (you don't need the more complicated error message I proposed for
M3UA because the error code is sufficient to point out the erroneous
parameter). So, our view is that there is no value in specifying multiple
IIDs in a message other that to save bandwidth, which we did not think was
too important since these are management messages and will not be sent too
frequently.

Why would the ASP not be prepared to process traffic for only part of the
ASs? It seems like it would be better to process some traffic rather none at
all.

>
>
> ---
> 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]>
Cc: [email-masked]
Subject: RE: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
Date: Fri, 20 Jul 2001 08:22:21 +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: [131.228.20.22]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian & Nirmalesh,

> I though that Invalid could do double duty for Duplicate. ;)

I concur with Brian.

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: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
Date: Fri, 20 Jul 2001 09:57:37 +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]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi John,

> 	We see no need for an ASP identifier at all!  Even 
> Brian's proposal is not acceptable because it is just an 
> indirect way of having a mandatory ASP identifier.

My feeling is that this should be an optional parameter, based upon what
vendors want to support.  

best regards,
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: SUA: Section 4.1.3 text
Date: Fri, 20 Jul 2001 10:20:58 +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,

> Now, the only other thing that I would like clarified is the format
> of the Destination Address parameter in the DUNA, DAVA, DRST or SCON
> messages.  I suggest that the following be added to "Note 1" in the
> DUNA, DAVA, DRST and SCON sections in Section 3.4:
> 
>     When the SSN is included in the Destination Address parameter,
>     the DUNA/DAVA/DRST/SCON message corresponds to the SCCP N-STATE
>     primitive.  When SSN is not included in the Destination Address
>     paraemter, the DUNA/DAVA/DRST/SCON message corresponds to the
>     SCCP N-PCSTATE primitive.

Agreed.

> But this brings up another question regarding N-STATE:  Why is there
> no Subsystem Multiplicity Indicator in the DUNA/DAVA/SCON messages?

This was deemed not needed. I'll try to dig up the thread on it.
During last call, please feel free to bring this up (with solutions, of
course).

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 20 Jul 2001 02:47:36 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA - Issue #7 - ASP Active 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: [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Kurt,

Kurt Kite wrote:                              (Thu, 19 Jul 2001 23:16:18)

> 
> Why would the ASP not be prepared to process traffic for only part of the
> ASs? It seems like it would be better to process some traffic rather none
at
> all.

Unfortunately an ASP may need to rely on an atomicity of activation with
multiple AS due to limitations of the Routing Context and the needs of the
application.  For example, a transaction service may need to be
configured/registered in two ASs, one for incoming transactions (e.g., VLR)
and one for outgoing transactions (e.g., HLR) to be able to process any
traffic.  This would be of specific concern in Override mode where an
existing active ASP may be handling traffic already.  A half-failure of the
activation could result in a half-override which would disrupt application
transaction processing until the ASP previously master ASP could be informed
of the failure and attempt a switchback.  The swichback attempt could also
fail due to a temporary or permanent configuration mismatch.

Unfortunately some UA Routing Context have limitations in the span of
Routing Keys that the AS can support.  An example would be M3UA, where the
Routing Key cannot span outside the SPMC, but the ASP application may need
to act as multiple point codes to properly perform its functioning of
traffic.

Examples for M2UA are probably rare compared to M3UA and SUA, however, an
example for M2UA might be where links (IIDs) need to be independent for
configuration purposes (e.g. the links in a link set need to be determined
under management action without affecting a current and running AS), but
need to be activated under Override in concert for management reasons (e.g.,
switching a linkset from a master processor to a standby processor for hot
upgrades).

At least that was my thinking behind the statement that the ASP may not be
able to process traffic (perform its application function) properly until it
is active in all the AS specified.

Now it is true in all the UAs that if one does not specify the Routing
Context/IID at all, that the SG could be implemented to guarantee this type
of atomicity of activation.  However, this has ramifications for operational
management systems which would then perhaps need to guarantee atomicity of
configuration changes in all SGP within multiple SGs and all ASPs withing
multiple hosts.  Such atomicity of configuration usually impairs front-end
performance of the system to impose the data locks necessary for multiple
managed information base atomic updates an may be as disruptive as a glitch
in the activation.

Because of this, it would be good that if the ASP activates with mutliple
routing contexts, that an error response be possible to reject the entire
set.  The SG should easily be capable of test and set synchronization on the
set of routing contexts and be able to pass success on the whole group or
reject the whole set with no partial-successes and partial-failures.  This
would preclude the necessity for correlation of the ERR response with the
individual Routing Context, because the error would apply to the set, rather
than the individual routing context.  That way, if the ASP really wants
non-atomic registration, it could send independent ASPAC messages with
individual RC/IID.

Aside from style, there is no discernable benefit from combining RC/IID in
an ASPAC anyway: particularly for SCTP transport.  Many smaller messages or
one larger message has little discernable impact on an SCTP implementation
which makes intelligent bundling decisions.

-- 
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, 20 Jul 2001 03:11:56 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: AS Identification Issue
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Satish,

Satish K wrote:                                   (Sun, 20 May 2001
13:00:54)
> Hi All,
>     We generally Identify the ASP messages at SGP using either Routing key
> or Association ID. Is there a way how we can identify the AS to which this
> ASP message is associated with.
>      Is this AS Identification Implementation dependent ie logical
> separation or there is a field in the message body by which we can
identify
> from which AS it is comming. Like if u want to know to which AS this ASPUP
> message of a ASP is associated with.
> Thanks
> Satish

When an ASPUP message is received, the ASP it is either not yet associated
with an AS (dynamic registration) or it is implicity associated with one or
more AS (static configuration).  [This is assuming that the SG can identify
the ASP from either information about the SCTP association or the ASP Id
which is "optionally" contained in the ASPUP message.]

Because of this, the ASPUP (and for that matter all of the ASPSM and ASPTM)
are associated with one or more AS.  Whether registration or configuration
is used, both the SG(P) and ASP should be aware from local data which AS(s)
an ASPSM/ASPTM applies.

RKM messages implicitly apply to the AS(s) for which the registration(s) or
deregistration(s) are being invoked.

For M2UA MAUP messages, the Interface Id in the MAUP common header of the
message explicitly identifies the AS to which the message belongs.

For M3UA SNMM and DATA messages, there is no identification of the AS,
implicit or explicit, to which the message applies.  In the current draft it
is necessary (both at the SGP and the ASP) to apply the set of Routing Keys
which are applicable to message to determine the AS.

This has been identified as an issue in M3UA which would be solved by adding
the Routing Context to each SNMM and DATA message in the same manner that
M2UA adds an Interface Id now.  This would mean that the Routing Key would
only have to be applied against the message once at the SGP and only for
messages in the SS7->IP direction.  There is a standing proposal for M3UA to
replace the optional Network Appearance with a mandatory Routing Context
parameter in SNMM and DATA messages to accomplish this.

It is the same situation in SUA as M3UA.  The proposal to replace Network
Appearance with Routing Context in Signalling Network Management,
Connectionless and Connection-Oriented messages has also been put forward.

--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: Fri, 20 Jul 2001 04:06:46 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: SUA-06: Signalling Link Selection 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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

In SUA O6 the CLDT message under Class 1 operation has no way for the AS to
specify the SLS value associated with the message.
This makes it impossible for SCCP at the SG to determine the proper SLS
value to use in the MTP-TRANSFER primitive with which the N-UNITDATA is
transfered.

Also, under Class 0 operation, the SCCP is still responsible for ensuring
that SLS selection is properly performed.

Under Class 0, for distibuted SCTP-User transaction processing
architectures, it is typical to perform SLS rotation on the incoming SLS on
the invoke to obtain the SLS to be used on the reply.  This is the simplest
way of ensuring load-sharing over the available SLS without having to
coordinate SLS values between ASPs using ASP-to-ASP communication.

Under Class 1, the same SLS rotation is usually performed on the SLS
incoming invoke to use in all subsequent conversation and reply messages to
maintain Class 1 operation.  Again, this is the simplest approach to ensure
load-sharing without ASP to ASP coordination, yet maintaining an SLS for the
duration of the transaction to sustain Class 1 operation.

Similar rules regarding SLS can be applied to Class 2 and Class 3 operation
as in Class 1.

Consider that, even though SLS is not shown on the basic N-UNITDATA
definitions, the following quote from ANSI T1.112.4-1992 (Q.714) Section
1.1.2.2:

    "In protocol class 1, the features of class 0 are
    complemented by an additional feature (i.e., sequence
    control parameter associated with the N-UNITDATA request
    primitive) which allows the higher layer to indicate to the
    SCCP that a given set of NSDUs have to be delivered
    in-sequence.  The Signalling Link Selection (SLS) field is
    chosen, based on the value of the sequence control
    parameter.  The SLS chosen for a stream of NSDUs with the
    same sequence control parameter will be identical.  SCCP
    will then encode the SLS field in the routing label...."

Therefore the CLDT message will require a "sequence control" parameter which
is large enough to contain an SLS value.

Because this sequence control parameter is closely associated with the
protocol class, I propose that the following changes be made to the "Flags"
parameter in section 3.9.1:

  3.9.1  Flags

     The flags parameter is a conglomerate of the following parameters,
>    described in ITU-T Recommendation Q.713/Q.714 :

        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 = 0x0101          |             Length = 8        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | Seq. Control  |  Importance   |  Hop Counter  |  Protocol Cl. |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Protocol Class (3.6/Q.713)

           Bits 1-2 indicate the protocol ...

    ...

>   Sequence Control (1.1.2/Q.714)
>
>          Bits 1-5 are coded with the value of the sequence control
>          parameter associated with a group of messages and must be
>          chosen so as to ensure proper loadsharing of message groups
>          over SLS values while ensuring that sequence control values
>          within message groups have the sequence control value coded
>          with the same value as the initial message of the message
>          group.
>
>          Bits 6-8 are spare bits and should be coded zero.

-- 
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: SUA-06: Signalling Link Selection Problems
Date: Fri, 20 Jul 2001 12:30:57 +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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

> In SUA O6 the CLDT message under Class 1 operation has no way
> for the AS to specify the SLS value associated with the message.
> This makes it impossible for SCCP at the SG to determine the
> proper SLS value to use in the MTP-TRANSFER primitive with which
> the N-UNITDATA is transfered.
> 
> Also, under Class 0 operation, the SCCP is still responsible for
> ensuring that SLS selection is properly performed.

Good catch.

> Therefore the CLDT message will require a "sequence control"
> parameter which is large enough to contain an SLS value.
> 
> Because this sequence control parameter is closely associated
> with the protocol class, I propose that the following changes be
> made to the "Flags" parameter in section 3.9.1:

Sounds very reasonable.  Thanks for the text.

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: asodhi <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: upper layer primitives of SUA
Date: Fri, 20 Jul 2001 15:08:06 +0530
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-SMTP-HELO: smtp.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!

i am not getting the details of all the parameters that are used by
N-CONNECT primitive etc. i got the details of Called address, calling
address, user data but not of expedited data selection, quality of service
parameter set.

what's the way to get full details of the Primitive parameters,not of the
message parameters.

Sodhi

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Original-To: IETF-Announce:;;@cnri.reston.va.us@zrtps0jn
PP-Warning: Parse error in original version of preceding To line
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sigtran-dua-00.txt
Date: Fri, 20 Jul 2001 05:38:18 -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]>
To: "sigtran" <[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		: DPNSS/DASS 2 extensions to the IUA protocol
	Author(s)	: A. Vydyam et al.
	Filename	: draft-ietf-sigtran-dua-00.txt
	Pages		: 
	Date		: 19-Jul-01
	
This document defines a mechanism for backhauling of DPNSS/DASS2 messages
over IP by extending the ISDN User Adaptation Layer Protocol reference
RFC3057. This document aims to become an Appendix to IUA and to be the base
for a DUA implementation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sigtran-dua-00.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-dua-00.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-dua-00.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-dua-00.txt

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-sigtran-dua-00.txt> ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07 Comments
Date: Fri, 20 Jul 2001 06:12:29 -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]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

My responses ..

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Tuesday, July 10, 2001 7:28 PM
Subject: M3UA07 Comments

Following are some preliminary comments on the M3UA07 draft.

In addition to these comments there are still the outstanding issues which
have not been addressed:

    o   DATA payload formats.
    o   Routing Context in DATA messages.
    o   Changeover and Changeback support.
    o   Correlation Id.
    o   Broadcast traffic mode.
    o   SGP management support.

Section 1.1 Scope, first paragraph:

"...  The delivery mechanism SHOULD meet the following criteria:"

    What is the point in specifying what the _draft_ SHOULD do?
    This "SHOULD" does not place a recommendation on an
    implementation...  Either this "SHOULD" is implicitly met, or
    implicitly not met, by the draft itself.  Suggest rewording as:

The delivery mechanism addresses the following objectives:

[Greg] Done

Section 1.2 Terminology, second last sentence in first paragraph
(Application Server definition):

"... An AS is contained within a single Network Appearance.
..."

    What is this supposed to mean?

[Greg] Gone.

Section 1.2 Terminology, second paragraph (Application Server Process
definition):

"an active or standby" was changed to "active or back-up"

    Why?

[Greg] So as not to confuse with the standby traffic mode

Section 1.2 Terminology, fifth paragraph (Signalling Gateway definition):

"Where an SG contains more than one SGP, the SG is a logical entity and the
contained SGPs must be coordinated into a single management view to the SS7
network and to the supported Application Servers."

    This is not consistent with later text which describes that the
    ASP must maintain the reachability of routes on a per SGP basis.

    As far as the SS7 network is concerned, it may only be necessary
    to provide a single MTP management view towards the SS7 network
    if the SG actually provides its own point code.  In a "protocol
    conversion" implementation (where the SG has no separate point
    code of its own) it is not necessary to represent a single
    management view of the SG towards the SS7 network.  This text,
    however, says "must".

    As far as the Application Servers are concerned, from further
    text in the draft, it appears that the ASPs must keep track of
    the reachability of the SGPs and (as an option) may coordinate
    the state of the SGPs into a single view.  In this case, it
    appears that the ASPs are responsible for providing a single
    management view of the SG.  Again, this text says "must".

    This last sentence should be struck from the definition or
    "must" change to "could" or "might typically".

[Greg] Change is made - subject to continuing e-mail discussion.

Section 1.2 Terminology, seventh paragraph (Signalling Process definition):

    Grammar:

"Signalling Process - A process instance that uses M3UA to communicate with
other signalling process."

either "other signalling processes" or "another signalling process"

[Greg] Done

Section 1.2 Terminology, eigth paragraph (Routing Key definition):

"Parameters within the Routing Key cannot extend across more than a single
SS7 Destination Point Code."

    This statement is too restrictive as it precludes "alias" point
    codes at the AS/ASP.  Suggest the following rewording:

Parameters within the Routing Key cannot extend across more than a single
Signalling Point Management Cluster.

[Greg] Done.

Section 1.2 Terminology, eleventh paragraph (Signalling Point Management
Cluster definition):

"The complete set of Application Servers represented to the SS7 network
under one specific SS7 Point Code of one specific Network Appearance."

    Again, too restrictive and precludes a single signalling point
    being labelled with multiple "alias" point codes.  Suggest the
    following rewording:

The complete set of Application Servers represented to the SS7 network under
a single MTP entity (Signalling Point).

[Greg] Done

Section 1.2 Terminology, eleventh paragraph (Signalling Point Management
Cluster definition):

"SPMCs are used to sum the availability/congestion/User_Part status of an
SS7 destination point code that is distributed in the IP domain, for the
purpose of supporting MTP3 management procedures at an SG."

    Again, too restrictive and precludes a signle signalling point
    being labeled with multiple "alias" point codes but having a
    common set of MTP3 management procedures which apply to the
    signalling point.  Suggest the following rewording:

SPMCs are used to aggregate the availability, congestion and user part
status of an MTP entity (Signalling Point) that is distributed in the IP
domain, for the purpose of supporting MTP3 management procedures towards the
SS7 network.

[Greg] Done

Section 1.2 Terminology, eleventh paragraph (Signalling Point Management
Cluster definition):

"... In this case, the SG availability/congestion/User_Part status must also
be taken into account when considering any supporting MTP3 management
actions."

    The word "must" causes confusion with MUST.  Change "must" to
    "should" or "could".

[Greg] Changed to "should"

Section 1.2 Terminology, fifteenth paragraph (Network Appearance
definition):

"This partitioning is necessary where an SG is logically partitioned to
appear as end node elements in multiple separate SS7 networks, in which case
there is a separate network appearance for each point code in the SS7
networks."

    and

"It is also necessary when an SG is configured as an STP hosting multiple
point codes, or when configured as multiple end nodes within the same
network, in which case each point code is a separate network
appearance.between the SG and the Application Server Processes over a common
SCTP Association."

    This implies that separate network appearances are required for
    both multiple and "alias" point codes, meaning that a separate
    AS is required for each point code, even though the same set of
    MTP3 management procedures may apply to the entire set.
    Definitely this language is somewhat confusing.  Suggest
    something more like the following:

Network Appearance - The Network Appearance uniquely identifies one SS7
network of multiple disjoint SS7 networks in which an SPMC resides.

[Greg] It was an agreement on the list, and changed in Issue 7, to have
separate Network Appearances for each point code even if they could be
considered as in the same SG network partition.  Your above definition is
actually pretty close to the previous definition.  See the thread started by
Norm Glaude in January for a description.  It was agreed on the list to line
up the definitions between the SUA and M3UA

Section 1.2 Terminology, fifteenth paragraph (Network Appearance
definition):

"... A Network Appearance implicitly defines the SS7 Point Code(s), Network
Indicator and MTP3 protocol type/variant/version used within a specific SS7
network partition."

    "SS7 network partition" is certainly not what is meant here.
    The draft should refer to a "separate" or "disjoint" "SS7
    network", not a "partition" of an SS7 network.

[Greg] OK - "within a separate SS7 network" then.

Section 1.2 Terminology, eighteenth paragraph (Host definition):

"Host - The computing platform that the ASP process is running on."

    This also applies to the SGP.  Also, there is a implication
    throughout the document that a Host corresponds to a unique set
    of SCTP endpoints.  Also "ASP process" repeats the "process"
    designation.  Suggest the following:

Host - The computing platform that a process (SGP or ASP) is running on.

[Greg] Done.

Section 1.3.1 Protocol Architecture

    Second paragraph:

"Within the framework architecture, this document defines an MTP3-User
adaptation module suitable for supporting the transfer of messages of any
protocol layer that is identified to the MTP Level 3 layer, in SS7 terms, as
a user part."

    SS7 refers to these as 'MTP Users', not 'as a user part'.  Also,
    SS7 uses Levels, not layers, so "MTP Level 3 layer" is
    redundant.  Suggest the following rewording:

Within the framework architecture, this document defines an MTP3-User
adaptation module suitable for supporting the transfer of messages of

[Greg] Your proposal is missing here  2:^0   I changed it to:

"Within the framework architecture, this document defines an MTP3-User
adaptation module suitable for supporting the transfer of messages of any
protocol layer that is identified to the MTP Level 3 as an MTP User."

Section 1.3.1 Protocol Architecture

"- Sequenced delivery of user messages within multiple streams, with an
option for order-of-arrival delivery of individual user messages,"

    M3UA does not utilize order-of-arrival delivery and this aspect
    of SCTP cannot be taken avantage of by using SCTP as a transport
    for M3UA.

[Greg] Some SSNM messages are allowed to be sent unsequenced (DAUD, SCON?).
If they are sent unsequenced I assume that this feature would be used.

Section 1.3.1 Protocol Architecture

"- Optional multiplexing of user messages into SCTP datagrams,"

    It is not clear how M3UA can utilize this optional feature of
    SCTP.

[Greg] An SCTP User can request bundling, which I assume is what is meant by
multiplexing here.  The M3UA doesn't state when to use bundling but it could
use it.  I assume this would be an operational decision, not a protocol
decision.

Section 1.3.1 Protocol Architecture

"- Network-level fault tolerance through support of multi-homing at either
or both ends of an association,"

    SCTP multi-homing can be used by a specific implementation and a
    specific configuration to support network-level fault tolerance,
    but SCTP does not provide this in itself.  M3UA does not get
    network- level fault tolerance merely by using SCTP as a
    transport, nor necessarily by merely using SCTP's multi-homing
    feature.

[Greg] This is just a lshort isting of an SCTP feature - directly from the
SCTP spec.  Yes there are configuration and implementation decisions to make
it work but I don't hink it is necessary to describe that here.

Section 1.3.1 Protocol Architecture

"Under certain scenarios, such as back-to-back connections without
redundancy requirements, the SCTP functions above MAY NOT be a requirement
and TCP can be used as the underlying common transport protocol."

    Should an implementation support TCP as well?

[Greg] No recommendation is made - it is up to the implementor.  The
sentence just "allows" some implementations to use TCP if they like.

Section 1.3.2

"The M3UA layer does not itself provide the MTP3 services.
However, in the case where an ASP is connected to more than one SGP, the
M3UA layer at an ASP must maintain the status of configured SS7 destinations
and route messages according to the availability and congestion status of
the routes to these destinations via each SGP."

    In this text "SG" from version 6 has been changed to "SGP" in
    version 7.  This has the negative impact that this text requires
    that when the ASP is connected to more than one SGP, the ASP is
    required to maintain SS7 routing information on a per-SGP basis
    rather than a per-SG basis.  Although both cases are valid, it
    represents a significant departure from the version 6 model.

[Greg] Yes but this was as agreed on the list.  There is a thread on the
list revisiting this so I will defer to the thread on the list.

    For example, what does an SGP do with tranfer messages for which
    it has no route?  In the version 6 situation, it is clear that
    if the SG has a route, the SGP either deals with messages for
    that route (or take itself out of service).  Now it is not so
    clear.

[Greg] Sorry I'm not following this example.

    Also, the "must" here means what?  Does it mean MUST?

[Greg] probably should be a MUST or SHOULD, depending on the outcome of the
thread on the list

Section 1.3.2.1

"The MTP-TRANSFER primitive information is encoded as in MTP3-User messages.
In this way, the SCCP and ISUP messages received from the SS7 network by the
SGP are not re-encoded into a different format for transport between the
M3UA peers.  The MTP3 Service Information Octet (SIO) and Routing Label
(OPC, DPC, and SLS) are included, encoded as expected by the MTP3 and
MTP3-User protocol layer."

    As discussed on the list, many MTP-User interfaces pass routing
    label information as parameters, which must then be "re-encoded"
    at the SG before transport to the ASP and "re-decoded" at the
    ASP to pass to the MTP-User.  This issue has not yet been
    addressed.

[Greg] I'll leave this to conclude on the list - I may be slow but so far I
don't see a consensus.

Section 1.3.2.1

"At an ASP, in the case where a destination is reachable via multiple SGPs,
the M3UA layer must also choose via which SGP the message is to be routed or
support load balancing across the SGPs, ensuring that no missequencing
occurs."

    M3UA in its current trim does not support the requirement that
    the ASP ensure that "no missequencing occurs".  Also, no
    procedure is given in M3UA to select an SGP from multiple SGPs
    for which the destination is available.  The management of SGPs
    at he ASP is an outstanding and significant issue.

[Greg] Well we need a proposal then.  I assume some part of this falls out
from the SG/SGP thread on the list (SG versus SGP view for SSNM messaging).
I assume that the SLS is used just like in MTP3 for link selection, taking
into account the remote SGP availability status.  And I agree with your
point on the list about the need for controlled rerouting.  The implementors
I have talked to seem to understand this but we probably need a section to
describe this.  I don't really want to get into re-interpretting MTP3
procedures though - maybe we could provide a set of guidelines instead?

Section 1.3.2.1

"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."

    This is also true for Q.703 Annex A operation which is cited as
    only supporting 272-octets as cited in [14] at the beginning of
    this paragraph.  Citing specific SS7 refererences here is of
    little use as the need for M3UA to respect maximum SIF sizes
    depends upon the implementation and the network configuration.

[Greg] I understand but I'm not sure what you would like changed - you want
to remove the refernce to MTP3b?

Section 1.3.2.2

"The M3UA layer provides management of the underlying SCTP transport
protocol to ensure that SGP-ASP and IPSP-IPSP transport is available to the
degree called for by the MTP3-User signalling applications."

    The M3UA layer provides no such thing.  It has no procedures to
    ensure the availability to the levels expected by the MTP3-User
    as quantified in the SS7 specifications.

[Greg] Yes - this is strange text.  M3UA can't ensure SCTP performane.  I'll
strike it.

Section 1.3.2.3

"At the SGP, the M3UA layer must also provide inter-working with MTP3
management functions to support seamless operation of the user SCN
signalling applications in the SS7 and IP domains."

    This statement places a requirement (or an objective) on M3UA.
    It is arguable whether M3UA can "support seamless operation fo
    the user SCN signalling applications in the SS7 and IP domains".

[Greg] Like you say, it is a requirement or objective - time will tell if we
are successful

Section 1.3.2.3

"- Providing an indication to MTP3-Users at an ASP that a
   remote destination in the SS7 network is not reachable.

- Providing an indication to MTP3-Users at an ASP that a
   remote destination in the SS7 network is now reachable.

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

- Providing an indication to the M3UA layer at an ASP that
   the routes to a remote destination in the SS7 network are
   restricted.

- Providing an indication to MTP3-Users at an ASP that a
   remote MTP3- User peer is unavailable.

    The words "remote destination" here is confusing.  A local or
    adjacent destination can also become unreachable and can also
    experience congestion.

[Greg] I removed "remote" - assuming that helps.

Section 1.3.2.4

"The M3UA layer at the SGP maintains the availability state of all
configured remote ASPs, in order to manage the SCTP Associations and the
traffic between the M3UA peers.  As well, the active/inactive and congestion
state of remote ASPs is maintained."

   SG changed to SGP has different meaning here.  Now it appears
   that it is each SGP's responsibility to maintain the state of all
   remote ASPs.  It also means that an ASP can be active for one SGP
   and inactive for another.  Although not necessarily incorrect,
   this is substantially different from the version 6 text.

[Greg] Yes.  I'm not sure that an SGP would have a different view than other
SGPs of the active/inactive state of an ASP - except maybe in a transitory
sense.

Section 1.3.2.4

"...M3UA configuration knowledge maintained to detect redundant..."

    Nit pick: should read "M3UA configuration information".

[Greg] Done

Section 1.3.2.4

"... This may be achieved using the M-ASP_request or M-AS_STATUS request
primitives. ..."

    Nit pick: should read "This MAY be achieved..."

[Greg] Done

Section 1.3.2.4

"As shown in Figure 1 an ASP may be connected to multiple SGPs. In such a
case a particular SS7 destination may be reachable via more than one SGP,
i.e., via more than one route."

    Changing SG to SGP here has consequences for the implementation
    as discussed above.

[Greg] Yes.

Section 1.3.3

"... However, the conjunction of distributed architecture and redundant
networks does allow for a sufficiently reliable transport of signalling
traffic over IP."

    "[S]ufficiently reliable" here is highly subjective.

[Greg] Yes it is subjective.  How about "should" instead?

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."

    Operators may require SGs (as they often require STPs) to be
    "loss-less" in that a single failure will not result in the loss
    of a message.  M3UA does not support this.

[Greg] Well, I've been around this a few times with various people.  I'm not
sure if there is an expectation of lossless SGs (is this a real word?) but
there is an expectation of meeting the performance and reliability
requirements end-to end with SGs in the path..

Section 1.3.3

"and SGPs within the available Hosts SHOULD also be considered. ..."

    Nit pick:  "SHOULD also be considered" and "MAY also be
    considered" and "MUST be considered" are really the same thing.
    There is no way of enforcing a consideration.  Therefore, "MAY"
    is more appropriate.

[Greg] Done

Section 1.3.3

"As an example, for a particular Application Server, the related ASPs SHOULD
be distributed over at least two Hosts."

    Nit pick:  "SHOULD" inside an example qualitified with
    "particular" but left unspecified has no weight.  Therefore,
    "MAY" is more appropriate.

[Greg] I'm certainly no english major - you really lost me there  2;^)
Anyway I think that a change to MAY weakens the statement too much - maybe
the problem is with "As an example" or "particular"?

Figure 1:

    What was the purpose of removing SG1 and SG2 from the figure?

[Greg] It implied that an SG was a physical thing implemented on a single
host - this might not always be the case.  An SG could be a logical thing
formed from SGP1/Host1 and SGP1/Host2.

Section 1.3.3

"A pair of signalling gateway processes may represent, as an example, a
single Signalling Gateway, serving a signalling point management cluster."

   This is less clear than the previous text with regard to the
   multiple SG arrangement diagrammed.  A "pair of SGP" has no
   significance over "n SGPs".  The configuration with multiple SG
   *is* significant.

[Greg] The only change here was to "Signalling Gateway" from "network
appearance", which Ian and I thought didn't made sense.  How is this less
clear?

Section 1.3.3

"This message distribution function is based on the status of provisioned
routing keys, the availability of signalling points in the SS7 network, and
the redundancy model (active-standby, load-sharing, n+k) of the remote
signalling processes."

    The message distribution function is not strictly dependent on
    "the availability of signalling points in the SS7 network".  The
    message distribution function *is* strictly dependent on the
    status of signalling routes (via the SGP in V7).

[Greg] Changed to " the status of signalling routes to signalling points in
the SS7 network, ...""

Section 1.3.3

"For carrier grade networks, the failure or isolation of a particular
signalling process SHOULD NOT cause stable calls or transactions to be lost.
This implies that signalling processes need, in some cases, to share the
call/transaction state or be able to pass the call state information between
each other.  In the case of ASPs performing call processing, coordination
may also be required with the related Media Gateway to transfer the MGC
control for a particular trunk termination.  However, this sharing or
communication of call/transaction state information is outside the scope of
this document."

    A "SHOULD NOT" implying something which is "outside the scope of
    this dcoument" has no weight.  This "SHOULD NOT" does not speak
    to the interoperability of M3UA, but addresses something out of
    scope.  It is really not the place of this document to specify
    what operators should or should not require with regards to
    stable calls or transactions.

[Greg] True, but this was a historical requirement from Operators on the
system (SG/MGC/MG) and describes at a high level what has to be done to meet
it.  Although it really falls to the inter-ASP communication to ensure this,
I think the information is still useful.  The SHOULD NOT probably shouldn't
be capitalised.

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."

    The mapping of Network Appearances and SPMCs to point codes does
    restrict the distribution algorithms and the distribution of
    signalling processes.

[Greg] IMHO it is interconnecting to SS7 that imposes these "restrictions"
2;^)

Section 1.4.1

"... The SG Point Code might also used for "

    Grammar:  should read "The SG Point Code might also be used
    for".

[Greg] Done.

Section 1.4.1

"The SG Point Code might also used for addressing any local MTP3-Users at
the SG such as an SG-resident SCCP function."

    This implies that a set of routing keys or routing contexts can
    also be "local" to the SG.  When an ASP goes to register or
    perform an ASPAC against one of these "local" routing keys, how
    does the SG treat this?  It appears that the SG would have to
    keep track of the state of these "local" ASPs as well...  How
    does M3UA support this local ASP management?  The example, while
    interesting, is confusing.

[Greg] I'm not sure why an ASP would try to register to receive SCCP traffic
for the SG's local SCCP layer.  Even if it was allowed, any messages
received from the SS7 network would not see the light of day on the M3UA
side.

Section 1.4.1

"An SG may be logically partitioned to operate in multiple SS7 network
appearances.  In such a case, the SG must be addressable with a Point Code
in each network appearance, and represents a set of nodes in the IP domain
into each SS7 network. ..."

    This "must" is too restrictive.  Certainly a
    "protocol-conversion" approach (without an SG point code) is as
    valid across multiple network appearances as it is in one.
    Change the "must" to "could".

[Greg] OK

Section 1.4.1

"Alias Point Codes [15] may also be used within an SG network appearance."

    This assertion is false due to the previous discussion on
    routing keys not spanning SPMCs (which are defined as point
    codes).  Changing the SPMC definition (as proposed above) would
    strengthen this assertion.

[Greg] I'm not sure why an SG would maintain an SPMC for an alias point
code.  I thought that the SG (or any SS7 node using an alias PC) would not
generate any MTP management messages (e.g., TFPs, TFAs) about the alias PC.
The alias PC is only used in the MTP discrimination function.

Section 1.4.1

"Where an SG contains more than one SGP, the MTP3 routeset, SPMC and remote
AS/ASP states of each SGP SHOULD be coordinated across all the SGPs.
Re-routing of traffic between the SGPs SHOULD also be supported"

    Gramar: missing period at end of second sentence.

    What is the purpose of adding this paragraph?  This attempts
    again to impose requirements on the SG/SGP implementation (and
    to what end?) What does one SGP care about what another SGP's
    view of the state of an ASP which is only active with another
    SGP?

[Greg] Not sure I follow - I thought we agreed that SGPs in an SG need to
share state?  I think the SG cares about the state of the SGPs as it needs
to put together an aggregate view.

Section 1.4.1

"The M3UA places no restrictions on the SS7 Point Code representation of an
AS."

    M3UA places the restriction that an AS cannot represent a point
    code and a set of alias point codes.  Redefinition of the
    Network Appearance and SPMC is required to permit this
    representation.

[Greg] Yes there are restrictions - I'll strike this sentence.

Section 1.4.1

"If an ASP or group of ASPs is available to the SS7 network via more than
one SG, each with its own Point Code, the ASP(s) should be represented by a
Point Code that is separate from any SG Point Code."

    The "should" in this text attempts to place a restriction on SG
    implementation and network configuration.  If multiple SGs are
    capable of representing an AS as sharing one of the SG's point
    codes, it should be permitted.

    Also, there is nothing precluding a multiple SG approach where
    each SG represents an A-link in an A-linkset and the SG acts in
    "protocol conversion" mode between the SS7 network and the ASP.
    In this case, the SGs don't need point codes at all...

    Change "should" to "might" or "will typically"

[Greg] Done

Section 1.4.1

"This allows these SGs to be viewed from the SS7 network as "STPs", each
having an ongoing "route" to the same ASP(s)."

    Associated STPs are permitted to have "local" MTP-Users which
    may be represented by a single AS in multiple ASP(s).  This
    accents the error in the previous restriction.  These are all
    examples and must not place requirements on the SG
    implementation or network configuration.

[Greg] I added the phrase "for example" - "This allows, for example, these
SGs to be viewed ..."

Section 1.4.1

"Under failure conditions where the ASP(s) become(s) unavailable from one of
the SGs, this approach enables MTP3 route management messaging between the
SG and SS7 network, allowing simple SS7 re-routing through an alternate SG
without changing the Destination Point Code Address of SS7 traffic to the
ASP(s)."

    This is the slippery slope of specifying the NIF again.  This
    approach must be completely optional.

[Greg] I'm not sure how this relates to the NIF?  Anyway it has been wekend
by the previous changes to an example.

Section 1.4.1

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

    s/SG/SGP/g here has an impact.  Suddenly each SGP must have the
    same routing keys and the associated SGs do not?  Why is it
    important anyway?  Just the statement that it is "important" is
    not a sufficient description of the situation.

[Greg] If all the SGPs routing to an AS have the same Routing Keys, then any
associated SGs are fine by definition - I'm not seeing your point.   Saying
it is important is a bit odd I grant you.  Probably "the Routing Keys in the
involved SGPs should be identical" is probably what was originally meant.

Section 1.4.1

"* Note:.  SG-to ûSG communication is recommended for carrier grade
networks, using an MTP3 linkset or an equivalent, to allow re-routing
between the SGs in the event of route failures.  Where SGPs are used,
inter-SGP communication is recommended.  Inter-SGP protocol is outside of
the scope of this document."

    Why can't you bring yourself to draw C-links?  They are a
    standard part of the SS7 signalling network in quasi-associated
    mode.  When you label the boxes "STP" you must draw C-links or
    you will cause confusion.

[Greg] C-links are there, honest! - I tried a line between the SGs with an
asterisk to point to the note and it just looked dumb.  I didn't have time
to redraw the ASCII diagram so I just left the asterisk there by itself.  I
can redraw the digram so there is a longer line later.

    In the note, it is not the place of the M3UA spec to make
    recommendations to SS7 network operators with regard to the use
    (or not) of C-links.  Also, what "equivalent" are you implying?

[Greg] SG-toSG and SGP-toSGP communication is recommended in the note -
could be MTP2, M2PA, SSCOP/ATM, ...  If this is too strong I can downgrade
it.  When nothing was shown in previous versions, I got complaints that a
link had to to be there.  When I put it in now and say it should be there
I'm told I shouldn't say it.  We can't have it both ways.

    Again, the draft recommends something (inter-SGP communication)
    which is outside the scope of the document.  The draft should
    not do this because it results in a restriction (at least a
    should) placed on implementation specifics.  At least downgrade
    "SHOULD" to "MAY" and "recommended" to "might be used".

[Greg] I honestly think it is useful to show the connectivity between the
SGs or SGPs even if it the protocol used is outside the scope of this
document.  "may" or "might' seems pretty weak to me.

Section 1.4.2.1

"The distribution of SS7 messages between the SGP and the Application
Servers is determined by the Routing Keys and their associated Routing
Contexts."

    The SGP distributes messages to ASP(s), not to AS(s).  The SGP
    may select an ASP within an AS based on routing key/context.

[Greg] Sorry, I'm not following this.  The Routing Key determines the AS and
RC.  Not sure what is wrong with "distribution" - where there are multiple
Application Servers the traffic is "distributed" among them.  Is there
another word you are more comfortable with?

Section 1.4.2.1

"Possible SS7 address/routing information that comprise a Routing Key entry
includes, for example, the OPC, DPC, SIO found in the MTP3 routing label, or
MTP3-User specific fields such as the ISUP CIC, SCCP subsystem number, or
TCAP transaction ID."

    TCAP transaction ID is not an MTP-User specific field: it is an
    SCCP-User specific field.

[Greg] OK.  I put brackets in to make this clearer:  "or MTP3-User specific
fields (such as the ISUP CIC, SCCP subsystem number) or TCAP transaction
ID."

Section 1.4.2.2

"Routing Keys SHOULD be unique in the sense that each received SS7
signalling message SHOULD have a single routing result to an Application
Server."

    This "SHOULD" is not consistent with the concept of a "default
    AS".  In the case of a default AS, every routing key has two
    results: one in the case that the AS is available and the other
    (default) in the case that the AS is unavailable.  The "SHOULD"
    should be removed and this text made an example only.

[Greg] Which SHOULD should be removed?   2;^)

Section 1.4.2.2

"At an ASP, the Routing Context parameter uniquely identifies the range of
signalling traffic associated with each Application Server that the ASP is
configured to receive."

    But the Routing Context parameter is not included with DATA
    messages and it is therefore not possible for the ASP to
    discriminate traffic by routing context without reapplying the
    routing key "filter".  As the filter has already been applied by
    the SGP in the case of DATA messages from SGP to ASP, it seems
    pointless that the ASP should then again (and perhaps
    erroneously) apply the routing key filter to discriminate
    traffic.  Routing Context should be included as a mandatory
    parameter in DATA messages and Network Appearance removed.

[Greg] I really don't have problem with putting the RC in a Data message.
I'm not sure that an ASP always needs a RC though - all the traffic for
could be going to the same MTP SAP.   No need to apply a filter there.  I
guess this is discussed in the thread so I'll leave it to conclude there.

Section 1.4.2.2

"A Routing Key may be configured statically using an implementation
dependent management interface, or dynamically using the M3UA Routing Key
registration procedure.  A Routing Key may also be configured using the M3UA
dynamic registration/deregistration procedures defined in this document."

    The second sentence is redundant.

[Greg] OOPs!

Section 1.4.2.2

"An M3UA element must implement at least one method of Routing Key
provisioning."

    If an M3UA element wants to implement the null function why not
    let it?  Or, if the M3UA element wants to hardwire the routing
    keys and not provide a "management interface", why not let it?
    An M3UA element might not require a "provisioning" method.
    Certainly, provisioning systems and management interfaces are
    outside the scope of the document.

[Greg] Deleted.

Section 1.4.2.4

"To support this message distribution, the SGP must maintain the equivalent
of a network address translation table, ..."

    The draft should not place restrictions on the SGP
    implementation.  Change "SGP must maintain" to "SGP MAY
    maintain" or "SGP might, for example, maintain".  Change "This
    is accomplished" to "This could be accomplished".  Change "in
    turn make reference" to "could in turn make reference".

[Greg] Done

Section 1.4.2.4

"When there is no matching Routing Key entry for an incoming SS7 message, a
default treatment SHOULD be specified."

    This attempts to define the NIF.  Downgrade "SHOULD" to "MAY".
    Again, there is no reason to impose a "SHOULD" restriction on an
    implementation dependent mechanism.  The "default" treatment
    could be to ignore messages in all such situations.  Further,
    the "SHOULD" does not speak to interoperability between M3UA
    peers.

[Greg] Done

Section 1.4.2.4

"In order to direct messages to the SS7 network, the ASP must also perform a
message distribution function in order to choose the proper SGP for a given
message."

    Gramar:  change both occurences of "in order to" in this
    sentence with (simply) "to".  Actually, why not:

The ASP must choose an SGP to direct a message to the SS7 network.

[Greg] Done

Section 1.4.2.4

"Where more than one route (or SGP) is possible for routing to the SS7
network, the ASP SHOULD maintain a dynamic table of available SGP routes for
the SS7 destinations, taking into account the SS7 destination
availability/restricted/congestion status received from the SGP(s), the
availability status of the individual SGPs and configuration changes and
fail-over mechanisms."

    What does the "SHOULD" apply to?  Maintaining the table?  Taking
    into account destinations status?  Configuration changes?  All
    of the above?  How the ASP goes about choosing is implementation
    dependent as it stands in the draft.  The draft need not impose
    how the ASP goes about choosing down to recommending dynamic
    tables.  Change "SHOULD" to "could, for example," and label the
    whole paragraph as an IMPLEMENTATION NOTE.

[Greg] Done.

Section 1.4.2.4

"There is, however, no M3UA messaging to manage the status of an SGP (e.g.,
SGP-Up/Down/Active/Inactive messaging).
Whenever an SCTP association to an SGP exists, the SGP is assumed to be
ready for the purposes of responding to M3UA ASPSM messages.

Every SGP of one SG ASP regarding one AS provides identical SS7 connectivity
to this ASP."

    This is an issue which has been discussed a fair amount on the
    list.  These to restrictions placed on the SG/SGP implementation
    are unworkable from an number of views.

    It is clear that it cannot be the case that the SGP are treated
    as completely equal.  An SG implementation with multiple SGP
    will likely require that the ASP choose the SGP in a determinate
    fashion.  It is reasonable to assume that an SGP will expect
    only symmetrical traffic from an ASP for the Routing Key for
    which the ASP has become active.

[Greg]  The draft doesn't say that the SGPs are treated equally, only that
they provide equivalent connectivity to the SS7 network.  I'm also not
convinced yet that the traffic has to be symmetrical.

    In the first sentences, the SGP cannot be considered to be ready
    to accept SS7 traffic before the ASP has even registered.
    Therefore, it is not just the availability of the SCTP
    association which determines whether an SGP is available.

[Greg] It just says it is ready to accept ASPSM messages (ASP-Up/Down).  I
don't see you point

    Further, the last sentence quoted above is in direct conflict
    with other statements in the draft which indicate that the ASP
    must maintain the availablity and congestion of route set on a
    per-SGP basis.  Therefore, it is possible that that ASP cannot
    treat the SGP as providing "identical SS7 connectivity".

[Greg] I think you are reading too much into the term "connectivity".  Bing
connected doesn't mean you are sending traffic.

Section 1.4.2.4

"Note: It is also possible for IP-based interfaces to be present, using the
services of the MTP2-User Adaptation Layer (M2UA) [23] or M2PA [].

    Missing reference for M2PA.

[Greg] OOPs

Section 1.4.2.4

"These may be terminated at a Signalling Transfer Point (STP) or Signalling
End Point (SEP)."

    Change "may" to "could".  It is not the place of the draft to
    "give permission" for this configuration.

[Greg] Done

Section 1.4.2.4

"Using the services of MTP3, the SG may be capable of communicating with
remote SS7 SEPs in a quasi-associated fashion, where STPs may be present in
the SS7 path between the SEP and the SG."

    Change both instances of "may" to "could".  It is not the place
    of the draft to "give permission" for this configuration.

[Greg] Done

Section 1.4.3.2

"The Signalling Gateway must maintain knowledge of relevant SS7 node and
Signalling Point Management Cluster (SPMC) status in their respective
domains in order to perform a seamless inter-working of the IP-based
signalling and the SS7 domains.  For example, SG knowledge of the
availability and/or congestion status of the SPMC and SS7 nodes must be
maintained and disseminated in the respective networks, in order to ensure
that end-to-end operation is transparent to the communicating SCN protocol
peers at the SS7 node and ASP.  Where more than one SGP constitutes an SG,
the knowledge of the SGPs must be coordinated into an overall SG view."

    This is extremely awkward after s/SG/SGP/g.  The text talks of
    "SG knowledge" (bad word usage) and then says that "the
    knowledge of the SGPs" must be coordinated.  This is so
    confusing, I don't know what the draft is trying to say here.
    Perhaps it would be sufficient to say:

The SGPs, as subsystems of an SG, are responsible for performing
interworking between the SS7 and IP networks.

[Greg] I think it is better to delete it.

    Furthermore, there are possible implementations ("protocol
    conversion" approaches) which are stateless and rely on the
    state of the subtending ASPs to reflect the state of the SPMC.
    In this case, the SGP would need to have no "knowledge" of the
    SPMC status, yet still achieve seamless interworking.  Each
    "must" in the quoted paragraph should be changed to "may".

[Greg] You have mentioned these "possible implementations" several times -
I'm curious whether anybody is really implementing this?  If not it may not
useful to try and accomodate them.

Section 1.4.3.2

"(These indication primitives are also made available to any existing local
MTP3-Users at the SG, if present.)"

    This is completely within the realm of the SS7 specifications
    and specific to an SG implementation.  I propose that it be
    stricken.

[Greg] Gone.

Section 1.4.3.2

"MTP3 management messages (such as TFPs or TFAs received from the SS7
network) MUST NOT be encapsulated as Data message Payload Data and sent
either from SG to ASP or from ASP to SG.  The SG MUST terminate these
messages and generate M3UA messages as appropriate."

    This "MUST" and "MUST NOT" is too restrictive.  MTP3 management
    messages which are for point codes other than that of the SG or
    an SPMC might be sent as DATA messages to the ASP.  Is there a
    reason to preclude the ASP from performing the "transfer
    function"?

[Greg] Brian, you proposed this text for Issue 7, so maybe you can tell me
2;^)

    Also, when there are multiple SGs, there is the issue of how the
    SG is supposed to perform changeback on behalf of the SPMC when
    it cannot be guaranteed that the CBD has arrived at the SPMC
    before responding with a CBA.  Also, there is the issue of
    changeover at the ASP in the case that there are multiple
    SG/SGPs.

[Greg] I'm not sure what these issues have to do with this text you quoted

Section 1.4.3.3.

"As an example, an SPMC providing MGC capabilities must provide complete
support for ISUP (and any other MTP3 user located at the point code of the
SPMC) for a given point code, according to the local SS7 network
specifications."

    Change "must provide" to "could provide".  "according to the
    local SS7 network specifications" adds no value to the sentence
    and should be removed.

[Greg] Done.

Section 1.4.3.3.

"This measure is necessary to allow the SG to accurately represent the
signalling point on the local SS7 network."

    Which measure?

[Greg] Deleted

Section 1.4.3.3.

"In the case where an ASP is connected to more than one SGP, the M3UA layer
must maintain the status of configured SS7 destinations and route messages
according to availability/congestion/restricted status of the routes to
these SS7 destinations."

    Is this a s/SG/SGP/g error?  Is it required that the ASP keep
    track of these things when there is only one SG (but multiple
    SGP)?  Also, which M3UA layer must maintain this information?
    The one on the ASP?

[Greg] The M3UA layer at the ASP.  I think per agreement in Issue 7 it
should be SGP.  I think this is subject to the e-mail discussion results

Section 1.4.3.3.

"The network address translation and mapping function of the M3UA layer
supports signalling process fail-over functions in order to support a high
availability of call and transaction processing capability."

    Gramar: change "in order to" to simply "to".

    So, the draft says that two largely unspecified functions
    support a function which supports high availability of a
    processing capability.  This is so vague it really means
    nothing.  Remove it.

[Greg] Done

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."

    This statement is too broad and is in error.  The SG certainly
    has some messages which come from the SS7 network which will not
    be assigned to an Application Server.  This is the case for
    "local" MTP-Users (which is mentioned previously in the draft)
    and for mangement messages which are destined for an SG's point
    code which is not part of the SPMC of any AS.

    A correct statement would be:

MTP3-User messages (e.g., ISUP, SCCP) which match a provisioned Routing Key
at an SGP are mapped to an Application Server.

[Greg] OK

Section 1.4.4.1

"The Application Server is, in practical terms, a list of all ASPs
configured to process a range of MTP3-User traffic defined by one Routing
Key.  One or more ASPs in the list are normally active (i.e., handling
traffic) while any others may be unavailable or inactive, to be possibly
used in the event of failure or unavailability of the active ASP(s)."

    Even in logical terms this is true; however, if the draft would
    use the word "set" instead "list" there would be no confusion
    with an implementation directive.  That is:

The Application Server is the set of all ASPs associated with a specific
Routing Key.  Each ASP in this set may be active, inactive or unavailable.
Active ASP handle traffic; inactive ASPs might be used when active ASPs
become unavailable.

etc....

[Greg] Done.

Section 1.4.4.1

"To avoid a single point of failure, it is recommended that a minimum of two
ASPs be in the list, resident in separate hosts and therefore available over
different SCTP Associations."

    ASP implementation is implementation specific.  Who says that a
    single ASP is a single point of failure?  For example, on a
    fault-tolerant processor, a single ASP might not represent a
    single point of failure.  Also, who says that a host represents
    a single point of failure?  Again, a hardware fault-tolerant
    host need not represent a single point of failure.

    This recommendation presupposes an ASP implementation and should
    be struck.

[Greg] OK

Section 1.4.4.1

   "Routing Key {DPC=x) - "Application Server #1" ASP1/Host3  - State =
Active
ASP1/Host3  - State = Inactive"

    The second Host3 should be "Host4" to agree with the text.

[Greg] Good catch

Section 1.4.4.1

"Care must be exercised by a Network Operator in the selection of the
routing information to be used as the Routing Key for a particular AS.  For
example, where Application Servers are defined using ranges of ISUP CIC
values, the Operator is implicitly splitting up control of the related
circuit groups.  Some CIC value range assignments may interfere with ISUP
circuit group management procedures."

    Change "Care must be" to "Care might need to be".  Certainly it
    is no more difficult for a group of ASPs to synchronize circuit
    group state than it is for them to synchronize call state.  It
    may not be necessary for a network operator to give any
    consideration whatsoever to the matter of routing key assignment
    (providing even that the network operator has any control over
     routing key assignment at the sub-circuit-group level).  Here,
    again, the draft makes assertions and recommendations concerning
    items which are clearly out of scope.

[Greg] Done

Section 1.4.4.1

"In the process of fail-over, it is recommended that in the case of ASPs
supporting call processing, stable calls do not fail.  It is possible that
calls in "transition" MAY fail, although measures of communication between
the ASPs involved can be used to mitigate this.  For example, the two ASPs
MAY share call state via shared memory, or MAY use an ASP to ASP protocol to
pass call state information.  Any ASP-to-ASP protocol to support this
function is outside the scope of this document.

    Why not?  This presumes that this is an application requirement.
    A network operator other than a regulated carrier might not care
    if some number of stable calls fail.  This recommendation is out
    of scope.  In many places in the draft, the draft makes such a
    recommendation followed by the statement that it is out of
    scope.  Out of scope recommendations should be removed or
    converted to examples.

[Greg] As I stated before in a different way, I honestly think it is OK to
make recommendations about things that are out of scope of the protocol when
they have an impact on the system and help explain how Operator requirements
can be met.

Section 1.4.4.2

"Signalling Gateways MAY also be distributed over multiple hosts.  Much like
the AS model, SGs may comprise one or more SG Processes (SGPs), distributed
over one or more hosts, using an active/back-up or a load-sharing model."

    How does an ASP determine which of multiple SGPs to select?  How
    does an ASP determine whether multiple SGPs are active/back-up
    or load-sharing or some other algorithm?

[Greg] Configuration management

Section 1.4.4.2

"Should an SGP lose all or partial SS7 connectivity and other SGPs exist,
the SGP SHOULD terminate the SCTP associations to the concerned ASPs."

    Given the current requirements that an SGP provide "identical"
    SS7 connectivity, I don't understand why this "MUST" was
    downgraded to a "SHOULD".  The ASP currently has no other
    mechanism to determine whether an SGP is active or not.

[Greg]  I really don't think terminating the SCTP association is always a
good idea if the SGP can still reroute via other SGPs in the SG.  If it
can't do that then MUST seems to fit.

Section 1.4.4.2

"From the perspective of the M3UA layer at an ASP, a particular SG is
capable of transferring traffic to an SS7 destination if an SCTP association
with at least one SGP of the SG is established, the SGP has returned an
acknowledgement to the ASP to indicate that the ASP is actively handling
traffic for that destination, and the SGP has not indicated that the
destination is inaccessible."

    There is a confusion between the destinations referred to in
    this text.  It is not clear whether the text is talking about a
    destination other than the ASP SPMC or whether the text is
    talking about the ASP SPMC.  The text seems to mix both in the
    same sentence, which is confusing.  Also, this text does not
    explicitly take MTP restart into consideration.

[Greg] Sorry, I don't see the confusion yet.  I'm not sure how MTP Restart
would make difference here - I hae to think about that one.

    For security reasons and in consideration of gateway screening
    at the SG, it might not be advisable for the ASP to consider all
    SS7 destinations as accessible by default: only those
    destinations to which it has a route.

[Greg] Again, I'm not sure I follow this -  Maybe it is too obvious  2;^).

Section 1.4.5

    It is necessary to permit the SGP to temporarily remove traffic
    from an association also.

[Greg] I thought it could - although I think it is better for the ASP to
stop traffic by sending an ASP-Inactive.

Section 1.4.6

"The M3UA layer at an ASP or IPSP should indicate local congestion to an
..."

    Change "should" to "MAY".

[Greg] Done

Section 1.4.6

"... that requires sequencing must be assigned to the same stream."

    Change "must" to "SHOULD".

[Greg] Done

Section 1.4.6

"The use of SCTP streams within M3UA is recommended in order to minimize
transmission and buffering delays, therefore improving the overall
performance and reliability of the signalling elements.  The distribution of
the MTP3 user messages over the various streams should be done in such a way
to minimize message mis-sequencing, as required by the SS7 User Parts."

    Recommendations regarding delays, performance and reliability
    should be in a separate AS document.  Strike this text.

[Greg] OK

Section 1.5.1

    The diagram shows the NIF as being above the MTP3 interface and
    above a (non-specified) M3UA interface.  This does not
    correspond to the text which requires that the NIF interact with
    MTP routing functions and even interact with SCTP at the
    management level.  It would be more accurate to show the NIF as
    between the stacks as follows:

  ********   SS7   *****************   IP   ********
  * SEP  *---------*      SGP      *--------* ASP  *
  ********         *****************        ********

  +------+       +-------------------+      +------+
  | ISUP |       |                   |      | ISUP |
  +------+       +------+ NIF +------+      +------+
  | MTP3 |       | MTP3 |     | M3UA |      | M3UA |
  +------|       +------+-+   +------+      +------+
  | MTP2 |       | MTP2 |  \  | SCTP |      | SCTP |
  +------+       +------+   +-+------+      +------+
  |  L1  |       |  L1  |     |  IP  |      |  IP  |
  +------+       +------+     +------+      +------+
      |_____________|             |____________|

    SEP - SS7 Signalling End Point
    SCTP - Stream Control Transmission Protocol
    NIF - Nodal Inter-working Function

[Greg] OK.  Not sure about the NIF interacting with the SCTP at the
management level though.

Section 3.1.2

         "4        SS7 Network Congestion (SCON)"

    SS7 Network Congestion is no longer a good description.  This
    message is also used to indicate nodal congestion at the ASP.

[Greg] Do you have a more decriptive name?

Section 3.3.1 Payload Data Message, Network Appearance, second paragraph:

"In a DATA message, the Network Appearance implicitly defines the SS7 Point
Code format used, the SS7 Network Indicator value, and the MTP3 and possibly
the MTP3-User protocol type/variant/version used within the SS7 network
partition.  ..."

    Again, "SS7 network partition" cannot possibly be what is meant
    here.  Although the SG can be partitioned, it is partitioned
    over multiple separate or disjoint (complete) SS7 networks.
    Change "SS7 network partition" to "specific SS7 network".

[Greg] Done.

Section 4.3.1 At an SGP, second paragraph:

"The SGP M3UA layer determines the set of concerned ASPs to be informed
based on the SS7 network partition for which the primitive indication is
relevant. ..."

    Again, suggest changing "SS7 network partition" to "specific SS7
    network".  `network partition' is certainly not what is meant
    here.

[Greg] Fine.

Section 4.3.1 At an SGP, third paragraph:

"The SG M3UA MAY filter further based on the Affected Point Code in the
MTP-PAUSE, MTP-RESUME or MTP-STATUS indication primitives.  In this way ASPs
can be informed only of affected destinations to which they actually
communicate.
The SGP M3UA layer MAY also suppress DUPU messages to ASPs that do not
implement an MTP3-User protocol peer for the affected MTP3-User."

    This sounds rather peculiar since the MTP3 at the SGP will
    likely perform this filtering by way of its routing and
    screening tables.  This is a function which normally sits below
    the MTP-User interface.  What was the purpose of adding this
    text?  Remove this text.

[Greg] I'm not so sure that the MTP3 will likely filter this.  But I have
removed the paragraph anyway.

Section 4.3.1

"DUNA, DAVA, SCON, and DRST messages MUST be sent sequentially and processed
at the receiver in the order sent.  SCTP stream "0" is used to provide the
sequencing.
The only exception to this is if the international congestion method (see
Q.704) is used.  If so, the Unordered bit in the SCTP DATA chunk MAY be used
for the SCON message."

    Even SS7 permits TFA/TFR/TFP/TFC to be sent unsequenced.  This
    is because there are responsive procedures which will soon
    correct a reversal of the messages.  For congestion, adequate
    hysteresis is provided to avoid problems due to message
    reversal.  This text should be reworded to reflect this
    situation.  The "MUST" should be changed to a "MAY" and the
    reference to international congestion removed.

[Greg] I don't see any harm in enforcing the sequencing of these messages.
Then we don't have to worry about reversal.

Section 4.3.2.1

"In the case where a local event has caused the unavailability or congestion
status of SS7 destinations, the M3UA layer at the ASP MUST pass up
appropriate indications in the primitives to the M3UA User, as though
equivalent SSNM messages were received.  For example, the loss of an SCTP
association to an SGP may cause the unavailability of a set of SS7
destinations.  MTP-PAUSE indication primitives to the M3UA User are
appropriate.  To accomplish this, the M3UA layer at an ASP maintains the
status of routes via the SG(P), much like an MTP3 layer maintains route-set
status."

    There is no way of enforcing this "MUST" without defining which
    actions are "appropriate" for each local event.  Furthermore,
    this does not address interoperability of the protocol and is
    an implementation decision.  Change "MUST" to "SHOULD".

[Greg] Fine.

    The last sentence is an implementation suggestion and should be
    marked as an IMPLEMENTATION NOTE.

[Greg] Done

Section 4.3.2.2

"An M3UA layer at the ASP MAY choose to maintain knowledge of which SGPs are
included in Signalling Gateways for the purpose of interpreting SSNM
messaging from one SGP so as to apply to all the SGPs in the SG."

    This "MAY" does not speak well to interoperability between
    independent SGP and ASP implementations.  Surely the SGP must
    know what the effect of an SNMM sent to an ASP will be in terms
    of the other SGPs in the SG.  This "optional" mode of operating
    provides one more "a priori" thing that the SGP must know about
    the ASP.

    What happens when the ASP receives conflicting information from
    separate SGP within the same SG?

    Remove this option for the sake of interoperability.

[Greg] I have deleted it but I may reconsider based on the outcome of the
list discussion.

Section 4.3.3

"In the first of the cases above, the auditing  procedure must not be
invoked for the case of a received SCON message containing a congestion
level value of "no congestion" or undefined" (i.e., congestion Level = "0").
...

    What is the draft trying to get at here?

[Greg] There can be no audit as in this case the SG does not maintain
congestion status.

Section 4.3.3

"The SGP MUST respond to a DAUD message with the MTP3 availability/congested
status of the routeset associated with each Destination Point Code(s) in the
DAUD message.
..."

    This is problematic in the case that the DAUD message if for a
    destination to which the SGP has no route (as opposed to a
    destination to which the SGP has a route, but which is currently
    unavailable).

[Greg] Sorry - I'm confused.  What are you saying?

This is also a security issue in that an ASP
    should not be empowered to be able to inquire as to the status
    of all possible destinations: only destinations to which the ASP
    has authorized routes.

[Greg] I don't know how you can restrict an ASP to enquiring only about
certain destinations.  The SG can protect itself by not responding I guess.

Grammar:

    Section 1.3.2.4, first paragraph, change "in order to" to "to".
    Section 1.3.2.4, second paragraph, change "In order to" to "to".
    Section 1.4.2.4, first paragraph, change "In order to" to "To".
    Section 1.4.2.5, first paragraph, change "In order to" to "To"
    and "in order to" to "to".
    Section 1.4.3.2, second paragraph, change both instances of "in
    order to" to "to".
    Section 1.4.4, first paragraph, change "in order to" to "to".
    Section 1.4.5, first paragraph, change "in order to" to "to".
    Section 1.4.7, second paragraph, change "in order to" to "to".
    Section 3.4.1, first paragraph, change "in order to" to "to".
    Section 3.4.4, sixth paragraph, change "in order to" to "to".
    Section 3.8.2, fifteenth paragraph, change "in order to" to "to".
    Section 4.2.3.4, sixteenth paragraph, change "in order to" to "to".
    Section 4.3.3, first paragraph, change "in order to" to "to".

[Greg] Yes - a very bad habit of mine (and peeve or yours?)

Thanks Brian for all the comments!

Cheeeers,

  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: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: Routing Procedure for SUA
Date: Fri, 20 Jul 2001 13:25: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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Shanker,

> Yes i mean to ask the routing procedure between SEP/STP to AS
> and AS to SEP/STP. Since we do not have any dynamic registration 
> for an ASP. How can we setup the association for a SG/AS? 
> what parameter to be consider for routing? 

Via a MIB, MML, or database (including DNS/ENUM).

The Routing Context is used.

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: M2UA - Issue #7 - ASP Active procedures
Date: Fri, 20 Jul 2001 13:32:20 +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 Ken,

> Perhaps it is a general correspondence of ERR message problem
> similar to that posted for M3UA today.  The proposal there was
> to include a message and parameter diagnostic in the ERR
> message to permit the error to be correlated with the message
> and parameter causing the error.  If this proposal were to be
> adopted for M2UA, it would permit an ERR (Invalid Interface
> Identifier) with a parameter diagnostic listing the two IIDs
> which were at fault.  Then the ASP would know to stop any
> T(ack) timers with regard to those IIDs.

I don't have a strong opinion for M2UA - but for M3UA and SUA, I suggest
optionally using the parameter diagnostic to indicate invalid Routing
Contexts in this kind of case.

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 20 Jul 2001 06:59:24 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: SUA-06: Segmentation/Reassembly/Sequencing
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

The two statements in section 4.1.1 and 4.1.2 need modification to permit
proper operation of segmentation and reassembly in all protocol classes.
These sections indicate that the SG is responsible for segmentation and
reassembly of messages for all protocol classes in both directions.

The problems I see are related to decoupled multiple SG operation.

For class 0 and 1 operation:

Segmentation of CLDT messages into (XL)UDT messages at the SG requires the
use of a source segmentation reference number which the SG is difficult to
impossible for the SG to generate.  Because the SG is really a transfer node
in this case, it should follow the LUDT procedures from Q.714: i.e., if the
ASP generates a message larger than X-bytes (X is usually 255), it must pass
a source segmentation reference number to the SG with the CLDT message for
use in segmentation.

This means that we need a optional source segmentation reference parameter
in the CLDT message which MUST be included when the data payload of the CLDT
exceeds X-bytes (configurable per Network Appearance).

For class 2 and 3 operation:

Due to failures in the network, it may not be possible for the SG to
reassemble DT1 or DT2 messages into one large CODT message.
Furthermore, class 2 and 3 *does* also support stream operation (i.e.,
non-segmented data transfer) so it may be impossible for the SG to do
"reassembly".  In the multiple SG case, failures in the network can cause
some segments to go to the other SG making reassembly impossible (the first
SG must deliver up the first segments to the ASP) and the second SG cannot
tell where the beginning of the segment is (no remaining segments).  Also,
this reassembly process at the SG can unreasonably increase data transfer
latencies (to infinity if the more bit is always set).
For class 3 operation, the SG would also need to deal with sequencing
(because the ASP is not given true sequence numbers), again causing havoc in
decoupled operation across multiple SGs as a result of a changeover in the
network.

Because the "reassembly" process (if required at all by the nature of the
connection) is simple (more bit) and this bit is already provided for in the
CODT message, I propose that we make it the ASPs responsibiliy to reassemble
segments (if required) and handle a partial delivery interface for
non-segmented data connections.

For class 3 operation:

If it is the responsibility of the SG to do segmentation of CODT messages
into DT1 or DT2 messages, then it will also have to perform sequencing
(because each segment must be numbered with a monotonically increasing
sequence number).  This causes all kinds of havoc in the multiple SG
scenario when failures cause a decoupled connection section to pass through
the alternate SG.  The alternate SG will not be able to assign sequence
numbers and the connection will be reset by SCCP peer when it otherwise
would not have.  Also, it would make the sent sequence number in the CODT
message pointless.  Again, as above, the nature of the SCCP connection may
not necessarily delimit messages at all (i.e., the more bit is always
set--like TCP not UDP or SCTP).
Again, transfer latencies to the SS7 network could tend towards infinity.

Because the "segmentation" process is simple (more bit) and it is fairly
easy to determine the maximum segmentation size, I propose that we make it
the responsibility of the ASP to segment NSDUs into CODT messages.

Also, because decoupled class 3 connections through multiple SGs would
increase the likelihood of a reset SCCP connection because of changeover, if
the SG is required to handle sequence numbering, I propose that it be the
ASPs responsibility to handle sequence numbering for multiple SG class 3
operation and perform resets when required.

To recap:

	o   it is still the SGs responsibility to perform
	    segmentation/reassembly of (XL)UDT messages to
	    and from the ASP, but,

	o   the ASP must include a new source segmentation
	    number in the CLDT message when it sends large
	    data payloads, and,

	o   it becomes the ASPs responsibility to do
	    sequencing/segmenting and segmenting/reassembly in
	    both directions for CODT messages.

--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: "Antonio Roque-Alvarez (ECE)" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA (V7) DRST question
Date: Fri, 20 Jul 2001 14:17:32 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
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]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hello all,

That's OK for DUNA & DAVA & etc. but not for DRST. 
DUNA & DAVA & etc. messages can be ( in some cases )mapped to MTP-Pause,
-Resume and -Status primitives while DRST should never be. 
When an ASP receives a DRST from a SGP, it must be because this SGP knows
that there is another SGP, within the SG, which the ASP can use to reach
that destination ( I don´t know how ) and thus that the ASP knows that this
other SGP exists.
That's the nature of DRST message. If not, DRST message is useless and can
be replaced by DUNA.

Regards,
Antonio

-----Original Message-----
From: Schantz, John [mailto:[email-masked]] Sent: Thursday, July
19, 2001 5:06 PM
To: sigtran
Subject: RE: M3UA (V7) DRST question

Greg, Brian, everybody:

	I have a problem with this discussion.  To it looks like the train
is jumping its track.

	A DRST (& DUNA & DAVA & etc.) must be interrupted as the
status/state that a SG, as a whole, sees for a destination(s), independent
of which one of the SG's SGP sent it.  It CAN NOT be used on an individual
SGP basis.

John Schantz
Compaq Telecom

 -----Original Message-----
From: 	Brian F. G. Bidulock [mailto:[email-masked]] Sent:
Wednesday, July 18, 2001 6:18 PM
To:	sigtran
Subject:	Re: M3UA (V7) DRST question

Greg,

More below...

Greg Sidebottom wrote:                                       (Wed, 18 Jul
2001 18:51:24)
> Hi Brian,
> 
> Response below ...
> 
> - Original Message -----
> From: "Brian F. G. Bidulock" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Wednesday, July 18, 2001 5:49 PM
> Subject: Re: M3UA (V7) DRST question
> 
> 
> > Greg,
> >
> > I did find one problem with what you describe:  In several
> > places the draft make mention of things which would preclude,
> > or counter-recommend it:
> >
> >     Section 1.1
> >
> > "Where an SG contains more than one SGP, the SG is a
> > logical entity and the contained SGPs must be
> > coordinated into a signle management view to the SS7
> > network and to the supported Application Servers."
> >
> 
> [Greg] Do you mean it is contradictory because, for example, if only one
SGP
> in an SG sends a DRST then this is not a single management view from the
SG
> to the supported Application Servers?  Probably true, but I think this is
a
> useful exception - the SGPs are coordinating the traffic flows to make
them
> more efficient.   I think we can get around this by using "should" instead
> of "must" (i.e., "  .. the contained SGPs should be coordinated ...  ") as
> in the other sections.
> 
> >     Section 1.4.1
> >
> > "Where an SG contains more than one SGP, the MTP3
> > routeset, SPMC and remote AS/ASP states of each SGP
> > SHOULD be coordinated across all the SGPs.  Re-routing
> > of traffic between SGPs SHOULD also be supported."
> >
> > --Brian
> 
> [Greg] I'm not sure yet why this text is contradictory?  The SGP states
> maintained locally can be different but aggregated into a single set of
> overall SG states, assuming there is no breakdown of inter-SGP
> communication.

Well, it is just a question of which thing you are sending to the ASP when
you send things like DRST for multiple SGP.
The ASP needs to know whether it is the SG status or the SGP status which is
being indicated.

  If all these things (DUNA/DAVA/DRST) are only an
  indication of the SGP status, then the ASP receives
  one for each SGP and must derive the SG status from
  the aggregate of the SGPs--which is contrary to the
  above statements.
  
  If DUNA/DAVA/DRST are indications of SG status, then
  it must already represent an aggregate view and the
  ASP needs only receive these from one SGP.

Unfortunately you can't have it both ways unless we add something to these
messages: i.e. an indicator as to whether the status applies to the SGP or
the whole SG.

I don't have a problem with the ASP keeping track of these things on a
per-SGP basis.  As a matter of fact I think it is quite apt for M3UA.  But
text list this which recommends otherwise gives the impression that the SG
is aggregating these things for the ASP when  in the per-SGP case, the ASP
must do the aggregation.

> Thanks,
>     Greg

-- 
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]
Date: Fri, 20 Jul 2001 07:23:29 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: upper layer primitives of SUA
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Sodhi,

Please reference the pertinent standards.

The NSD (which describes the primitives) was standardized in ISO 8348 and
ITU X.213.

SS7 SCCP specifications (ITU Q.71x and ANSI T1.112) discuss differences
between the NSD and the SCCP.

You will find that ANSI T1.112 states that the QoS parameters of the NSD are
mapped into Protocol Class.

--Brian

asodhi wrote:                                   (Fri, 20 Jul 2001 15:08:06)
> hi!
> 
> i am not getting the details of all the parameters that are used by
> N-CONNECT primitive etc. i got the details of Called address, calling
> address, user data but not of expedited data selection, quality of service
> parameter set.
> 
> what's the way to get full details of the Primitive parameters,not of the
> message parameters.
> 
> Sodhi
> 

-- 
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: SUA-06: Segmentation/Reassembly/Sequencing
Date: Fri, 20 Jul 2001 15:49:17 +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: [131.228.20.26]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

I don't think we can completely resolve this before I re-issue the draft.

Some questions / comments:

> Segmentation of CLDT messages into (XL)UDT messages at the SG
> requires the use of a source segmentation reference number which the
> SG is difficult to impossible for the SG to generate.  Because the
> SG is really a transfer node in this case, it should follow the LUDT
> procedures from Q.714: i.e., if the ASP generates a message larger
> than X-bytes (X is usually 255), it must pass a source segmentation
> reference number to the SG with the CLDT message for use in
> segmentation.
> 
> This means that we need a optional source segmentation reference
> parameter in the CLDT message which MUST be included when the data
> payload of the CLDT exceeds X-bytes (configurable per Network
> Appearance).

If we remove the network appearance, and use only Routing Context, how would
you like to handle this?  Do we specify the Routing Context to be a
combination of a the range of traffic & network ID that an ASP handles
within an AS?

-- bunch of things clipped --

> To recap:
> 
> 	o   it is still the SGs responsibility to perform
> 	    segmentation/reassembly of (XL)UDT messages to
> 	    and from the ASP, but,
> 
> 	o   the ASP must include a new source segmentation
> 	    number in the CLDT message when it sends large
> 	    data payloads, and,
> 
> 	o   it becomes the ASPs responsibility to do
> 	    sequencing/segmenting and segmenting/reassembly in
> 	    both directions for CODT messages.

My gut reaction is that I don't think designing for the decoupled case is
really my goal.  

I'm going to have to think about this a bit more - if you want to propose
text, I will be more than happy to consider it.

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
X-Lotus-FromDomain: HSS
To: "sigtran" <[email-masked]>
Date: Fri, 20 Jul 2001 18:32:53 +0530
Subject: Re: SUA-06: Segmentation/Reassembly/Sequencing
X-SMTP-HELO: hindon.hss.co.in
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [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]

John

I am not able to userstand the very basic question, why SUA should support
segmentation/reassembly of messages when it is implicitly being provided by
the userlying transport layer SCTP. I have followed the older mails
exchanged on this topic and could figure out that it is being supported for
two reasons:

1. SCCP at SG should not wait for all the messages for reassembly and
subsequent delivery to upper layer because it may lead to delays in
transport of messages to ASP.

For e.g. if segmented XUDT messages are received at SG, SCCP at SG may
reassemble them and give whole of the combined message to SUA or it may give
individual segmented XUDT messages which will get reassembled at SUA at ASP.

2. SCTP at ASP may also deliver partial messages to SUA due to which it will
have to support reassembly.

Which primitive SCCP provides for delivery of segmented messages to upper
layer?

As partial delivery of SCTP is concerned, any SCTP application should
support it and this may not be the motivation behind supporting segmentation
in SUA.

Thanks

Vakul

"Brian F. G. Bidulock" <[email-masked]> on 07/20/2001 06:29:24 PM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]> cc:    (bcc: Vakul
Garg/HSS)

Subject:  SUA-06: Segmentation/Reassembly/Sequencing

John,

The two statements in section 4.1.1 and 4.1.2 need modification to permit
proper operation of segmentation and reassembly in all protocol classes.
These sections indicate that the SG is responsible for segmentation and
reassembly of messages for all protocol classes in both directions.

The problems I see are related to decoupled multiple SG operation.

For class 0 and 1 operation:

Segmentation of CLDT messages into (XL)UDT messages at the SG requires the
use of a source segmentation reference number which the SG is difficult to
impossible for the SG to generate.  Because the SG is really a transfer node
in this case, it should follow the LUDT procedures from Q.714: i.e., if the
ASP generates a message larger than X-bytes (X is usually 255), it must pass
a source segmentation reference number to the SG with the CLDT message for
use in segmentation.

This means that we need a optional source segmentation reference parameter
in the CLDT message which MUST be included when the data payload of the CLDT
exceeds X-bytes (configurable per Network Appearance).

For class 2 and 3 operation:

Due to failures in the network, it may not be possible for the SG to
reassemble DT1 or DT2 messages into one large CODT message.
Furthermore, class 2 and 3 *does* also support stream operation (i.e.,
non-segmented data transfer) so it may be impossible for the SG to do
"reassembly".  In the multiple SG case, failures in the network can cause
some segments to go to the other SG making reassembly impossible (the first
SG must deliver up the first segments to the ASP) and the second SG cannot
tell where the beginning of the segment is (no remaining segments).  Also,
this reassembly process at the SG can unreasonably increase data transfer
latencies (to infinity if the more bit is always set).
For class 3 operation, the SG would also need to deal with sequencing
(because the ASP is not given true sequence numbers), again causing havoc in
decoupled operation across multiple SGs as a result of a changeover in the
network.

Because the "reassembly" process (if required at all by the nature of the
connection) is simple (more bit) and this bit is already provided for in the
CODT message, I propose that we make it the ASPs responsibiliy to reassemble
segments (if required) and handle a partial delivery interface for
non-segmented data connections.

For class 3 operation:

If it is the responsibility of the SG to do segmentation of CODT messages
into DT1 or DT2 messages, then it will also have to perform sequencing
(because each segment must be numbered with a monotonically increasing
sequence number).  This causes all kinds of havoc in the multiple SG
scenario when failures cause a decoupled connection section to pass through
the alternate SG.  The alternate SG will not be able to assign sequence
numbers and the connection will be reset by SCCP peer when it otherwise
would not have.  Also, it would make the sent sequence number in the CODT
message pointless.  Again, as above, the nature of the SCCP connection may
not necessarily delimit messages at all (i.e., the more bit is always
set--like TCP not UDP or SCTP).
Again, transfer latencies to the SS7 network could tend towards infinity.

Because the "segmentation" process is simple (more bit) and it is fairly
easy to determine the maximum segmentation size, I propose that we make it
the responsibility of the ASP to segment NSDUs into CODT messages.

Also, because decoupled class 3 connections through multiple SGs would
increase the likelihood of a reset SCCP connection because of changeover, if
the SG is required to handle sequence numbering, I propose that it be the
ASPs responsibility to handle sequence numbering for multiple SG class 3
operation and perform resets when required.

To recap:

     o   it is still the SGs responsibility to perform
         segmentation/reassembly of (XL)UDT messages to
         and from the ASP, but,

     o   the ASP must include a new source segmentation
         number in the CLDT message when it sends large
         data payloads, and,

     o   it becomes the ASPs responsibility to do
         sequencing/segmenting and segmenting/reassembly in
         both directions for CODT messages.

--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]

---
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 - Issue #7 - ASP Active procedures
X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001
Date: Fri, 20 Jul 2001 09:33:00 -0400
X-MIMETrack: Serialize by Router on HQ_ACS_1/Radisys_Corporation/US(Release 
             5.0.8 |June 18, 2001) at 07/20/2001 06:35:29 AM, Serialize 
             complete at 07/20/2001 06:35:29 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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Ken,

The proposal that was put forward at the M3UA "bay-cough" was to add to the
protocol a "NACK" (Negative Acknowledge) message. The advantage of the NACK
over the ERROR message is that there is clear and instant correlation to the
ASP Active Msg.

Greg forgot about this proposal when he was editing M3UA v7. He is
considering adding it to the next version of M3UA.

Barry Nagelberg
Software Engineer
RadiSys, Corp.
Signaling Products Design Center
[email-masked]
+1-856-642-9229 x237

Ken Morneault <[email-masked]>
07/19/01 10:16 PM
Please respond to sigtran

        To:     "sigtran" <[email-masked]>
        cc: 
        Subject:        M2UA - Issue #7 - ASP Active procedures

Note:  This issue also impacts M3UA.  Just replace Interface Identifier with
Routing Context.

If an SG receives an ASP Active message (at the proper time) which has some
Interface Ids indicating AS for which the ASP is not configured/registered,
how does the SG respond?  The draft only allows for two situations that I
can see:

   1.  ASP Active is unexpected:  Error - Unexpected Message
   2.  ASP Active is expected:    Must return ASP Active Ack.

We need a procedure to tell the ASP that an interface id is incorrect or
that some other failure has occured and which describes the disposition of
valid IIDs in the ASP Active.

The use of ERR (Invalid Interface Identifier) is appropriate, however, it
should be mentioned in the ASP Active procedures section.

Also, the disposition of other non-errored IIDs in the ASPAC needs to be
addressed for interoperability sake.

For example, the ASP sends an ASPAC with 5 IIDs which are representative of
5 ASs.  Two of them are invalid (i.e., there is no configured/registered AS
which has these two IIDs on the SG).  The SG could respond with an ERR
(Invalid Interface Identifier) and an ASPAC Ack for the 3 successful IIDs,
but then how does the ASP know which IIDs the ERR corresponds to.

Perhaps it is a general correspondence of ERR message problem similar to
that posted for M3UA today.  The proposal there was to include a message and
parameter diagnostic in the ERR message to permit the error to be correlated
with the message and parameter causing the error.  If this proposal were to
be adopted for M2UA, it would permit an ERR (Invalid Interface Identifier)
with a parameter diagnostic listing the two IIDs which were at fault.  Then
the ASP would know to stop any T(ack) timers with regard to those IIDs.

Another approach would be to fail all 5 IIDs and only send one ERR message
(and no ASPAC Ack).  This would be a better approach because the ASP may not
want to start receiving traffic for a partly unsuccessful activation
attempt.

It gets worse for IID ranges.

Otherwise, to get expected behavior, the ASP will need to send each IID in
an individual ASPAC and wait for the ASPAC Ack or ERR message on each before
sending the next and will have to be prepared to start messaging on a
partially built group of AS.  This would severly reduce the value and
usability of placing multiple IID in the ASPAC message at all.

---
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: Updated SUA sent out
Date: Fri, 20 Jul 2001 17:09:35 +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 all,

I have just sent out an update version of SUA to the IETF Drafts Editor.
With any luck, it will be in an inbox near you soon.
For those of you who are filled with anticipation, you can get a preview of
it here:

	http://www-nrc.nokia.com/sua/sua.htm

As I feel it is quite stable, I would like the WG to consider this version
for last call.  

I'm going to try to track any issues via a web page - if the WG and Lyndon
don't mind.  Taking a page off of the AAA WG, I suggest a template that
looks like the following:

To submit a new issue, send an e-mail to the SIGTRAN, using the following
template: 

Description of issue 
Submitter name: Your_Name_Here 
Submitter email address: Your_Email_Address_Here Date first submitted:
Insert_Date_Here Reference: URL to e-mail describing problem, if available
Comment type: ['T'echnical | 'E'ditorial] Priority: ['S' Must fix | '1'
Should fix | '2' May fix ] Section: Insert_Section_Number_Here 
Rationale/Explanation of issue: 
Length description of problem 

Requested change: 
Proposal 

And if you can use [SUAv7] in any mails, I'd appreciate it.

Thanks,
John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Zannin, Francois" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA (V7) DRST question
Date: Fri, 20 Jul 2001 16:31:31 +0200
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: zmamail04.zma.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [161.114.64.104]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hello,

This is our understanding of the use of the DRST and partitioning between
the SGP.
See below,
Do you agree with this?

    Regards,
    Francois Z.

0000000001111111111222222222233333333334444444444555555555566666666667777777
7778
1234567890123456789012345678901234567890123456789012345678901234567890123456
7890

     SS7 World                              IP World
============================          =================
                               S.G.                       A.S.
                          ..............
 +----+     +-----+ R1    . +-------+  .               +-------+
|SP_1|-----|STP_A|---------| SGP_1 |-----------[As0]--|       |  +----+
|     |---   ---|       |  .    ----[As1]--| ASP_1 |
            +-----+   \ / . +---++--+  .   / ---[As2]--|       |
                       \  .     ||     .  / /          +-------+  +----+
+-----+   / \ . +---++--+  . / /  |SP_2|-----|STP_B|---   ---| SGP_2 |---- /
+----+     |     |---------|       |  . /
            +--+--+ R2    . +---++--+  ./
          Clink|          .     ||     /  +----+     +--+--+       .
+---++--+ /.
 |SP_3|-----|STP_C|---------| SGP_3 |- .
 +----+     |     |---------|       |  .
            +-----+ R3    . +-------+  .
                          ..............

In this configuration,
The destination SP_2 can be reached via R2 (STP_B) and if R2 fails, via R3
(STP_C).

ASP_1 is connected to SGP_1 by the association As0 ASP_1 is connected to
SGP_2 by the association As1 ASP_1 is connected to SGP_3 by the association
As2 

SP_2 can be reached via STP_B which is connected to SGP_1 and SGP_2 for
redundancy perspective.
ASP_1 will use links As0 and As1 to send messages to SP_2 and only uses As2
if As0 and As1 fail.

With this configuration the DAVA are sent from SGP_1, SGP_2 and SGP_3 BUT
SGP_3 can also send a DRST to inform ASP_1 that it should use As0 and As1 in
priority. This DRST is not the result of a TFR message.

If a TFR is received from STP_B, this information is distributed to all the
SGP and then all the SGP send a DRST to the ASP. These DRST can be used by
the ASP to reroute the traffic on another SG if there is one available.

All the MTP3 information must be distributed to all the SGP because if the
route R2 fails, all the messages already sent from the ASP to SGP_1 and
SGP_2 before the receipt of a DRST must be forwarded to the SGP_3 for the
time controlled diversion between R2 to R3 or R3 to R2 if R2 restarts.

If the platform is partitioned, message sequencing cannot be performed
between the ASP and the ss7 SP. Another problem that occurs in a partitioned
platform is that the network management messages concerning one route may be
sent on another route because the ss7 network sees the SG as an unique point
code.

If we chose to have a partitioned platform, we must be sure that we never
will receive management messages on another route then the one it concerns
and this depend of the ss7 network configuration. 

==================================================================
  ALL THIS BEHAVIOR IS TRUE IF THE SGP ARE DIRECTLY CONNECTED TO 
  THE SS7 NETWORK WITHOUT INTERMEDIATE PROCESSES.
==================================================================

-----Original Message-----
From: Antonio Roque-Alvarez (ECE)
[mailto:[email-masked]] Sent: Friday, July 20, 2001
2:18 PM
To: sigtran
Subject: RE: M3UA (V7) DRST question

Hello all,

That's OK for DUNA & DAVA & etc. but not for DRST. 
DUNA & DAVA & etc. messages can be ( in some cases )mapped to MTP-Pause,
-Resume and -Status primitives while DRST should never be. 
When an ASP receives a DRST from a SGP, it must be because this SGP knows
that there is another SGP, within the SG, which the ASP can use to reach
that destination ( I don´t know how ) and thus that the ASP knows that this
other SGP exists.
That's the nature of DRST message. If not, DRST message is useless and can
be replaced by DUNA.

Regards,
Antonio

-----Original Message-----
From: Schantz, John [mailto:[email-masked]] Sent: Thursday, July
19, 2001 5:06 PM
To: sigtran
Subject: RE: M3UA (V7) DRST question

Greg, Brian, everybody:

	I have a problem with this discussion.  To it looks like the train
is jumping its track.

	A DRST (& DUNA & DAVA & etc.) must be interrupted as the
status/state that a SG, as a whole, sees for a destination(s), independent
of which one of the SG's SGP sent it.  It CAN NOT be used on an individual
SGP basis.

John Schantz
Compaq Telecom

 -----Original Message-----
From: 	Brian F. G. Bidulock [mailto:[email-masked]] Sent:
Wednesday, July 18, 2001 6:18 PM
To:	sigtran
Subject:	Re: M3UA (V7) DRST question

Greg,

More below...

Greg Sidebottom wrote:                                       (Wed, 18 Jul
2001 18:51:24)
> Hi Brian,
> 
> Response below ...
> 
> - Original Message -----
> From: "Brian F. G. Bidulock" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Wednesday, July 18, 2001 5:49 PM
> Subject: Re: M3UA (V7) DRST question
> 
> 
> > Greg,
> >
> > I did find one problem with what you describe:  In several
> > places the draft make mention of things which would preclude,
> > or counter-recommend it:
> >
> >     Section 1.1
> >
> > "Where an SG contains more than one SGP, the SG is a
> > logical entity and the contained SGPs must be
> > coordinated into a signle management view to the SS7
> > network and to the supported Application Servers."
> >
> 
> [Greg] Do you mean it is contradictory because, for example, if only one
SGP
> in an SG sends a DRST then this is not a single management view from the
SG
> to the supported Application Servers?  Probably true, but I think this is
a
> useful exception - the SGPs are coordinating the traffic flows to make
them
> more efficient.   I think we can get around this by using "should" instead
> of "must" (i.e., "  .. the contained SGPs should be coordinated ...  ") as
> in the other sections.
> 
> >     Section 1.4.1
> >
> > "Where an SG contains more than one SGP, the MTP3
> > routeset, SPMC and remote AS/ASP states of each SGP
> > SHOULD be coordinated across all the SGPs.  Re-routing
> > of traffic between SGPs SHOULD also be supported."
> >
> > --Brian
> 
> [Greg] I'm not sure yet why this text is contradictory?  The SGP states
> maintained locally can be different but aggregated into a single set of
> overall SG states, assuming there is no breakdown of inter-SGP
> communication.

Well, it is just a question of which thing you are sending to the ASP when
you send things like DRST for multiple SGP.
The ASP needs to know whether it is the SG status or the SGP status which is
being indicated.

  If all these things (DUNA/DAVA/DRST) are only an
  indication of the SGP status, then the ASP receives
  one for each SGP and must derive the SG status from
  the aggregate of the SGPs--which is contrary to the
  above statements.
  
  If DUNA/DAVA/DRST are indications of SG status, then
  it must already represent an aggregate view and the
  ASP needs only receive these from one SGP.

Unfortunately you can't have it both ways unless we add something to these
messages: i.e. an indicator as to whether the status applies to the SGP or
the whole SG.

I don't have a problem with the ASP keeping track of these things on a
per-SGP basis.  As a matter of fact I think it is quite apt for M3UA.  But
text list this which recommends otherwise gives the impression that the SG
is aggregating these things for the ASP when  in the per-SGP case, the ASP
must do the aggregation.

> Thanks,
>     Greg

-- 
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]

---
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: M3UA (V7) DRST question
Date: Fri, 20 Jul 2001 07:53:04 -0700
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: zcamail05.zca.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [161.114.32.105]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,
	I don't think I am reading a lot into "single management view".
This is the view that all SS7 nodes have today and if any SG wants to
connect into an SS7 network will need to abide by the same management
philosophy (it is built into the SS7 protocol).

	So you're telling me that a partitioned SG will have a "single
management view" towards the SS7 network but it will not maintain this view
for its' SGPs.  You are basically forcing the AS to have more complicated
management structure because you are not willing to build a node that abides
by the general philosophy that all other nodes in the network must abide by.
So you are asking the AS to collect management messages from each SGP, as
though they are independent nodes, before the AS can then determine the true
state of a remote destination.  When are you going to stop pushing all of
your dirty work onto the ASs?  Why is a limited node architecture driving
the standard?  Who do you think will buy a SG like this (cheap but almost no
network management functions)?  A small protocol converter per link would be
better than this, at least it blindly convert the management message and not
make its presence known.

	You can make it OPTIONAL but thank goodness my node will be in
networks with real SGs.

John

 -----Original Message-----
From: 	Brian F. G. Bidulock [mailto:[email-masked]] Sent:
Thursday, July 19, 2001 4:38 PM
To:	sigtran
Subject:	Re: M3UA (V7) DRST question

John,

I think that you are reading alot into the "single management view"
statement, as it is not really defined what this means; but, I understand
what you are getting at.  Certainly the fact that it is possible that an ASP
may receive conflicting information from individual SGP, it does not
preclude building a system which assumes this single management view.

Perhaps a resolution to the situation, for the sake of interoperability, is
to say the the SG SHOULD present such a single view of availability/
congestion/restriction status, but that the ASP SHOULD keep track of that
status on a per-SGP basis.

Then, if an ASP implementation chooses to rely heavily on a single
management view from the SG, it must do so with the full understanding that
it might not interoperate as well with a partionable SG implementation.
And, if the SGP implementation chooses to not present such a single
management view to the ASP, that it might not interoperate as well with ASPs
which rely upon it.

That way due warning is given, nothing is precluded, and maximum
interoperability may result.  Let the implementations solve the details.

Plus, this takes the least amount of text changes, right Greg?

Comments?

--Brian

Schantz, John wrote:                           (Thu, 19 Jul 2001 13:41:44)
> Brian,
> 	I will need to read what the changes are but availability and
> congestion would show up in the status of the 'links/associations', hence
it
> is already taken care of.  There is no parallel for restricted for an
> interface.
> 
> 	If you look at the definition of a SG from the M3UA document:
> 
> Signalling Gateway - An SG is a signaling agent that receives/sends SCN 
> native signaling at the edge of the IP network [1].  An SG appears to 
> the SS7 network as an SS7 Signalling Point.  An SG contains a set of one 
> or more unique Signalling Gateway Processes, of which one or more is 
> normally actively processing traffic.  Where an SG contains more than 
> one SGP, the SG is a logical entity and the contained SGPs must be 
> coordinated into a single management view to the SS7 network and to the 
> supported Application Servers.
> 
> 	Notice the highlighted "single management view", this states to me
> that the SG has a single management function even if it is composed of
> multiple SGPs.  We will be supporting multiple ASPs and we will also have
a
> single management view of the system and it interfaces.  Therefore, if a
PC
> is prohibited, allowed, congested, or restricted, only single management
> message should be sent to its adjacent nodes.  You can not use DUNA, DAVA,
> SCON, DRST, etc. to manage a single SGP, they are the "single management
> view" of the SG for destinations.
> 
> 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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 20 Jul 2001 10:21:33 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07 Comments
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

Ok, while your wrapping it up, let me first hit ONE BIT NIT:

   Runaway hyphenation throughout the document:

	`Backup'         is one word, not `back-up'.
	`Reroute'        is one word, not `re-route'.
	`Unidirectional' is one word, not `uni-directional'.
	`Unordered'      is one word, not `un-ordered'.
	`Interworking'   is one word, not `inter-working'.
	`Reassembly'     is one word, not `re-assembly'.
	`Rerouting'      is one word, not `re-routing'.
	`Ongoing'        is one word, not `on-going'.
	`Deregister' is not a word.  `Unregister' is the opposite of
		  `register'.  But I suppose we are stuck with it: but if it
		  *was* a word, it would not be `de-register' as `de' is
		  normally only hyphenated before a word starting with `e'
as
		  in `de-energized'.)
	`Deregistration' not `de-registration'.
	`Override'       is one word, not `over-ride'.
	`Overriding'     is one word, not `over-riding'.
	`Lockout'        is one word, not `lock-out'.
	`Setup'          is one word, not `set-up'.
	`Preconfigured'  is one word, not `pre-configured'.
	`Reestablish'    is one word, not `re-establish'.
	`Reallocated'    is one word, not `re-allocated'.
	`Unconfigured'   is one word, not `un-configured'.
	`Unsequenced'    is one word, not `un-sequenced'.
	`Redirect'       is one word, not `re-direct'.

Can you run the document through a spell-checker and grammar-checker
before-releasing-it-as-an-RFC? ;)

Follow-up comments below...

Greg Sidebottom wrote:                                       (Fri, 20 Jul
2001 06:12:29)

[snip]
> "an active or standby" was changed to "active or back-up"
> 
>     Why?
> 
> [Greg] So as not to confuse with the standby traffic mode

Ok.  But its `backup'... ;)

> Section 1.2 Terminology, fifteenth paragraph (Network Appearance
> definition):
> 
> "This partitioning is necessary where an SG is logically
> partitioned to appear as end node elements in multiple
> separate SS7 networks, in which case there is a separate
> network appearance for each point code in the SS7 networks."
> 
>     and
> 
> "It is also necessary when an SG is configured as an STP
> hosting multiple point codes, or when configured as multiple
> end nodes within the same network, in which case each point
> code is a separate network appearance.between the SG and the
> Application Server Processes over a common SCTP
> Association."
> 
>     This implies that separate network appearances are required for
>     both multiple and "alias" point codes, meaning that a separate
>     AS is required for each point code, even though the same set of
>     MTP3 management procedures may apply to the entire set.
>     Definitely this language is somewhat confusing.  Suggest
>     something more like the following:
> 
> Network Appearance - The Network Appearance uniquely
> identifies one SS7 network of multiple disjoint SS7 networks
> in which an SPMC resides.
> 
> [Greg] It was an agreement on the list, and changed in Issue 7, to have
> separate Network Appearances for each point code even if they could be
> considered as in the same SG network partition.  Your above definition is
> actually pretty close to the previous definition.  See the thread started
by
> Norm Glaude in January for a description.  It was agreed on the list to
line
> up the definitions between the SUA and M3UA

Ok.  Sorry I missed that.

[snip[
> 
> [Greg] Your proposal is missing here  2:^0   I changed it to:
> 
> "Within the framework architecture, this document defines an MTP3-User
> adaptation module suitable for supporting the transfer of messages of any
> protocol layer that is identified to the MTP Level 3 as an MTP User."

That's fine.

> 
> 
> Section 1.3.1 Protocol Architecture
> 
> "- Sequenced delivery of user messages within multiple
> streams, with an option for order-of-arrival delivery of
> individual user messages,"
> 
>     M3UA does not utilize order-of-arrival delivery and this aspect
>     of SCTP cannot be taken avantage of by using SCTP as a transport
>     for M3UA.
> 
> [Greg] Some SSNM messages are allowed to be sent unsequenced (DAUD,
SCON?).
> If they are sent unsequenced I assume that this feature would be used.

Yes.  Sorry.  I noticed that after I sent this off...

> 
> 
> Section 1.3.1 Protocol Architecture
> 
> "- Optional multiplexing of user messages into SCTP
> datagrams,"
> 
>     It is not clear how M3UA can utilize this optional feature of
>     SCTP.
> 
> [Greg] An SCTP User can request bundling, which I assume is what is meant
by
> multiplexing here.  The M3UA doesn't state when to use bundling but it
could
> use it.  I assume this would be an operational decision, not a protocol
> decision.
> 
> 
> Section 1.3.1 Protocol Architecture
> 
> "- Network-level fault tolerance through support of
> multi-homing at either or both ends of an association,"
> 
>     SCTP multi-homing can be used by a specific implementation and a
>     specific configuration to support network-level fault tolerance,
>     but SCTP does not provide this in itself.  M3UA does not get
>     network- level fault tolerance merely by using SCTP as a
>     transport, nor necessarily by merely using SCTP's multi-homing
>     feature.
> 
> [Greg] This is just a lshort isting of an SCTP feature - directly from the
> SCTP spec.  Yes there are configuration and implementation decisions to
make
> it work but I don't hink it is necessary to describe that here.

I wish it would have been left in the SCTP spec, where it came from.

> 
> 
> Section 1.3.1 Protocol Architecture
> 
> "Under certain scenarios, such as back-to-back connections
> without redundancy requirements, the SCTP functions above
> MAY NOT be a requirement and TCP can be used as the
> underlying common transport protocol."
> 
>     Should an implementation support TCP as well?
> 
> [Greg] No recommendation is made - it is up to the implementor.  The
> sentence just "allows" some implementations to use TCP if they like.

It's just the weird use of "MAY NOT" and "TCP can".

Might I suggest that it change to "might not" and "TCP MAY".

"MAY NOT be a requirement" is giving permission for the lack of a
requirement. :]

> 
> 
> Section 1.3.2
> 
> "The M3UA layer does not itself provide the MTP3 services.
> However, in the case where an ASP is connected to more than
> one SGP, the M3UA layer at an ASP must maintain the status
> of configured SS7 destinations and route messages according
> to the availability and congestion status of the routes to
> these destinations via each SGP."
> 
>     In this text "SG" from version 6 has been changed to "SGP" in
>     version 7.  This has the negative impact that this text requires
>     that when the ASP is connected to more than one SGP, the ASP is
>     required to maintain SS7 routing information on a per-SGP basis
>     rather than a per-SG basis.  Although both cases are valid, it
>     represents a significant departure from the version 6 model.
> 
> [Greg] Yes but this was as agreed on the list.  There is a thread on the
> list revisiting this so I will defer to the thread on the list.

That's ok, this note is oooold.

> 
> 
>     For example, what does an SGP do with tranfer messages for which
>     it has no route?  In the version 6 situation, it is clear that
>     if the SG has a route, the SGP either deals with messages for
>     that route (or take itself out of service).  Now it is not so
>     clear.
> 
> [Greg] Sorry I'm not following this example.

Before if an SGP could not route messages sent to it, it was a "MUST" that
it drop the association.  I think this is handled now with the inter-SGP
communication recommendation and per-SGP routes.  Leave it for the other
discussion.  The other discussion didn't start until I sent this.

> 
> 
>     Also, the "must" here means what?  Does it mean MUST?
> 
> [Greg] probably should be a MUST or SHOULD, depending on the outcome of
the
> thread on the list

Agreed.

> 
> 
> Section 1.3.2.1
> 
> "The MTP-TRANSFER primitive information is encoded as in
> MTP3-User messages.  In this way, the SCCP and ISUP messages
> received from the SS7 network by the SGP are not re-encoded
> into a different format for transport between the M3UA
> peers.  The MTP3 Service Information Octet (SIO) and Routing
> Label (OPC, DPC, and SLS) are included, encoded as expected
> by the MTP3 and MTP3-User protocol layer."
> 
>     As discussed on the list, many MTP-User interfaces pass routing
>     label information as parameters, which must then be "re-encoded"
>     at the SG before transport to the ASP and "re-decoded" at the
>     ASP to pass to the MTP-User.  This issue has not yet been
>     addressed.
> 
> [Greg] I'll leave this to conclude on the list - I may be slow but so far
I
> don't see a consensus.

I don't recall any objections.

> 
> 
> Section 1.3.2.1
> 
> "At an ASP, in the case where a destination is reachable via
> multiple SGPs, the M3UA layer must also choose via which SGP
> the message is to be routed or support load balancing across
> the SGPs, ensuring that no missequencing occurs."
> 
>     M3UA in its current trim does not support the requirement that
>     the ASP ensure that "no missequencing occurs".  Also, no
>     procedure is given in M3UA to select an SGP from multiple SGPs
>     for which the destination is available.  The management of SGPs
>     at he ASP is an outstanding and significant issue.
> 
> [Greg] Well we need a proposal then.  I assume some part of this falls out
> from the SG/SGP thread on the list (SG versus SGP view for SSNM
messaging).
> I assume that the SLS is used just like in MTP3 for link selection, taking
> into account the remote SGP availability status.  And I agree with your
> point on the list about the need for controlled rerouting.  The
implementors
> I have talked to seem to understand this but we probably need a section to
> describe this.  I don't really want to get into re-interpretting MTP3
> procedures though - maybe we could provide a set of guidelines instead?

You get me wrong.  I had a problem with

       "must" "ensur[e]" "that no missequencing occurs"

"ensure" is a strong word.  Say, "minimizing missequencing".

Oh, by the way, elsehwhere in the document "mis-sequencing" should be
changed to "missequencing".

> 
> 
> Section 1.3.2.1
> 
> "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."
> 
>     This is also true for Q.703 Annex A operation which is cited as
>     only supporting 272-octets as cited in [14] at the beginning of
>     this paragraph.  Citing specific SS7 refererences here is of
>     little use as the need for M3UA to respect maximum SIF sizes
>     depends upon the implementation and the network configuration.
> 
> [Greg] I understand but I'm not sure what you would like changed - you
want
> to remove the refernce to MTP3b?

What I'm saying is that the statement is not really correct.  It might be if
it said "provisioned to *only* support the Broadband MTP".  Otherwise, the
interworking procedures specified in the standards should be used.
And, I'm saying that this is not the only case that SIF size is larger: the
other instances are conspicuous by their absence.  I would like to see:

    "The provisioning and configuration of the SS7 network
     determines the restriction placed on the maximum
     information block size.  Some configurations (e.g,
     Broadband MTP [20]) may permit larger block sizes."

[snip]
> 
> Section 1.3.2.3
> 
> "At the SGP, the M3UA layer must also provide inter-working
> with MTP3 management functions to support seamless operation
> of the user SCN signalling applications in the SS7 and IP
> domains."
> 
>     This statement places a requirement (or an objective) on M3UA.
>     It is arguable whether M3UA can "support seamless operation fo
>     the user SCN signalling applications in the SS7 and IP domains".
> 
> [Greg] Like you say, it is a requirement or objective - time will tell if
we
> are successful

Assume we are successful.  Say:

  "At the SGP, the M3UA layer provides interworking..."

That is, don't way what it "must provide," say what it "provides," whether
that is an opinion of its authors or not.

> 
> 
> Section 1.3.2.3
> 
> "- Providing an indication to MTP3-Users at an ASP that a
>    remote destination in the SS7 network is not reachable.
> 
> - Providing an indication to MTP3-Users at an ASP that a
>    remote destination in the SS7 network is now reachable.
> 
> - Providing an indication to MTP3-Users at an ASP that
>    messages to a remote destination in the SS7 network are
>    experiencing SS7 congestion.
> 
> - Providing an indication to the M3UA layer at an ASP that
>    the routes to a remote destination in the SS7 network are
>    restricted.
> 
> - Providing an indication to MTP3-Users at an ASP that a
>    remote MTP3- User peer is unavailable.
> 
>     The words "remote destination" here is confusing.  A local or
>     adjacent destination can also become unreachable and can also
>     experience congestion.
> 
> [Greg] I removed "remote" - assuming that helps.

Yes.

> 
> 
> 
> Section 1.3.2.4
> 
> "The M3UA layer at the SGP maintains the availability state
> of all configured remote ASPs, in order to manage the SCTP
> Associations and the traffic between the M3UA peers.  As
> well, the active/inactive and congestion state of remote
> ASPs is maintained."
> 
>    SG changed to SGP has different meaning here.  Now it appears
>    that it is each SGP's responsibility to maintain the state of all
>    remote ASPs.  It also means that an ASP can be active for one SGP
>    and inactive for another.  Although not necessarily incorrect,
>    this is substantially different from the version 6 text.
> 
> [Greg] Yes.  I'm not sure that an SGP would have a different view than
other
> SGPs of the active/inactive state of an ASP - except maybe in a transitory
> sense.

Well, an ASP appears free to move to the inactive or down state with one
SGP, but stay active with another.  Also, one SGP may have a downed
association with an ASP whereas another SGP does not and the ASP is active.

[snip]
> 
> Section 1.3.3
> 
> "... However, the conjunction of distributed architecture
> and redundant networks does allow for a sufficiently
> reliable transport of signalling traffic over IP."
> 
>     "[S]ufficiently reliable" here is highly subjective.
> 
> [Greg] Yes it is subjective.  How about "should" instead?

How about change "does allow for a sufficiently" to "provides support for".

> 
> 
> 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."
> 
>     Operators may require SGs (as they often require STPs) to be
>     "loss-less" in that a single failure will not result in the loss
>     of a message.  M3UA does not support this.
> 
> [Greg] Well, I've been around this a few times with various people.  I'm
not
> sure if there is an expectation of lossless SGs (is this a real word?) but
> there is an expectation of meeting the performance and reliability
> requirements end-to end with SGs in the path..

I think you misunderstand the performance and reliability requirements.  SS7
is allowed to lose messages because of failures.  If an SP (but more
importantly anything acting as an STP) performs a changeover and one of its
processors is not blowing smoke it had better not lose a message.

If you do not believe me, check the Q.782 conformance specification which
state as a condition of passing changeover tests to "check that no message
loss and no message missequencing occurs".

An implementation which thinks that it's good enough to drop the odd message
during changeover can be shown to fail Q.782 conformance tests.  As I'm sure
you know, in many networks, failure to meet conformance means that you don't
connect to the telephone network.

Pull out Q.782.  Its the changeover and changeback tests.

[snip]
> 
> [Greg] Done
> 
> 
> Section 1.3.3
> 
> "As an example, for a particular Application Server, the
> related ASPs SHOULD be distributed over at least two Hosts."
> 
>     Nit pick:  "SHOULD" inside an example qualitified with
>     "particular" but left unspecified has no weight.  Therefore,
>     "MAY" is more appropriate.
> 
> [Greg] I'm certainly no english major - you really lost me there  2;^)
> Anyway I think that a change to MAY weakens the statement too much - maybe
> the problem is with "As an example" or "particular"?

I would, except that the statement also presumes that a host is not, say,
hardware fault-tolerant.  How about "could" instead of "SHOULD".

> 
> 
> Figure 1:
> 
>     What was the purpose of removing SG1 and SG2 from the figure?
> 
> [Greg] It implied that an SG was a physical thing implemented on a single
> host - this might not always be the case.  An SG could be a logical thing
> formed from SGP1/Host1 and SGP1/Host2.

Yes, but it is an example drawing:  Where is the SG?

> 
> 
> Section 1.3.3
> 
> "A pair of signalling gateway processes may represent, as an
> example, a single Signalling Gateway, serving a signalling
> point management cluster."
> 
>    This is less clear than the previous text with regard to the
>    multiple SG arrangement diagrammed.  A "pair of SGP" has no
>    significance over "n SGPs".  The configuration with multiple SG
>    *is* significant.
> 
> [Greg] The only change here was to "Signalling Gateway" from "network
> appearance", which Ian and I thought didn't made sense.  How is this less
> clear?

Wasn't it "a pair of signalling gateways may represent" before?
Who cares what a pair of SGPs represents (other than an SG).

[snip]
> 
> 
> Section 1.3.3
> 
> "For carrier grade networks, the failure or isolation of a
> particular signalling process SHOULD NOT cause stable calls
> or transactions to be lost.  This implies that signalling
> processes need, in some cases, to share the call/transaction
> state or be able to pass the call state information between
> each other.  In the case of ASPs performing call processing,
> coordination may also be required with the related Media
> Gateway to transfer the MGC control for a particular trunk
> termination.  However, this sharing or communication of
> call/transaction state information is outside the scope of
> this document."
> 
>     A "SHOULD NOT" implying something which is "outside the scope of
>     this dcoument" has no weight.  This "SHOULD NOT" does not speak
>     to the interoperability of M3UA, but addresses something out of
>     scope.  It is really not the place of this document to specify
>     what operators should or should not require with regards to
>     stable calls or transactions.
> 
> [Greg] True, but this was a historical requirement from Operators on the
> system (SG/MGC/MG) and describes at a high level what has to be done to
meet
> it.  Although it really falls to the inter-ASP communication to ensure
this,
> I think the information is still useful.  The SHOULD NOT probably
shouldn't
> be capitalised.

Greg.  Read this: "SHOULD NOT cause stable calls... to be lost."

This has nothing to do with ASP-ASP communication.  There is no signalling
for a "stable call".  How on earth is M3UA (or an ASP for that matter) going
to ensure that the circuits on which people are merrily talking don't get
torn down because of what?
--the lack of no signalling?

For transaction, either the querying end got a reply, or gee, it didn't and
it is going to try again.

We are transporting MTP across IP here.

> 
> 
> 
> 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."
> 
>     The mapping of Network Appearances and SPMCs to point codes does
>     restrict the distribution algorithms and the distribution of
>     signalling processes.
> 
> [Greg] IMHO it is interconnecting to SS7 that imposes these "restrictions"
> 2;^)

So when did SS7 come up with the finite list: Override and Load-share?
That hardly catches the entire spectrum of distribution algorithms.
Also, M3UA restricts a signalling process to an SCTP endpoint, not SS7.

[snip]
> Section 1.4.1
> 
> "The SG Point Code might also used for addressing any local
> MTP3-Users at the SG such as an SG-resident SCCP function."
> 
>     This implies that a set of routing keys or routing contexts can
>     also be "local" to the SG.  When an ASP goes to register or
>     perform an ASPAC against one of these "local" routing keys, how
>     does the SG treat this?  It appears that the SG would have to
>     keep track of the state of these "local" ASPs as well...  How
>     does M3UA support this local ASP management?  The example, while
>     interesting, is confusing.
> 
> [Greg] I'm not sure why an ASP would try to register to receive SCCP
traffic
> for the SG's local SCCP layer.  Even if it was allowed, any messages
> received from the SS7 network would not see the light of day on the M3UA
> side.

What about IP address 127.0.0.1 ?

If the draft is referring to a pure SS7 MTP-User, why call it an
"SG-resident" function.  I was confusing this with something like the
"default AS/ASP".

[snip]
> 
> Section 1.4.1
> 
> "Alias Point Codes [15] may also be used within an SG
> network appearance."
> 
>     This assertion is false due to the previous discussion on
>     routing keys not spanning SPMCs (which are defined as point
>     codes).  Changing the SPMC definition (as proposed above) would
>     strengthen this assertion.
> 
> [Greg] I'm not sure why an SG would maintain an SPMC for an alias point
> code.  I thought that the SG (or any SS7 node using an alias PC) would not
> generate any MTP management messages (e.g., TFPs, TFAs) about the alias
PC.
> The alias PC is only used in the MTP discrimination function.

This was just more evidence for the change in definition of SPMC.
Don't worry about it now.

> 
> 
> Section 1.4.1
> 
> "Where an SG contains more than one SGP, the MTP3 routeset,
> SPMC and remote AS/ASP states of each SGP SHOULD be
> coordinated across all the SGPs.  Re-routing of traffic
> between the SGPs SHOULD also be supported"
> 
>     Gramar: missing period at end of second sentence.
> 
>     What is the purpose of adding this paragraph?  This attempts
>     again to impose requirements on the SG/SGP implementation (and
>     to what end?) What does one SGP care about what another SGP's
>     view of the state of an ASP which is only active with another
>     SGP?
> 
> [Greg] Not sure I follow - I thought we agreed that SGPs in an SG need to
> share state?  I think the SG cares about the state of the SGPs as it needs
> to put together an aggregate view.

The SG only needs to put together a view of the SPMC state for the SS7
network.  It does not need to know aggregate AS/ASP state.
It only has to know about the reachability of the SPMC.

[snip]
> 
> Section 1.4.1
> 
> "Where an AS can be reached via more than one SGP it is
> equally important that the corresponding Routing Keys in the
> involved SGPs are identical.  (Note: It is possible for the
> SGP Routing Key configuration data to be temporarily
> out-of-synch during configuration updates)."
> 
>     s/SG/SGP/g here has an impact.  Suddenly each SGP must have the
>     same routing keys and the associated SGs do not?  Why is it
>     important anyway?  Just the statement that it is "important" is
>     not a sufficient description of the situation.
> 
> [Greg] If all the SGPs routing to an AS have the same Routing Keys, then
any
> associated SGs are fine by definition - I'm not seeing your point.
Saying
> it is important is a bit odd I grant you.  Probably "the Routing Keys in
the
> involved SGPs should be identical" is probably what was originally meant.

No, my confusion was with "identical".  I think that it is quite acceptable
for SGP1 to support RK1, RK2, and SGP2 to support only RK3 and RK4.  What
does the text mean by "identical"?

> 
> 
> Section 1.4.1
> 
> "* Note:.  SG-to ûSG communication is recommended for
> carrier grade networks, using an MTP3 linkset or an
> equivalent, to allow re-routing between the SGs in the event
> of route failures.  Where SGPs are used, inter-SGP
> communication is recommended.  Inter-SGP protocol is outside
> of the scope of this document."
> 
>     Why can't you bring yourself to draw C-links?  They are a
>     standard part of the SS7 signalling network in quasi-associated
>     mode.  When you label the boxes "STP" you must draw C-links or
>     you will cause confusion.
> 
> [Greg] C-links are there, honest! - I tried a line between the SGs with an
> asterisk to point to the note and it just looked dumb.  I didn't have time
> to redraw the ASCII diagram so I just left the asterisk there by itself.
I
> can redraw the digram so there is a longer line later.

Use a permanent marker. ;)

> 
> 
>     In the note, it is not the place of the M3UA spec to make
>     recommendations to SS7 network operators with regard to the use
>     (or not) of C-links.  Also, what "equivalent" are you implying?
> 
> [Greg] SG-toSG and SGP-toSGP communication is recommended in the note -
> could be MTP2, M2PA, SSCOP/ATM, ...  If this is too strong I can downgrade
> it.  When nothing was shown in previous versions, I got complaints that a
> link had to to be there.  When I put it in now and say it should be there
> I'm told I shouldn't say it.  We can't have it both ways.

"MTP2, M2PA, SSCOP/ATM, ..."--just call them C-links.

> 
> 
>     Again, the draft recommends something (inter-SGP communication)
>     which is outside the scope of the document.  The draft should
>     not do this because it results in a restriction (at least a
>     should) placed on implementation specifics.  At least downgrade
>     "SHOULD" to "MAY" and "recommended" to "might be used".
> 
> [Greg] I honestly think it is useful to show the connectivity between the
> SGs or SGPs even if it the protocol used is outside the scope of this
> document.  "may" or "might' seems pretty weak to me.

This is more related to the SGP discussion.  It is perfectly possible (and
advantageous) to implement an SGP fully partitioned that has no
communication between SGP of the manner the draft is considering: MTP-user
traffic.

[snip]
> 
> Section 1.4.2.2
> 
> "Routing Keys SHOULD be unique in the sense that each
> received SS7 signalling message SHOULD have a single routing
> result to an Application Server."
> 
>     This "SHOULD" is not consistent with the concept of a "default
>     AS".  In the case of a default AS, every routing key has two
>     results: one in the case that the AS is available and the other
>     (default) in the case that the AS is unavailable.  The "SHOULD"
>     should be removed and this text made an example only.
> 
> [Greg] Which SHOULD should be removed?   2;^)

Maybe just cut "to an Application Server".

Also, this doesn't preclude RK's from overlapping.  It just precludes
"active" RK's from overlapping.  Right?

[snip]
> 
> Section 1.4.2.4
> 
> "There is, however, no M3UA messaging to manage the status
> of an SGP (e.g., SGP-Up/Down/Active/Inactive messaging).
> Whenever an SCTP association to an SGP exists, the SGP is
> assumed to be ready for the purposes of responding to M3UA
> ASPSM messages.
> 
> Every SGP of one SG ASP regarding one AS provides identical
> SS7 connectivity to this ASP."
> 
>     This is an issue which has been discussed a fair amount on the
>     list.  These to restrictions placed on the SG/SGP implementation
>     are unworkable from an number of views.
> 
>     It is clear that it cannot be the case that the SGP are treated
>     as completely equal.  An SG implementation with multiple SGP
>     will likely require that the ASP choose the SGP in a determinate
>     fashion.  It is reasonable to assume that an SGP will expect
>     only symmetrical traffic from an ASP for the Routing Key for
>     which the ASP has become active.
> 
> [Greg]  The draft doesn't say that the SGPs are treated equally, only that
> they provide equivalent connectivity to the SS7 network.  I'm also not
> convinced yet that the traffic has to be symmetrical.

No.  "identical" and "equivalent" are two completely different words.
Nevertheless, why cannot one SGP1 provide only routes to PC A and SGP2
provide only routes to PC B?  That is not "identical SS7 connectivity".

> 
> 
>     In the first sentences, the SGP cannot be considered to be ready
>     to accept SS7 traffic before the ASP has even registered.
>     Therefore, it is not just the availability of the SCTP
>     association which determines whether an SGP is available.
> 
> [Greg] It just says it is ready to accept ASPSM messages (ASP-Up/Down).  I
> don't see you point

Oooops.  Sorry.  I withdraw that.

> 
> 
>     Further, the last sentence quoted above is in direct conflict
>     with other statements in the draft which indicate that the ASP
>     must maintain the availablity and congestion of route set on a
>     per-SGP basis.  Therefore, it is possible that that ASP cannot
>     treat the SGP as providing "identical SS7 connectivity".
> 
> [Greg] I think you are reading too much into the term "connectivity".
Bing
> connected doesn't mean you are sending traffic.

No.  I am reading the word "identical".  As in twins.

[snip]
> 
>     Furthermore, there are possible implementations ("protocol
>     conversion" approaches) which are stateless and rely on the
>     state of the subtending ASPs to reflect the state of the SPMC.
>     In this case, the SGP would need to have no "knowledge" of the
>     SPMC status, yet still achieve seamless interworking.  Each
>     "must" in the quoted paragraph should be changed to "may".
> 
> [Greg] You have mentioned these "possible implementations" several times -
> I'm curious whether anybody is really implementing this?  If not it may
not
> useful to try and accomodate them.

Gee, I thought M3UA "placed no restrictions"...  I am just saying that a
"must" here is too "restrictive".  Nothing has to be done to accomodate the
possible implementation except not telling them what they "must" do in this
text.

[snip]
> 
> 
> Section 1.4.4.1
> 
> "In the process of fail-over, it is recommended that in the
> case of ASPs supporting call processing, stable calls do not
> fail.  It is possible that calls in "transition" MAY fail,
> although measures of communication between the ASPs involved
> can be used to mitigate this.  For example, the two ASPs MAY
> share call state via shared memory, or MAY use an ASP to ASP
> protocol to pass call state information.  Any ASP-to-ASP
> protocol to support this function is outside the scope of
> this document.
> 
>     Why not?  This presumes that this is an application requirement.
>     A network operator other than a regulated carrier might not care
>     if some number of stable calls fail.  This recommendation is out
>     of scope.  In many places in the draft, the draft makes such a
>     recommendation followed by the statement that it is out of
>     scope.  Out of scope recommendations should be removed or
>     converted to examples.
> 
> [Greg] As I stated before in a different way, I honestly think it is OK to
> make recommendations about things that are out of scope of the protocol
when
> they have an impact on the system and help explain how Operator
requirements
> can be met.

See previous response.  Stable calls cannot fail as a result of anything
that M3UA does.  Quite frankly, the whole SS7 network could "go away" and
stable calls could still be going along fine.

> 
> 
> Section 1.4.4.2
> 
> "Signalling Gateways MAY also be distributed over multiple
> hosts.  Much like the AS model, SGs may comprise one or more
> SG Processes (SGPs), distributed over one or more hosts,
> using an active/back-up or a load-sharing model."
> 
>     How does an ASP determine which of multiple SGPs to select?  How
>     does an ASP determine whether multiple SGPs are active/back-up
>     or load-sharing or some other algorithm?
> 
> [Greg] Configuration management

I think that we need to go a little farther here for the sake of
interoperability.  ASPs having an unknown distribution algorithm which is
completely outside the control of the SGP and hidden in the ASP is not going
to work well.  The SG designer needs to be able to make some assumptions
about the ability of the ASP to distribute traffic this way or that way.

[snip]
> 
> 
> Section 1.4.4.2
> 
> "From the perspective of the M3UA layer at an ASP, a
> particular SG is capable of transferring traffic to an SS7
> destination if an SCTP association with at least one SGP of
> the SG is established, the SGP has returned an
> acknowledgement to the ASP to indicate that the ASP is
> actively handling traffic for that destination, and the SGP
> has not indicated that the destination is inaccessible."
> 
>     There is a confusion between the destinations referred to in
>     this text.  It is not clear whether the text is talking about a
>     destination other than the ASP SPMC or whether the text is
>     talking about the ASP SPMC.  The text seems to mix both in the
>     same sentence, which is confusing.  Also, this text does not
>     explicitly take MTP restart into consideration.
> 
> [Greg] Sorry, I don't see the confusion yet.  I'm not sure how MTP Restart
> would make difference here - I hae to think about that one.

The last "destination" could refer to the SPMC.  Perhaps "remote
desintation" would make the sentence even longer and more confusing.

With regard to MTP Restart, during MTP Restart there can be an association
between an ASP and an SGP which is ASP-ACTIVE and has not received DUNA for
any destination; however, the ASP is still incapable of transferring traffic
to *any* SS7 destination.

> 
>     For security reasons and in consideration of gateway screening
>     at the SG, it might not be advisable for the ASP to consider all
>     SS7 destinations as accessible by default: only those
>     destinations to which it has a route.
> 
> [Greg] Again, I'm not sure I follow this -  Maybe it is too obvious  2;^).

I'll say again: an ASP can have an association with an SGP, and be in
ASP-ACTIVE state with regard to that SGP, and have received no DUNA for
point code foo.  That doesn't mean that the ASP is capable of transferring
traffic to point code foo.
The SGP may be offering no routes to point code foo to the ASP because it is
some international point code on a mountain in Chile.

Make "transferring traffic to an SS7 destination" read

"transferring traffic to a provisioned SS7 destination".

And add to the long sentence ", and the SG has not indicated MTP Restart."

Changing the three occurences of "destination" to "destination X" and it
will be clear that they are all the same "destination".

[snip]
> 
> Section 1.5.1
> 
>     The diagram shows the NIF as being above the MTP3 interface and
>     above a (non-specified) M3UA interface.  This does not
>     correspond to the text which requires that the NIF interact with
>     MTP routing functions and even interact with SCTP at the
>     management level.  It would be more accurate to show the NIF as
>     between the stacks as follows:
> 
>   ********   SS7   *****************   IP   ********
>   * SEP  *---------*      SGP      *--------* ASP  *
>   ********         *****************        ********
> 
>   +------+       +-------------------+      +------+
>   | ISUP |       |                   |      | ISUP |
>   +------+       +------+ NIF +------+      +------+
>   | MTP3 |       | MTP3 |     | M3UA |      | M3UA |
>   +------|       +------+-+   +------+      +------+
>   | MTP2 |       | MTP2 |  \  | SCTP |      | SCTP |
>   +------+       +------+   +-+------+      +------+
>   |  L1  |       |  L1  |     |  IP  |      |  IP  |
>   +------+       +------+     +------+      +------+
>       |_____________|             |____________|
> 
>     SEP - SS7 Signalling End Point
>     SCTP - Stream Control Transmission Protocol
>     NIF - Nodal Inter-working Function
> 
> 
> [Greg] OK.  Not sure about the NIF interacting with the SCTP at the
> management level though.

E.g, M-SCTP_ESTABLISH.

> 
> 
> Section 3.1.2
> 
>          "4        SS7 Network Congestion (SCON)"
> 
>     SS7 Network Congestion is no longer a good description.  This
>     message is also used to indicate nodal congestion at the ASP.
> 
> [Greg] Do you have a more decriptive name?

How about "Signalling Congestion"--still fits the acronym.

[snip]
> 
> 
> Section 4.3.1
> 
> "DUNA, DAVA, SCON, and DRST messages MUST be sent
> sequentially and processed at the receiver in the order
> sent.  SCTP stream "0" is used to provide the sequencing.
> The only exception to this is if the international
> congestion method (see Q.704) is used.  If so, the Unordered
> bit in the SCTP DATA chunk MAY be used for the SCON
> message."
> 
>     Even SS7 permits TFA/TFR/TFP/TFC to be sent unsequenced.  This
>     is because there are responsive procedures which will soon
>     correct a reversal of the messages.  For congestion, adequate
>     hysteresis is provided to avoid problems due to message
>     reversal.  This text should be reworded to reflect this
>     situation.  The "MUST" should be changed to a "MAY" and the
>     reference to international congestion removed.
> 
> [Greg] I don't see any harm in enforcing the sequencing of these messages.
> Then we don't have to worry about reversal.

They can be reversed in the SS7 network before they even get to M3UA.  SS7
does not impose this restriction, why say "MUST" for M3UA?  I would think
that it may be very advantageous to send them out of order on SCTP
implementation which will expedite them around ordered messages on the same
stream.  The faster they get to the ASP the better.  The "MUST" is
unjustified.

[snip]
> 
> 
> Section 4.3.3
> 
> "In the first of the cases above, the auditing  procedure
> must not be invoked for the case of a received SCON message
> containing a congestion level value of "no congestion" or
> undefined" (i.e., congestion Level = "0"). ...
> 
>     What is the draft trying to get at here?
> 
> [Greg] There can be no audit as in this case the SG does not maintain
> congestion status.

Huh?  Why doesn't it?

> 
> 
> Section 4.3.3
> 
> "The SGP MUST respond to a DAUD message with the MTP3
> availability/congested status of the routeset associated
> with each Destination Point Code(s) in the DAUD message.
> ..."
> 
>     This is problematic in the case that the DAUD message if for a
>     destination to which the SGP has no route (as opposed to a
>     destination to which the SGP has a route, but which is currently
>     unavailable).
> 
> [Greg] Sorry - I'm confused.  What are you saying?

The DAUD is for that point code on the mountain in Chile that no ASP is
allowed to query the state of or send messages to (even though the SG
receives TFP/TFA for them).
The SG needs a way to refuse to answer an DAUD for a point code that the ASP
is not authorized to audit the state of.

Consider M3UA as a demarcation point.

> 
> This is also a security issue in that an ASP
>     should not be empowered to be able to inquire as to the status
>     of all possible destinations: only destinations to which the ASP
>     has authorized routes.
> 
> 
> [Greg] I don't know how you can restrict an ASP to enquiring only about
> certain destinations.  The SG can protect itself by not responding I
guess.

The SG cannot refuse to respond unless the draft releases the "MUST" above.

> 
> Grammar:
> 
>     Section 1.3.2.4, first paragraph, change "in order to" to "to".
>     Section 1.3.2.4, second paragraph, change "In order to" to "to".
>     Section 1.4.2.4, first paragraph, change "In order to" to "To".
>     Section 1.4.2.5, first paragraph, change "In order to" to "To"
>     and "in order to" to "to".
>     Section 1.4.3.2, second paragraph, change both instances of "in
>     order to" to "to".
>     Section 1.4.4, first paragraph, change "in order to" to "to".
>     Section 1.4.5, first paragraph, change "in order to" to "to".
>     Section 1.4.7, second paragraph, change "in order to" to "to".
>     Section 3.4.1, first paragraph, change "in order to" to "to".
>     Section 3.4.4, sixth paragraph, change "in order to" to "to".
>     Section 3.8.2, fifteenth paragraph, change "in order to" to "to".
>     Section 4.2.3.4, sixteenth paragraph, change "in order to" to "to".
>     Section 4.3.3, first paragraph, change "in order to" to "to".
> 
> [Greg] Yes - a very bad habit of mine (and peeve or yours?)

Nope.  A bad habit of mine too.  I'm on the program: can you tell? :)

> 
> Thanks Brian for all the comments!
> 
> Cheeeers,
> 
>   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]

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 20 Jul 2001 10:32:53 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: John Loughney <[email-masked]>
Subject: Re: SUA-06: Segmentation/Reassembly/Sequencing
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

John Loughney wrote:                         (Fri, 20 Jul 2001 15:49:17)
> Brian,
> 
> I don't think we can completely resolve this before I re-issue the
> draft.

Issues for last call?

> 
> Some questions / comments:
> 
> > Segmentation of CLDT messages into (XL)UDT messages at the SG
> > requires the use of a source segmentation reference number which the
> > SG is difficult to impossible for the SG to generate.  Because the
> > SG is really a transfer node in this case, it should follow the LUDT
> > procedures from Q.714: i.e., if the ASP generates a message larger
> > than X-bytes (X is usually 255), it must pass a source segmentation
> > reference number to the SG with the CLDT message for use in
> > segmentation.
> > 
> > This means that we need a optional source segmentation reference
> > parameter in the CLDT message which MUST be included when the data
> > payload of the CLDT exceeds X-bytes (configurable per Network
> > Appearance).
> 
> If we remove the network appearance, and use only Routing Context,
> how would you like to handle this?  Do we specify the Routing
> Context to be a combination of a the range of traffic & network ID
> that an ASP handles within an AS?

What has that to do with segmentation?  Nevertheless, I think that a range
of traffic implicitly defines a network ID.  As Joyce pointed out, Network
Appearance should stick around for the REG REQ message.
(SUA doesn't have one of those, though).

> 
> -- bunch of things clipped --
> 
> > To recap:
> > 
> > 	o   it is still the SGs responsibility to perform
> > 	    segmentation/reassembly of (XL)UDT messages to
> > 	    and from the ASP, but,
> > 
> > 	o   the ASP must include a new source segmentation
> > 	    number in the CLDT message when it sends large
> > 	    data payloads, and,
> > 
> > 	o   it becomes the ASPs responsibility to do
> > 	    sequencing/segmenting and segmenting/reassembly in
> > 	    both directions for CODT messages.
> 
> My gut reaction is that I don't think designing for the
> decoupled case is really my goal.  

How is your design going to handle arbitrarily large NSDUs?

> 
> I'm going to have to think about this a bit more - 
> if you want to propose text, I will be more than happy
> to consider it.

I'll propose text.

> 
> John
> 
> 
> ---
> 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: Fri, 20 Jul 2001 10:45:18 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: SUA-06: Segmentation/Reassembly/Sequencing
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Vakul,

[email-masked] wrote:                                  (Fri, 20 Jul 2001
18:32:53)
> 
> 
> John
> 
> I am not able to userstand the very basic question,
> why SUA should support segmentation/reassembly
> of messages when it is implicitly being provided by
> the userlying transport layer SCTP. I have followed
> the older mails exchanged on this topic and could
> figure out that it is being supported for two reasons:
> 
> 1. SCCP at SG should not wait for all the messages
> for reassembly and subsequent delivery to upper
> layer because it may lead to delays in transport
> of messages to ASP.

True for connection-oriented, false for connection-less.
A connection-less data transfer is a "unit" data transfer.  The NSD does not
support partial-delivery of unitdata and must wait for the last segment.

> 
> For e.g. if segmented XUDT messages are received
> at SG, SCCP at SG may reassemble them and give
> whole of the combined message to SUA or it may
> give individual segmented XUDT messages
> which will get reassembled at SUA at ASP.

Bad example.  An SS7 relay point (STP) must fragment LUDT messages into XUDT
when interworking between broadband and narrowband links.  The SS7 part of
the SG might have to support this anyway.

Read the SCCP specs.  For N-UNITDATA, the procedure require that the SCCP
reassemble XUDT before delivery to the user.  This is becase NSD N-UNITDATA
does not support partial delivery (as most UDP sockets don't do partial even
though they are allowed to).

However, for DT1 and DT2, N-DATA does support partial delivery (with a more
flag, much like the use of MSG_EOR in SCTP socket).

Your argument holds for connection-oriented.

> 
> 2. SCTP at ASP may also deliver partial messages
> to SUA due to which it will have to support reassembly.

Huh?

> 
> 
> Which primitive SCCP provides for delivery of segmented
> messages to upper layer?

N-DATA supports partial delivery.

N-UNITDATA and N-EXPEDITED-DATA do not.  But ED doesn't fragment anyway.

> 
> As partial delivery of SCTP is concerned, any SCTP application
> should support it and this may not be the motivation behind
> supporting segmentation in SUA.
> 

-- 
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]
To: "sigtran" <[email-masked]>
Date: Fri, 20 Jul 2001 08:47:26 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Mailer: MailCity Service
Subject: Re: M3UA07 Comments
X-Sender-Ip: 63.96.78.21
Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80)
X-SMTP-HELO: shared1-mail.whowhere.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.185.123.82]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Just a note - once approved out of this group, the document goes through
another round of comments in IETF Last Call (although the main comments
should have been resolved by then).

Assuming it is approved, the document (or a version incorporating comments)
then gets a going over by the RFC Editor, which will probably catch a lot of
nits if previous experience holds true :o)

L. Ong 
--

On Fri, 20 Jul 2001 10:21:33   Brian F. G. Bidulock wrote:
>Greg,
>
>Ok, while your wrapping it up, let me first hit ONE BIT NIT:
>
>   Runaway hyphenation throughout the document:
>
>	`Backup'         is one word, not `back-up'.
>	`Reroute'        is one word, not `re-route'.
>	`Unidirectional' is one word, not `uni-directional'.
>	`Unordered'      is one word, not `un-ordered'.
>	`Interworking'   is one word, not `inter-working'.
>	`Reassembly'     is one word, not `re-assembly'.
>	`Rerouting'      is one word, not `re-routing'.
>	`Ongoing'        is one word, not `on-going'.
>	`Deregister' is not a word.  `Unregister' is the opposite of
>		  `register'.  But I suppose we are stuck with it: but if it
>		  *was* a word, it would not be `de-register' as `de' is
>		  normally only hyphenated before a word starting with `e'
as
>		  in `de-energized'.)
>	`Deregistration' not `de-registration'.
>	`Override'       is one word, not `over-ride'.
>	`Overriding'     is one word, not `over-riding'.
>	`Lockout'        is one word, not `lock-out'.
>	`Setup'          is one word, not `set-up'.
>	`Preconfigured'  is one word, not `pre-configured'.
>	`Reestablish'    is one word, not `re-establish'.
>	`Reallocated'    is one word, not `re-allocated'.
>	`Unconfigured'   is one word, not `un-configured'.
>	`Unsequenced'    is one word, not `un-sequenced'.
>	`Redirect'       is one word, not `re-direct'.
>
>Can you run the document through a spell-checker and
>grammar-checker before-releasing-it-as-an-RFC? ;)
>
>Follow-up comments below...
>
>
>
>Greg Sidebottom wrote:                                       (Fri, 20 Jul
2001 06:12:29)
>
>[snip]
>> "an active or standby" was changed to "active or back-up"
>> 
>>     Why?
>> 
>> [Greg] So as not to confuse with the standby traffic mode
>
>Ok.  But its `backup'... ;)
>
>> Section 1.2 Terminology, fifteenth paragraph (Network Appearance
>> definition):
>> 
>> "This partitioning is necessary where an SG is logically
>> partitioned to appear as end node elements in multiple
>> separate SS7 networks, in which case there is a separate
>> network appearance for each point code in the SS7 networks."
>> 
>>     and
>> 
>> "It is also necessary when an SG is configured as an STP
>> hosting multiple point codes, or when configured as multiple
>> end nodes within the same network, in which case each point
>> code is a separate network appearance.between the SG and the
>> Application Server Processes over a common SCTP
>> Association."
>> 
>>     This implies that separate network appearances are required for
>>     both multiple and "alias" point codes, meaning that a separate
>>     AS is required for each point code, even though the same set of
>>     MTP3 management procedures may apply to the entire set.
>>     Definitely this language is somewhat confusing.  Suggest
>>     something more like the following:
>> 
>> Network Appearance - The Network Appearance uniquely
>> identifies one SS7 network of multiple disjoint SS7 networks
>> in which an SPMC resides.
>> 
>> [Greg] It was an agreement on the list, and changed in Issue 7, to have
>> separate Network Appearances for each point code even if they could be
>> considered as in the same SG network partition.  Your above definition is
>> actually pretty close to the previous definition.  See the thread started
by
>> Norm Glaude in January for a description.  It was agreed on the list to
line
>> up the definitions between the SUA and M3UA
>
>Ok.  Sorry I missed that.
>
>
>[snip[
>> 
>> [Greg] Your proposal is missing here  2:^0   I changed it to:
>> 
>> "Within the framework architecture, this document defines an MTP3-User
>> adaptation module suitable for supporting the transfer of messages of any
>> protocol layer that is identified to the MTP Level 3 as an MTP User."
>
>That's fine.
>
>> 
>> 
>> Section 1.3.1 Protocol Architecture
>> 
>> "- Sequenced delivery of user messages within multiple
>> streams, with an option for order-of-arrival delivery of
>> individual user messages,"
>> 
>>     M3UA does not utilize order-of-arrival delivery and this aspect
>>     of SCTP cannot be taken avantage of by using SCTP as a transport
>>     for M3UA.
>> 
>> [Greg] Some SSNM messages are allowed to be sent unsequenced (DAUD,
SCON?).
>> If they are sent unsequenced I assume that this feature would be used.
>
>Yes.  Sorry.  I noticed that after I sent this off...
>
>> 
>> 
>> Section 1.3.1 Protocol Architecture
>> 
>> "- Optional multiplexing of user messages into SCTP
>> datagrams,"
>> 
>>     It is not clear how M3UA can utilize this optional feature of
>>     SCTP.
>> 
>> [Greg] An SCTP User can request bundling, which I assume is what is meant
by
>> multiplexing here.  The M3UA doesn't state when to use bundling but it
could
>> use it.  I assume this would be an operational decision, not a protocol
>> decision.
>> 
>> 
>> Section 1.3.1 Protocol Architecture
>> 
>> "- Network-level fault tolerance through support of
>> multi-homing at either or both ends of an association,"
>> 
>>     SCTP multi-homing can be used by a specific implementation and a
>>     specific configuration to support network-level fault tolerance,
>>     but SCTP does not provide this in itself.  M3UA does not get
>>     network- level fault tolerance merely by using SCTP as a
>>     transport, nor necessarily by merely using SCTP's multi-homing
>>     feature.
>> 
>> [Greg] This is just a lshort isting of an SCTP feature - directly from
the
>> SCTP spec.  Yes there are configuration and implementation decisions to
make
>> it work but I don't hink it is necessary to describe that here.
>
>I wish it would have been left in the SCTP spec, where it came from.
>
>> 
>> 
>> Section 1.3.1 Protocol Architecture
>> 
>> "Under certain scenarios, such as back-to-back connections
>> without redundancy requirements, the SCTP functions above
>> MAY NOT be a requirement and TCP can be used as the
>> underlying common transport protocol."
>> 
>>     Should an implementation support TCP as well?
>> 
>> [Greg] No recommendation is made - it is up to the implementor.  The
>> sentence just "allows" some implementations to use TCP if they like.
>
>It's just the weird use of "MAY NOT" and "TCP can".
>
>Might I suggest that it change to "might not" and "TCP MAY".
>
>"MAY NOT be a requirement" is giving permission for the lack of
>a requirement. :]
>
>> 
>> 
>> Section 1.3.2
>> 
>> "The M3UA layer does not itself provide the MTP3 services.
>> However, in the case where an ASP is connected to more than
>> one SGP, the M3UA layer at an ASP must maintain the status
>> of configured SS7 destinations and route messages according
>> to the availability and congestion status of the routes to
>> these destinations via each SGP."
>> 
>>     In this text "SG" from version 6 has been changed to "SGP" in
>>     version 7.  This has the negative impact that this text requires
>>     that when the ASP is connected to more than one SGP, the ASP is
>>     required to maintain SS7 routing information on a per-SGP basis
>>     rather than a per-SG basis.  Although both cases are valid, it
>>     represents a significant departure from the version 6 model.
>> 
>> [Greg] Yes but this was as agreed on the list.  There is a thread on the
>> list revisiting this so I will defer to the thread on the list.
>
>That's ok, this note is oooold.
>
>> 
>> 
>>     For example, what does an SGP do with tranfer messages for which
>>     it has no route?  In the version 6 situation, it is clear that
>>     if the SG has a route, the SGP either deals with messages for
>>     that route (or take itself out of service).  Now it is not so
>>     clear.
>> 
>> [Greg] Sorry I'm not following this example.
>
>Before if an SGP could not route messages sent to it, it was a "MUST"
>that it drop the association.  I think this is handled now with the
>inter-SGP communication recommendation and per-SGP routes.  Leave it
>for the other discussion.  The other discussion didn't start until
>I sent this.
>
>> 
>> 
>>     Also, the "must" here means what?  Does it mean MUST?
>> 
>> [Greg] probably should be a MUST or SHOULD, depending on the outcome of
the
>> thread on the list
>
>Agreed.
>
>> 
>> 
>> Section 1.3.2.1
>> 
>> "The MTP-TRANSFER primitive information is encoded as in
>> MTP3-User messages.  In this way, the SCCP and ISUP messages
>> received from the SS7 network by the SGP are not re-encoded
>> into a different format for transport between the M3UA
>> peers.  The MTP3 Service Information Octet (SIO) and Routing
>> Label (OPC, DPC, and SLS) are included, encoded as expected
>> by the MTP3 and MTP3-User protocol layer."
>> 
>>     As discussed on the list, many MTP-User interfaces pass routing
>>     label information as parameters, which must then be "re-encoded"
>>     at the SG before transport to the ASP and "re-decoded" at the
>>     ASP to pass to the MTP-User.  This issue has not yet been
>>     addressed.
>> 
>> [Greg] I'll leave this to conclude on the list - I may be slow but so far
I
>> don't see a consensus.
>
>I don't recall any objections.
>
>> 
>> 
>> Section 1.3.2.1
>> 
>> "At an ASP, in the case where a destination is reachable via
>> multiple SGPs, the M3UA layer must also choose via which SGP
>> the message is to be routed or support load balancing across
>> the SGPs, ensuring that no missequencing occurs."
>> 
>>     M3UA in its current trim does not support the requirement that
>>     the ASP ensure that "no missequencing occurs".  Also, no
>>     procedure is given in M3UA to select an SGP from multiple SGPs
>>     for which the destination is available.  The management of SGPs
>>     at he ASP is an outstanding and significant issue.
>> 
>> [Greg] Well we need a proposal then.  I assume some part of this falls
out
>> from the SG/SGP thread on the list (SG versus SGP view for SSNM
messaging).
>> I assume that the SLS is used just like in MTP3 for link selection,
taking
>> into account the remote SGP availability status.  And I agree with your
>> point on the list about the need for controlled rerouting.  The
implementors
>> I have talked to seem to understand this but we probably need a section
to
>> describe this.  I don't really want to get into re-interpretting MTP3
>> procedures though - maybe we could provide a set of guidelines instead?
>
>You get me wrong.  I had a problem with
>
>       "must" "ensur[e]" "that no missequencing occurs"
>
>"ensure" is a strong word.  Say, "minimizing missequencing".
>
>Oh, by the way, elsehwhere in the document "mis-sequencing" should
>be changed to "missequencing".
>
>> 
>> 
>> Section 1.3.2.1
>> 
>> "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."
>> 
>>     This is also true for Q.703 Annex A operation which is cited as
>>     only supporting 272-octets as cited in [14] at the beginning of
>>     this paragraph.  Citing specific SS7 refererences here is of
>>     little use as the need for M3UA to respect maximum SIF sizes
>>     depends upon the implementation and the network configuration.
>> 
>> [Greg] I understand but I'm not sure what you would like changed - you
want
>> to remove the refernce to MTP3b?
>
>What I'm saying is that the statement is not really correct.  It might
>be if it said "provisioned to *only* support the Broadband MTP".
Otherwise,
>the interworking procedures specified in the standards should be used.
>And, I'm saying that this is not the only case that SIF size is larger:
>the other instances are conspicuous by their absence.  I would like to
>see:
>
>    "The provisioning and configuration of the SS7 network
>     determines the restriction placed on the maximum
>     information block size.  Some configurations (e.g,
>     Broadband MTP [20]) may permit larger block sizes."
>
>[snip]
>> 
>> Section 1.3.2.3
>> 
>> "At the SGP, the M3UA layer must also provide inter-working
>> with MTP3 management functions to support seamless operation
>> of the user SCN signalling applications in the SS7 and IP
>> domains."
>> 
>>     This statement places a requirement (or an objective) on M3UA.
>>     It is arguable whether M3UA can "support seamless operation fo
>>     the user SCN signalling applications in the SS7 and IP domains".
>> 
>> [Greg] Like you say, it is a requirement or objective - time will tell if
we
>> are successful
>
>Assume we are successful.  Say:
>
>  "At the SGP, the M3UA layer provides interworking..."
>
>That is, don't way what it "must provide," say what it "provides,"
>whether that is an opinion of its authors or not.
>
>> 
>> 
>> Section 1.3.2.3
>> 
>> "- Providing an indication to MTP3-Users at an ASP that a
>>    remote destination in the SS7 network is not reachable.
>> 
>> - Providing an indication to MTP3-Users at an ASP that a
>>    remote destination in the SS7 network is now reachable.
>> 
>> - Providing an indication to MTP3-Users at an ASP that
>>    messages to a remote destination in the SS7 network are
>>    experiencing SS7 congestion.
>> 
>> - Providing an indication to the M3UA layer at an ASP that
>>    the routes to a remote destination in the SS7 network are
>>    restricted.
>> 
>> - Providing an indication to MTP3-Users at an ASP that a
>>    remote MTP3- User peer is unavailable.
>> 
>>     The words "remote destination" here is confusing.  A local or
>>     adjacent destination can also become unreachable and can also
>>     experience congestion.
>> 
>> [Greg] I removed "remote" - assuming that helps.
>
>Yes.
>
>> 
>> 
>> 
>> Section 1.3.2.4
>> 
>> "The M3UA layer at the SGP maintains the availability state
>> of all configured remote ASPs, in order to manage the SCTP
>> Associations and the traffic between the M3UA peers.  As
>> well, the active/inactive and congestion state of remote
>> ASPs is maintained."
>> 
>>    SG changed to SGP has different meaning here.  Now it appears
>>    that it is each SGP's responsibility to maintain the state of all
>>    remote ASPs.  It also means that an ASP can be active for one SGP
>>    and inactive for another.  Although not necessarily incorrect,
>>    this is substantially different from the version 6 text.
>> 
>> [Greg] Yes.  I'm not sure that an SGP would have a different view than
other
>> SGPs of the active/inactive state of an ASP - except maybe in a
transitory
>> sense.
>
>Well, an ASP appears free to move to the inactive or down state
>with one SGP, but stay active with another.  Also, one SGP may
>have a downed association with an ASP whereas another SGP does
>not and the ASP is active.
>
>[snip]
>> 
>> Section 1.3.3
>> 
>> "... However, the conjunction of distributed architecture
>> and redundant networks does allow for a sufficiently
>> reliable transport of signalling traffic over IP."
>> 
>>     "[S]ufficiently reliable" here is highly subjective.
>> 
>> [Greg] Yes it is subjective.  How about "should" instead?
>
>How about change "does allow for a sufficiently" to
>"provides support for".
>
>> 
>> 
>> 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."
>> 
>>     Operators may require SGs (as they often require STPs) to be
>>     "loss-less" in that a single failure will not result in the loss
>>     of a message.  M3UA does not support this.
>> 
>> [Greg] Well, I've been around this a few times with various people.  I'm
not
>> sure if there is an expectation of lossless SGs (is this a real word?)
but
>> there is an expectation of meeting the performance and reliability
>> requirements end-to end with SGs in the path..
>
>I think you misunderstand the performance and reliability
>requirements.  SS7 is allowed to lose messages because of
>failures.  If an SP (but more importantly anything acting
>as an STP) performs a changeover and one of its processors
>is not blowing smoke it had better not lose a message.
>
>If you do not believe me, check the Q.782 conformance
>specification which state as a condition of passing
>changeover tests to "check that no message loss and no
>message missequencing occurs".
>
>An implementation which thinks that it's good enough to
>drop the odd message during changeover can be shown to
>fail Q.782 conformance tests.  As I'm sure you know,
>in many networks, failure to meet conformance means that
>you don't connect to the telephone network.
>
>Pull out Q.782.  Its the changeover and changeback tests.
>
>[snip]
>> 
>> [Greg] Done
>> 
>> 
>> Section 1.3.3
>> 
>> "As an example, for a particular Application Server, the
>> related ASPs SHOULD be distributed over at least two Hosts."
>> 
>>     Nit pick:  "SHOULD" inside an example qualitified with
>>     "particular" but left unspecified has no weight.  Therefore,
>>     "MAY" is more appropriate.
>> 
>> [Greg] I'm certainly no english major - you really lost me there  2;^)
>> Anyway I think that a change to MAY weakens the statement too much -
maybe
>> the problem is with "As an example" or "particular"?
>
>I would, except that the statement also presumes that a host
>is not, say, hardware fault-tolerant.  How about "could"
>instead of "SHOULD".
>
>> 
>> 
>> Figure 1:
>> 
>>     What was the purpose of removing SG1 and SG2 from the figure?
>> 
>> [Greg] It implied that an SG was a physical thing implemented on a single
>> host - this might not always be the case.  An SG could be a logical thing
>> formed from SGP1/Host1 and SGP1/Host2.
>
>Yes, but it is an example drawing:  Where is the SG?
>
>> 
>> 
>> Section 1.3.3
>> 
>> "A pair of signalling gateway processes may represent, as an
>> example, a single Signalling Gateway, serving a signalling
>> point management cluster."
>> 
>>    This is less clear than the previous text with regard to the
>>    multiple SG arrangement diagrammed.  A "pair of SGP" has no
>>    significance over "n SGPs".  The configuration with multiple SG
>>    *is* significant.
>> 
>> [Greg] The only change here was to "Signalling Gateway" from "network
>> appearance", which Ian and I thought didn't made sense.  How is this less
>> clear?
>
>Wasn't it "a pair of signalling gateways may represent" before?
>Who cares what a pair of SGPs represents (other than an SG).
>
>[snip]
>> 
>> 
>> Section 1.3.3
>> 
>> "For carrier grade networks, the failure or isolation of a
>> particular signalling process SHOULD NOT cause stable calls
>> or transactions to be lost.  This implies that signalling
>> processes need, in some cases, to share the call/transaction
>> state or be able to pass the call state information between
>> each other.  In the case of ASPs performing call processing,
>> coordination may also be required with the related Media
>> Gateway to transfer the MGC control for a particular trunk
>> termination.  However, this sharing or communication of
>> call/transaction state information is outside the scope of
>> this document."
>> 
>>     A "SHOULD NOT" implying something which is "outside the scope of
>>     this dcoument" has no weight.  This "SHOULD NOT" does not speak
>>     to the interoperability of M3UA, but addresses something out of
>>     scope.  It is really not the place of this document to specify
>>     what operators should or should not require with regards to
>>     stable calls or transactions.
>> 
>> [Greg] True, but this was a historical requirement from Operators on the
>> system (SG/MGC/MG) and describes at a high level what has to be done to
meet
>> it.  Although it really falls to the inter-ASP communication to ensure
this,
>> I think the information is still useful.  The SHOULD NOT probably
shouldn't
>> be capitalised.
>
>Greg.  Read this: "SHOULD NOT cause stable calls... to be lost."
>
>This has nothing to do with ASP-ASP communication.  There is no
>signalling for a "stable call".  How on earth is M3UA (or an
>ASP for that matter) going to ensure that the circuits on which
>people are merrily talking don't get torn down because of what?
>--the lack of no signalling?
>
>For transaction, either the querying end got a reply, or gee,
>it didn't and it is going to try again.
>
>We are transporting MTP across IP here.
>
>
>> 
>> 
>> 
>> 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."
>> 
>>     The mapping of Network Appearances and SPMCs to point codes does
>>     restrict the distribution algorithms and the distribution of
>>     signalling processes.
>> 
>> [Greg] IMHO it is interconnecting to SS7 that imposes these
"restrictions"
>> 2;^)
>
>So when did SS7 come up with the finite list: Override and Load-share?
>That hardly catches the entire spectrum of distribution algorithms.
>Also, M3UA restricts a signalling process to an SCTP endpoint, not SS7.
>
>[snip]
>> Section 1.4.1
>> 
>> "The SG Point Code might also used for addressing any local
>> MTP3-Users at the SG such as an SG-resident SCCP function."
>> 
>>     This implies that a set of routing keys or routing contexts can
>>     also be "local" to the SG.  When an ASP goes to register or
>>     perform an ASPAC against one of these "local" routing keys, how
>>     does the SG treat this?  It appears that the SG would have to
>>     keep track of the state of these "local" ASPs as well...  How
>>     does M3UA support this local ASP management?  The example, while
>>     interesting, is confusing.
>> 
>> [Greg] I'm not sure why an ASP would try to register to receive SCCP
traffic
>> for the SG's local SCCP layer.  Even if it was allowed, any messages
>> received from the SS7 network would not see the light of day on the M3UA
>> side.
>
>What about IP address 127.0.0.1 ?
>
>If the draft is referring to a pure SS7 MTP-User, why call it
>an "SG-resident" function.  I was confusing this with something
>like the "default AS/ASP".
>
>[snip]
>> 
>> Section 1.4.1
>> 
>> "Alias Point Codes [15] may also be used within an SG
>> network appearance."
>> 
>>     This assertion is false due to the previous discussion on
>>     routing keys not spanning SPMCs (which are defined as point
>>     codes).  Changing the SPMC definition (as proposed above) would
>>     strengthen this assertion.
>> 
>> [Greg] I'm not sure why an SG would maintain an SPMC for an alias point
>> code.  I thought that the SG (or any SS7 node using an alias PC) would
not
>> generate any MTP management messages (e.g., TFPs, TFAs) about the alias
PC.
>> The alias PC is only used in the MTP discrimination function.
>
>This was just more evidence for the change in definition of SPMC.
>Don't worry about it now.
>
>> 
>> 
>> Section 1.4.1
>> 
>> "Where an SG contains more than one SGP, the MTP3 routeset,
>> SPMC and remote AS/ASP states of each SGP SHOULD be
>> coordinated across all the SGPs.  Re-routing of traffic
>> between the SGPs SHOULD also be supported"
>> 
>>     Gramar: missing period at end of second sentence.
>> 
>>     What is the purpose of adding this paragraph?  This attempts
>>     again to impose requirements on the SG/SGP implementation (and
>>     to what end?) What does one SGP care about what another SGP's
>>     view of the state of an ASP which is only active with another
>>     SGP?
>> 
>> [Greg] Not sure I follow - I thought we agreed that SGPs in an SG need to
>> share state?  I think the SG cares about the state of the SGPs as it
needs
>> to put together an aggregate view.
>
>The SG only needs to put together a view of the SPMC state for
>the SS7 network.  It does not need to know aggregate AS/ASP state.
>It only has to know about the reachability of the SPMC.
>
>[snip]
>> 
>> Section 1.4.1
>> 
>> "Where an AS can be reached via more than one SGP it is
>> equally important that the corresponding Routing Keys in the
>> involved SGPs are identical.  (Note: It is possible for the
>> SGP Routing Key configuration data to be temporarily
>> out-of-synch during configuration updates)."
>> 
>>     s/SG/SGP/g here has an impact.  Suddenly each SGP must have the
>>     same routing keys and the associated SGs do not?  Why is it
>>     important anyway?  Just the statement that it is "important" is
>>     not a sufficient description of the situation.
>> 
>> [Greg] If all the SGPs routing to an AS have the same Routing Keys, then
any
>> associated SGs are fine by definition - I'm not seeing your point.
Saying
>> it is important is a bit odd I grant you.  Probably "the Routing Keys in
the
>> involved SGPs should be identical" is probably what was originally meant.
>
>No, my confusion was with "identical".  I think that it is
>quite acceptable for SGP1 to support RK1, RK2, and SGP2 to
>support only RK3 and RK4.  What does the text mean by
>"identical"?
>
>> 
>> 
>> Section 1.4.1
>> 
>> "* Note:.  SG-to {SG communication is recommended for
>> carrier grade networks, using an MTP3 linkset or an
>> equivalent, to allow re-routing between the SGs in the event
>> of route failures.  Where SGPs are used, inter-SGP
>> communication is recommended.  Inter-SGP protocol is outside
>> of the scope of this document."
>> 
>>     Why can't you bring yourself to draw C-links?  They are a
>>     standard part of the SS7 signalling network in quasi-associated
>>     mode.  When you label the boxes "STP" you must draw C-links or
>>     you will cause confusion.
>> 
>> [Greg] C-links are there, honest! - I tried a line between the SGs with
an
>> asterisk to point to the note and it just looked dumb.  I didn't have
time
>> to redraw the ASCII diagram so I just left the asterisk there by itself.
I
>> can redraw the digram so there is a longer line later.
>
>Use a permanent marker. ;)
>
>> 
>> 
>>     In the note, it is not the place of the M3UA spec to make
>>     recommendations to SS7 network operators with regard to the use
>>     (or not) of C-links.  Also, what "equivalent" are you implying?
>> 
>> [Greg] SG-toSG and SGP-toSGP communication is recommended in the note -
>> could be MTP2, M2PA, SSCOP/ATM, ...  If this is too strong I can
downgrade
>> it.  When nothing was shown in previous versions, I got complaints that a
>> link had to to be there.  When I put it in now and say it should be there
>> I'm told I shouldn't say it.  We can't have it both ways.
>
>"MTP2, M2PA, SSCOP/ATM, ..."--just call them C-links.
>
>> 
>> 
>>     Again, the draft recommends something (inter-SGP communication)
>>     which is outside the scope of the document.  The draft should
>>     not do this because it results in a restriction (at least a
>>     should) placed on implementation specifics.  At least downgrade
>>     "SHOULD" to "MAY" and "recommended" to "might be used".
>> 
>> [Greg] I honestly think it is useful to show the connectivity between the
>> SGs or SGPs even if it the protocol used is outside the scope of this
>> document.  "may" or "might' seems pretty weak to me.
>
>This is more related to the SGP discussion.  It is perfectly
>possible (and advantageous) to implement an SGP fully
>partitioned that has no communication between SGP of the manner
>the draft is considering: MTP-user traffic.
>
>[snip]
>> 
>> Section 1.4.2.2
>> 
>> "Routing Keys SHOULD be unique in the sense that each
>> received SS7 signalling message SHOULD have a single routing
>> result to an Application Server."
>> 
>>     This "SHOULD" is not consistent with the concept of a "default
>>     AS".  In the case of a default AS, every routing key has two
>>     results: one in the case that the AS is available and the other
>>     (default) in the case that the AS is unavailable.  The "SHOULD"
>>     should be removed and this text made an example only.
>> 
>> [Greg] Which SHOULD should be removed?   2;^)
>
>Maybe just cut "to an Application Server".
>
>Also, this doesn't preclude RK's from overlapping.  It just
>precludes "active" RK's from overlapping.  Right?
>
>[snip]
>> 
>> Section 1.4.2.4
>> 
>> "There is, however, no M3UA messaging to manage the status
>> of an SGP (e.g., SGP-Up/Down/Active/Inactive messaging).
>> Whenever an SCTP association to an SGP exists, the SGP is
>> assumed to be ready for the purposes of responding to M3UA
>> ASPSM messages.
>> 
>> Every SGP of one SG ASP regarding one AS provides identical
>> SS7 connectivity to this ASP."
>> 
>>     This is an issue which has been discussed a fair amount on the
>>     list.  These to restrictions placed on the SG/SGP implementation
>>     are unworkable from an number of views.
>> 
>>     It is clear that it cannot be the case that the SGP are treated
>>     as completely equal.  An SG implementation with multiple SGP
>>     will likely require that the ASP choose the SGP in a determinate
>>     fashion.  It is reasonable to assume that an SGP will expect
>>     only symmetrical traffic from an ASP for the Routing Key for
>>     which the ASP has become active.
>> 
>> [Greg]  The draft doesn't say that the SGPs are treated equally, only
that
>> they provide equivalent connectivity to the SS7 network.  I'm also not
>> convinced yet that the traffic has to be symmetrical.
>
>No.  "identical" and "equivalent" are two completely different words.
>Nevertheless, why cannot one SGP1 provide only routes to PC A and SGP2
>provide only routes to PC B?  That is not "identical SS7 connectivity".
>
>> 
>> 
>>     In the first sentences, the SGP cannot be considered to be ready
>>     to accept SS7 traffic before the ASP has even registered.
>>     Therefore, it is not just the availability of the SCTP
>>     association which determines whether an SGP is available.
>> 
>> [Greg] It just says it is ready to accept ASPSM messages (ASP-Up/Down).
I
>> don't see you point
>
>Oooops.  Sorry.  I withdraw that.
>
>> 
>> 
>>     Further, the last sentence quoted above is in direct conflict
>>     with other statements in the draft which indicate that the ASP
>>     must maintain the availablity and congestion of route set on a
>>     per-SGP basis.  Therefore, it is possible that that ASP cannot
>>     treat the SGP as providing "identical SS7 connectivity".
>> 
>> [Greg] I think you are reading too much into the term "connectivity".
Bing
>> connected doesn't mean you are sending traffic.
>
>No.  I am reading the word "identical".  As in twins.
>
>[snip]
>> 
>>     Furthermore, there are possible implementations ("protocol
>>     conversion" approaches) which are stateless and rely on the
>>     state of the subtending ASPs to reflect the state of the SPMC.
>>     In this case, the SGP would need to have no "knowledge" of the
>>     SPMC status, yet still achieve seamless interworking.  Each
>>     "must" in the quoted paragraph should be changed to "may".
>> 
>> [Greg] You have mentioned these "possible implementations" several times
-
>> I'm curious whether anybody is really implementing this?  If not it may
not
>> useful to try and accomodate them.
>
>Gee, I thought M3UA "placed no restrictions"...  I am just saying
>that a "must" here is too "restrictive".  Nothing has to be done
>to accomodate the possible implementation except not telling them
>what they "must" do in this text.
>
>[snip]
>> 
>> 
>> Section 1.4.4.1
>> 
>> "In the process of fail-over, it is recommended that in the
>> case of ASPs supporting call processing, stable calls do not
>> fail.  It is possible that calls in "transition" MAY fail,
>> although measures of communication between the ASPs involved
>> can be used to mitigate this.  For example, the two ASPs MAY
>> share call state via shared memory, or MAY use an ASP to ASP
>> protocol to pass call state information.  Any ASP-to-ASP
>> protocol to support this function is outside the scope of
>> this document.
>> 
>>     Why not?  This presumes that this is an application requirement.
>>     A network operator other than a regulated carrier might not care
>>     if some number of stable calls fail.  This recommendation is out
>>     of scope.  In many places in the draft, the draft makes such a
>>     recommendation followed by the statement that it is out of
>>     scope.  Out of scope recommendations should be removed or
>>     converted to examples.
>> 
>> [Greg] As I stated before in a different way, I honestly think it is OK
to
>> make recommendations about things that are out of scope of the protocol
when
>> they have an impact on the system and help explain how Operator
requirements
>> can be met.
>
>See previous response.  Stable calls cannot fail as a result
>of anything that M3UA does.  Quite frankly, the whole SS7
>network could "go away" and stable calls could still be 
>going along fine.
>
>> 
>> 
>> Section 1.4.4.2
>> 
>> "Signalling Gateways MAY also be distributed over multiple
>> hosts.  Much like the AS model, SGs may comprise one or more
>> SG Processes (SGPs), distributed over one or more hosts,
>> using an active/back-up or a load-sharing model."
>> 
>>     How does an ASP determine which of multiple SGPs to select?  How
>>     does an ASP determine whether multiple SGPs are active/back-up
>>     or load-sharing or some other algorithm?
>> 
>> [Greg] Configuration management
>
>I think that we need to go a little farther here for the
>sake of interoperability.  ASPs having an unknown distribution
>algorithm which is completely outside the control of the SGP
>and hidden in the ASP is not going to work well.  The SG
>designer needs to be able to make some assumptions about the
>ability of the ASP to distribute traffic this way or that
>way.
>
>[snip]
>> 
>> 
>> Section 1.4.4.2
>> 
>> "From the perspective of the M3UA layer at an ASP, a
>> particular SG is capable of transferring traffic to an SS7
>> destination if an SCTP association with at least one SGP of
>> the SG is established, the SGP has returned an
>> acknowledgement to the ASP to indicate that the ASP is
>> actively handling traffic for that destination, and the SGP
>> has not indicated that the destination is inaccessible."
>> 
>>     There is a confusion between the destinations referred to in
>>     this text.  It is not clear whether the text is talking about a
>>     destination other than the ASP SPMC or whether the text is
>>     talking about the ASP SPMC.  The text seems to mix both in the
>>     same sentence, which is confusing.  Also, this text does not
>>     explicitly take MTP restart into consideration.
>> 
>> [Greg] Sorry, I don't see the confusion yet.  I'm not sure how MTP
Restart
>> would make difference here - I hae to think about that one.
>
>The last "destination" could refer to the SPMC.  Perhaps
>"remote desintation" would make the sentence even longer and
>more confusing.
>
>With regard to MTP Restart, during MTP Restart there can be
>an association between an ASP and an SGP which is ASP-ACTIVE
>and has not received DUNA for any destination; however, the
>ASP is still incapable of transferring traffic to *any* SS7
>destination.
>
>> 
>>     For security reasons and in consideration of gateway screening
>>     at the SG, it might not be advisable for the ASP to consider all
>>     SS7 destinations as accessible by default: only those
>>     destinations to which it has a route.
>> 
>> [Greg] Again, I'm not sure I follow this -  Maybe it is too obvious
2;^).
>
>I'll say again: an ASP can have an association with an SGP,
>and be in ASP-ACTIVE state with regard to that SGP, and have
>received no DUNA for point code foo.  That doesn't mean that
>the ASP is capable of transferring traffic to point code foo.
>The SGP may be offering no routes to point code foo to the ASP
>because it is some international point code on a mountain in
>Chile.
>
>Make "transferring traffic to an SS7 destination" read
>
>"transferring traffic to a provisioned SS7 destination".
>
>And add to the long sentence ", and the SG has not indicated
>MTP Restart."
>
>Changing the three occurences of "destination" to "destination X"
>and it will be clear that they are all the same "destination".
>
>[snip]
>> 
>> Section 1.5.1
>> 
>>     The diagram shows the NIF as being above the MTP3 interface and
>>     above a (non-specified) M3UA interface.  This does not
>>     correspond to the text which requires that the NIF interact with
>>     MTP routing functions and even interact with SCTP at the
>>     management level.  It would be more accurate to show the NIF as
>>     between the stacks as follows:
>> 
>>   ********   SS7   *****************   IP   ********
>>   * SEP  *---------*      SGP      *--------* ASP  *
>>   ********         *****************        ********
>> 
>>   +------+       +-------------------+      +------+
>>   | ISUP |       |                   |      | ISUP |
>>   +------+       +------+ NIF +------+      +------+
>>   | MTP3 |       | MTP3 |     | M3UA |      | M3UA |
>>   +------|       +------+-+   +------+      +------+
>>   | MTP2 |       | MTP2 |  \  | SCTP |      | SCTP |
>>   +------+       +------+   +-+------+      +------+
>>   |  L1  |       |  L1  |     |  IP  |      |  IP  |
>>   +------+       +------+     +------+      +------+
>>       |_____________|             |____________|
>> 
>>     SEP - SS7 Signalling End Point
>>     SCTP - Stream Control Transmission Protocol
>>     NIF - Nodal Inter-working Function
>> 
>> 
>> [Greg] OK.  Not sure about the NIF interacting with the SCTP at the
>> management level though.
>
>E.g, M-SCTP_ESTABLISH.
>
>> 
>> 
>> Section 3.1.2
>> 
>>          "4        SS7 Network Congestion (SCON)"
>> 
>>     SS7 Network Congestion is no longer a good description.  This
>>     message is also used to indicate nodal congestion at the ASP.
>> 
>> [Greg] Do you have a more decriptive name?
>
>How about "Signalling Congestion"--still fits the acronym.
>
>[snip]
>> 
>> 
>> Section 4.3.1
>> 
>> "DUNA, DAVA, SCON, and DRST messages MUST be sent
>> sequentially and processed at the receiver in the order
>> sent.  SCTP stream "0" is used to provide the sequencing.
>> The only exception to this is if the international
>> congestion method (see Q.704) is used.  If so, the Unordered
>> bit in the SCTP DATA chunk MAY be used for the SCON
>> message."
>> 
>>     Even SS7 permits TFA/TFR/TFP/TFC to be sent unsequenced.  This
>>     is because there are responsive procedures which will soon
>>     correct a reversal of the messages.  For congestion, adequate
>>     hysteresis is provided to avoid problems due to message
>>     reversal.  This text should be reworded to reflect this
>>     situation.  The "MUST" should be changed to a "MAY" and the
>>     reference to international congestion removed.
>> 
>> [Greg] I don't see any harm in enforcing the sequencing of these
messages.
>> Then we don't have to worry about reversal.
>
>They can be reversed in the SS7 network before they even get to
>M3UA.  SS7 does not impose this restriction, why say "MUST" for
>M3UA?  I would think that it may be very advantageous to send
>them out of order on SCTP implementation which will expedite
>them around ordered messages on the same stream.  The faster
>they get to the ASP the better.  The "MUST" is unjustified.
>
>[snip]
>> 
>> 
>> Section 4.3.3
>> 
>> "In the first of the cases above, the auditing  procedure
>> must not be invoked for the case of a received SCON message
>> containing a congestion level value of "no congestion" or
>> undefined" (i.e., congestion Level = "0"). ...
>> 
>>     What is the draft trying to get at here?
>> 
>> [Greg] There can be no audit as in this case the SG does not maintain
>> congestion status.
>
>Huh?  Why doesn't it?
>
>> 
>> 
>> Section 4.3.3
>> 
>> "The SGP MUST respond to a DAUD message with the MTP3
>> availability/congested status of the routeset associated
>> with each Destination Point Code(s) in the DAUD message.
>> ..."
>> 
>>     This is problematic in the case that the DAUD message if for a
>>     destination to which the SGP has no route (as opposed to a
>>     destination to which the SGP has a route, but which is currently
>>     unavailable).
>> 
>> [Greg] Sorry - I'm confused.  What are you saying?
>
>The DAUD is for that point code on the mountain in Chile
>that no ASP is allowed to query the state of or send
>messages to (even though the SG receives TFP/TFA for them).
>The SG needs a way to refuse to answer an DAUD for a point
>code that the ASP is not authorized to audit the state of.
>
>Consider M3UA as a demarcation point.
>
>> 
>> This is also a security issue in that an ASP
>>     should not be empowered to be able to inquire as to the status
>>     of all possible destinations: only destinations to which the ASP
>>     has authorized routes.
>> 
>> 
>> [Greg] I don't know how you can restrict an ASP to enquiring only about
>> certain destinations.  The SG can protect itself by not responding I
guess.
>
>The SG cannot refuse to respond unless the draft releases the
>"MUST" above.
>
>> 
>> Grammar:
>> 
>>     Section 1.3.2.4, first paragraph, change "in order to" to "to".
>>     Section 1.3.2.4, second paragraph, change "In order to" to "to".
>>     Section 1.4.2.4, first paragraph, change "In order to" to "To".
>>     Section 1.4.2.5, first paragraph, change "In order to" to "To"
>>     and "in order to" to "to".
>>     Section 1.4.3.2, second paragraph, change both instances of "in
>>     order to" to "to".
>>     Section 1.4.4, first paragraph, change "in order to" to "to".
>>     Section 1.4.5, first paragraph, change "in order to" to "to".
>>     Section 1.4.7, second paragraph, change "in order to" to "to".
>>     Section 3.4.1, first paragraph, change "in order to" to "to".
>>     Section 3.4.4, sixth paragraph, change "in order to" to "to".
>>     Section 3.8.2, fifteenth paragraph, change "in order to" to "to".
>>     Section 4.2.3.4, sixteenth paragraph, change "in order to" to "to".
>>     Section 4.3.3, first paragraph, change "in order to" to "to".
>> 
>> [Greg] Yes - a very bad habit of mine (and peeve or yours?)
>
>Nope.  A bad habit of mine too.  I'm on the program: can you tell? :)
>
>> 
>> Thanks Brian for all the comments!
>> 
>> Cheeeers,
>> 
>>   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]
>
>-- 
>Brian F. G. Bidulock
>[email-masked]
>ttp://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]
Date: Fri, 20 Jul 2001 10:54:01 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Updated SUA sent out
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.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

What are the changes in SUAv7 over SUAv6?

What is the Last Call start and end?

Can you give us a week to look at the document before starting last call?

--Brian

John Loughney wrote:                                         (Fri, 20 Jul
2001 17:09:35)
> Hi all,
> 
> I have just sent out an update version of SUA to the IETF Drafts 
> Editor.  With any luck, it will be in an inbox near you soon.
> For those of you who are filled with anticipation, you can get
> a preview of it here:
> 
> 	http://www-nrc.nokia.com/sua/sua.htm
> 
> As I feel it is quite stable, I would like the WG to consider this
> version for last call.  
> 
> I'm going to try to track any issues via a web page - if the WG
> and Lyndon don't mind.  Taking a page off of the AAA WG, I suggest
> a template that looks like the following:
> 
> To submit a new issue, send an e-mail to the SIGTRAN, using the
> following template: 
> 
> Description of issue 
> Submitter name: Your_Name_Here 
> Submitter email address: Your_Email_Address_Here 
> Date first submitted: Insert_Date_Here 
> Reference: URL to e-mail describing problem, if available 
> Comment type: ['T'echnical | 'E'ditorial] 
> Priority: ['S' Must fix | '1' Should fix | '2' May fix ] 
> Section: Insert_Section_Number_Here 
> Rationale/Explanation of issue: 
> Length description of problem 
> 
> Requested change: 
> Proposal 
> 
> And if you can use [SUAv7] in any mails, I'd appreciate it.
> 
> Thanks,
> John
> 
> 
> ---
> 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]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Fri, 20 Jul 2001 11:59:12 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA - Issue #7 - ASP Active 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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Is there any interest in adding Routing Context (M3UA) / Interface
Identifier (M2UA) as optional parameters to the Error Message?
Then, the Error message could be explicit about the RC/IID it is referring
to with the "Invalid RC/IID" error without having to stuff something into
Diagnostic Information OR create a new message.

At 09:33 AM 7/20/01 -0400, you wrote:
>Ken,
>
>The proposal that was put forward at the M3UA "bay-cough" was to add to 
>the protocol a "NACK" (Negative Acknowledge) message. The advantage of the 
>NACK over the ERROR message is that there is clear and instant correlation 
>to the ASP Active Msg.
>
>Greg forgot about this proposal when he was editing M3UA v7. He is 
>considering adding it to the next version of M3UA.
>
>Barry Nagelberg
>Software Engineer
>RadiSys, Corp.
>Signaling Products Design Center
>[email-masked]
>+1-856-642-9229 x237
>
>
>
>
>
>Ken Morneault <[email-masked]>
>07/19/01 10:16 PM
>Please respond to sigtran
>
>  
>         To:     "sigtran" <[email-masked]>
>         cc: 
>         Subject:        M2UA - Issue #7 - ASP Active procedures
>
>
>
>
>Note:  This issue also impacts M3UA.  Just replace Interface Identifier
>with Routing Context.
>
>If an SG receives an ASP Active message (at the proper time)
>which has some Interface Ids indicating AS for which the ASP
>is not configured/registered, how does the SG respond?  The
>draft only allows for two situations that I can see:
>
>    1.  ASP Active is unexpected:  Error - Unexpected Message
>    2.  ASP Active is expected:    Must return ASP Active Ack.
>
>We need a procedure to tell the ASP that an interface id is
>incorrect or that some other failure has occured and which
>describes the disposition of valid IIDs in the ASP Active.
>
>The use of ERR (Invalid Interface Identifier) is appropriate, however,
>it should be mentioned in the ASP Active procedures section.
>
>Also, the disposition of other non-errored IIDs in the ASPAC
>needs to be addressed for interoperability sake.
>
>For example, the ASP sends an ASPAC with 5 IIDs which are
>representative of 5 ASs.  Two of them are invalid (i.e., there
>is no configured/registered AS which has these two IIDs on the
>SG).  The SG could respond with an ERR (Invalid Interface
>Identifier) and an ASPAC Ack for the 3 successful IIDs, but
>then how does the ASP know which IIDs the ERR corresponds to.
>
>Perhaps it is a general correspondence of ERR message problem
>similar to that posted for M3UA today.  The proposal there was
>to include a message and parameter diagnostic in the ERR
>message to permit the error to be correlated with the message
>and parameter causing the error.  If this proposal were to be
>adopted for M2UA, it would permit an ERR (Invalid Interface
>Identifier) with a parameter diagnostic listing the two IIDs
>which were at fault.  Then the ASP would know to stop any
>T(ack) timers with regard to those IIDs.
>
>Another approach would be to fail all 5 IIDs and only send
>one ERR message (and no ASPAC Ack).  This would be a better
>approach because the ASP may not want to start receiving
>traffic for a partly unsuccessful activation attempt.
>
>It gets worse for IID ranges.
>
>Otherwise, to get expected behavior, the ASP will need to send
>each IID in an individual ASPAC and wait for the ASPAC Ack or
>ERR message on each before sending the next and will have to
>be prepared to start messaging on a partially built group of
>AS.  This would severly reduce the value and usability of placing
>multiple IID in the ASPAC message at all.
>
>
>---
>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: Fri, 20 Jul 2001 11:01:20 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: FW: M3UA (V7) DRST question
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.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

If the ASP does not keep track of routing on a per-SGP basis, then all SGP
have to be identical clones.

Any clone which becomes unidentical (e.g, congested, looses a route) has to
take itself out of service by dropping all SCTP associations.

That was M3UA 06.

--Brian

Schantz, John wrote:                              (Fri, 20 Jul 2001
08:37:39)
> 
> 
> -----Original Message-----
> From: Schantz, John 
> Sent: Friday, July 20, 2001 9:53 AM
> To: [email-masked]'
> Subject: RE: M3UA (V7) DRST question
> 
> 
> Brian,
> 	I don't think I am reading a lot into "single management view".
> This is the view that all SS7 nodes have today and if any SG wants to
> connect into an SS7 network will need to abide by the same management
> philosophy (it is built into the SS7 protocol).
> 
> 	So you're telling me that a partitioned SG will have a "single
> management view" towards the SS7 network but it will not maintain this
view
> for its' SGPs.  You are basically forcing the AS to have more complicated
> management structure because you are not willing to build a node that
abides
> by the general philosophy that all other nodes in the network must abide
by.
> So you are asking the AS to collect management messages from each SGP, as
> though they are independent nodes, before the AS can then determine the
true
> state of a remote destination.  When are you going to stop pushing all of
> your dirty work onto the ASs?  Why is a limited node architecture driving
> the standard?  Who do you think will buy a SG like this (cheap but almost
no
> network management functions)?  A small protocol converter per link would
be
> better than this, at least it blindly convert the management message and
not
> make its presence known.
> 
> 	You can make it OPTIONAL but thank goodness my node will be in
> networks with real SGs.
> 
> 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, 20 Jul 2001 11:07:17 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA (V7) DRST question
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Francois,

I think from the discussion so far that the SGPs in your diagram would be
considered to be three separate SGs, rather than a single SG as you have
drawn it.

I believe the dicussion is focussing on multiple SGPs in an SG which
represents a single SPMC or a single point code.

--Brian

Zannin, Francois wrote:                                   (Fri, 20 Jul 2001
16:31:31)
> Hello,
> 
> This is our understanding of the use of the DRST and partitioning between
> the SGP.
> See below,
> Do you agree with this?
> 
>     Regards,
>     Francois Z.
> 
>
0000000001111111111222222222233333333334444444444555555555566666666667777777
> 7778
1234567890123456789012345678901234567890123456789012345678901234567890123456
> 7890
> 
>      SS7 World                              IP World
>  ============================          =================
>                                S.G.                       A.S.
>                           ..............
>  +----+     +-----+ R1    . +-------+  .               +-------+
>  |SP_1|-----|STP_A|---------| SGP_1 |-----------[As0]--|       |
>  +----+     |     |---   ---|       |  .    ----[As1]--| ASP_1 |
>             +-----+   \ / . +---++--+  .   / ---[As2]--|       |
>                        \  .     ||     .  / /          +-------+
>  +----+     +-----+   / \ . +---++--+  . / /
>  |SP_2|-----|STP_B|---   ---| SGP_2 |---- /
>  +----+     |     |---------|       |  . /
>             +--+--+ R2    . +---++--+  ./
>           Clink|          .     ||     / 
>  +----+     +--+--+       . +---++--+ /.
>  |SP_3|-----|STP_C|---------| SGP_3 |- .
>  +----+     |     |---------|       |  .
>             +-----+ R3    . +-------+  .
>                           ..............
> 
> In this configuration,
> The destination SP_2 can be reached via R2 (STP_B) and if R2 
> fails, via R3 (STP_C).
> 
> ASP_1 is connected to SGP_1 by the association As0 
> ASP_1 is connected to SGP_2 by the association As1 
> ASP_1 is connected to SGP_3 by the association As2 
> 
> SP_2 can be reached via STP_B which is connected to SGP_1 and SGP_2
> for redundancy perspective.
> ASP_1 will use links As0 and As1 to send messages to SP_2
> and only uses As2 if As0 and As1 fail.
> 
> With this configuration the DAVA are sent from SGP_1, SGP_2 and 
> SGP_3 BUT SGP_3 can also send a DRST to inform ASP_1 that
> it should use As0 and As1 in priority. This DRST is not the result of 
> a TFR message.
> 
> If a TFR is received from STP_B, this information is distributed 
> to all the SGP and then all the SGP send a DRST to the ASP. These
> DRST can be used by the ASP to reroute the traffic on another SG if
> there is one available.
> 
> All the MTP3 information must be distributed to all the SGP because 
> if the route R2 fails, all the messages already sent from the ASP 
> to SGP_1 and SGP_2 before the receipt of a DRST must be forwarded 
> to the SGP_3 for the time controlled diversion between R2 to R3 or R3
> to R2 if R2 restarts.
> 
> If the platform is partitioned, message sequencing cannot be performed 
> between the ASP and the ss7 SP. Another problem that occurs in a 
> partitioned platform is that the network management messages concerning 
> one route may be sent on another route because the ss7 network sees the 
> SG as an unique point code.
> 
> If we chose to have a partitioned platform, we must be sure that we 
> never will receive management messages on another route then the one it 
> concerns and this depend of the ss7 network configuration. 
> 
> ==================================================================
>   ALL THIS BEHAVIOR IS TRUE IF THE SGP ARE DIRECTLY CONNECTED TO 
>   THE SS7 NETWORK WITHOUT INTERMEDIATE PROCESSES.
> ==================================================================
> 

-- 
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, 20 Jul 2001 11:25:46 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07 Comments
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Lyndon,

I have-noticed a-lot of hyphens finding their-way into all the UAs. It seems
more get added with every version.  So we better get them to the RFC-Editor
while he can still-under-stand-them. ;)

--Brian

(Sorry.  I couldn't-resist!)

Lyndon Ong wrote:                                          (Fri, 20 Jul 2001
08:47:26)
> Just a note - once approved out of this group, the document goes through
> another round of comments in IETF Last Call (although the main comments
> should have been resolved by then).
> 
> Assuming it is approved, the document (or a version incorporating
comments)
> then gets a going over by the RFC Editor, which will probably catch a lot
of
> nits if previous experience holds true :o)
> 
> L. Ong 
> --
> 
> On Fri, 20 Jul 2001 10:21:33   Brian F. G. Bidulock wrote:
> >Greg,
> >
> >Ok, while your wrapping it up, let me first hit ONE BIT NIT:
> >
> >   Runaway hyphenation throughout the document:
> >
> >	`Backup'         is one word, not `back-up'.
> >	`Reroute'        is one word, not `re-route'.
> >	`Unidirectional' is one word, not `uni-directional'.
> >	`Unordered'      is one word, not `un-ordered'.
> >	`Interworking'   is one word, not `inter-working'.
> >	`Reassembly'     is one word, not `re-assembly'.
> >	`Rerouting'      is one word, not `re-routing'.
> >	`Ongoing'        is one word, not `on-going'.
> >	`Deregister' is not a word.  `Unregister' is the opposite of
> >		  `register'.  But I suppose we are stuck with it: but if it
> >		  *was* a word, it would not be `de-register' as `de' is
> >		  normally only hyphenated before a word starting with `e'
as
> >		  in `de-energized'.)
> >	`Deregistration' not `de-registration'.
> >	`Override'       is one word, not `over-ride'.
> >	`Overriding'     is one word, not `over-riding'.
> >	`Lockout'        is one word, not `lock-out'.
> >	`Setup'          is one word, not `set-up'.
> >	`Preconfigured'  is one word, not `pre-configured'.
> >	`Reestablish'    is one word, not `re-establish'.
> >	`Reallocated'    is one word, not `re-allocated'.
> >	`Unconfigured'   is one word, not `un-configured'.
> >	`Unsequenced'    is one word, not `un-sequenced'.
> >	`Redirect'       is one word, not `re-direct'.
> >
> >Can you run the document through a spell-checker and
> >grammar-checker before-releasing-it-as-an-RFC? ;)
> >
> >Follow-up comments below...
> >
[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: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: FW: M3UA (V7) DRST question
Date: Fri, 20 Jul 2001 09:35:05 -0700
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: zcamail05.zca.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: zcamail05.zca.compaq.com [161.114.32.105]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,
	I would think that they are only clones in the management.  You
would think that there would be a central management presence, hence,
eliminating the need to treat the SGP as independent entities and
eliminating the need for the SGPs to worry about network management.

	From an SS7 point of view, if a link became congested, the whole
linkset (route) was assumed to be congested.  This is a good assumption
since all links are used in the same loadsharing scheme and if one was
congested then all should be congest or close to being congested.

	Wouldn't the SGPs connected to the ASP also fit into this model.  If
they are loadsharing the traffic, wouldn't all SGPs be close to going into
congestion if one of them is already congested?  Taking the congested SGP
out of service would only guarantee that the other SGPs will go into
congestion.

	Can't we reused some existing models that already work?

John

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Friday, July
20, 2001 11:01 AM
To: sigtran
Subject: Re: FW: M3UA (V7) DRST question

John,

If the ASP does not keep track of routing on a per-SGP basis, then all SGP
have to be identical clones.

Any clone which becomes unidentical (e.g, congested, looses a route) has to
take itself out of service by dropping all SCTP associations.

That was M3UA 06.

--Brian

Schantz, John wrote:                              (Fri, 20 Jul 2001
08:37:39)
> 
> 
> -----Original Message-----
> From: Schantz, John 
> Sent: Friday, July 20, 2001 9:53 AM
> To: [email-masked]'
> Subject: RE: M3UA (V7) DRST question
> 
> 
> Brian,
> 	I don't think I am reading a lot into "single management view".
> This is the view that all SS7 nodes have today and if any SG wants to
> connect into an SS7 network will need to abide by the same management
> philosophy (it is built into the SS7 protocol).
> 
> 	So you're telling me that a partitioned SG will have a "single
> management view" towards the SS7 network but it will not maintain this
view
> for its' SGPs.  You are basically forcing the AS to have more complicated
> management structure because you are not willing to build a node that
abides
> by the general philosophy that all other nodes in the network must abide
by.
> So you are asking the AS to collect management messages from each SGP, as
> though they are independent nodes, before the AS can then determine the
true
> state of a remote destination.  When are you going to stop pushing all of
> your dirty work onto the ASs?  Why is a limited node architecture driving
> the standard?  Who do you think will buy a SG like this (cheap but almost
no
> network management functions)?  A small protocol converter per link would
be
> better than this, at least it blindly convert the management message and
not
> make its presence known.
> 
> 	You can make it OPTIONAL but thank goodness my node will be in
> networks with real SGs.
> 
> 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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Garnero, Pierre" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA (V7) DRST question
Date: Fri, 20 Jul 2001 18:44:46 +0200
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: zmamail04.zma.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: zmamail04.zma.compaq.com [161.114.64.104]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

no, I think that Francois is well talking about a single SG that contains
multiple SGPs. Some of these SGPs are connected to multiples SS7 adjacent
nodes (nothing precludes to do that in the M3UA-07 draft I hope ? :-) ) and
are able to communicates via an inter-SGP communication channel.
In such a case, I will be very interested to understand how the SS7 SG PC is
able to works correctly, from a SS7 point of view, when it is partitioned
(and when link failures or route failures occur). How message sequencing
could be insured when such a SS7 point code (SG) is partioned ?
How changeover could be insured when the link between SGP_2 and STP_A breaks

(and inter-SGP channel between SGP_1 and SGP_2 is unavailable) ?

Cheers,

Pierre

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, July 20, 2001 6:07 PM
> To: sigtran
> Subject: Re: M3UA (V7) DRST question
> 
> 
> Francois,
> 
> I think from the discussion so far that the SGPs in your
> diagram would be considered to be three separate SGs,
> rather than a single SG as you have drawn it.
> 
> I believe the dicussion is focussing on multiple SGPs in
> an SG which represents a single SPMC or a single point code.
> 
> --Brian
> 
> 
> Zannin, Francois wrote:                                   
> (Fri, 20 Jul 2001 16:31:31)
> > Hello,
> > 
> > This is our understanding of the use of the DRST and 
> partitioning between
> > the SGP.
> > See below,
> > Do you agree with this?
> > 
> >     Regards,
> >     Francois Z.
> > 
> > 
> 00000000011111111112222222222333333333344444444445555555555666
> 66666667777777
> > 7778
> > 
> 12345678901234567890123456789012345678901234567890123456789012
> 34567890123456
> > 7890
> > 
> >      SS7 World                              IP World
> >  ============================          =================
> >                                S.G.                       A.S.
> >                           ..............
> >  +----+     +-----+ R1    . +-------+  .               +-------+
> >  |SP_1|-----|STP_A|---------| SGP_1 |-----------[As0]--|       |
> >  +----+     |     |---   ---|       |  .    ----[As1]--| ASP_1 |
> >             +-----+   \ / . +---++--+  .   / ---[As2]--|       |
> >                        \  .     ||     .  / /          +-------+
> >  +----+     +-----+   / \ . +---++--+  . / /
> >  |SP_2|-----|STP_B|---   ---| SGP_2 |---- /
> >  +----+     |     |---------|       |  . /
> >             +--+--+ R2    . +---++--+  ./
> >           Clink|          .     ||     / 
> >  +----+     +--+--+       . +---++--+ /.
> >  |SP_3|-----|STP_C|---------| SGP_3 |- .
> >  +----+     |     |---------|       |  .
> >             +-----+ R3    . +-------+  .
> >                           ..............
> > 
> > In this configuration,
> > The destination SP_2 can be reached via R2 (STP_B) and if R2 
> > fails, via R3 (STP_C).
> > 
> > ASP_1 is connected to SGP_1 by the association As0 
> > ASP_1 is connected to SGP_2 by the association As1 
> > ASP_1 is connected to SGP_3 by the association As2 
> > 
> > SP_2 can be reached via STP_B which is connected to SGP_1 and SGP_2
> > for redundancy perspective.
> > ASP_1 will use links As0 and As1 to send messages to SP_2
> > and only uses As2 if As0 and As1 fail.
> > 
> > With this configuration the DAVA are sent from SGP_1, SGP_2 and 
> > SGP_3 BUT SGP_3 can also send a DRST to inform ASP_1 that
> > it should use As0 and As1 in priority. This DRST is not the 
> result of 
> > a TFR message.
> > 
> > If a TFR is received from STP_B, this information is distributed 
> > to all the SGP and then all the SGP send a DRST to the ASP. These
> > DRST can be used by the ASP to reroute the traffic on another SG if
> > there is one available.
> > 
> > All the MTP3 information must be distributed to all the SGP because 
> > if the route R2 fails, all the messages already sent from the ASP 
> > to SGP_1 and SGP_2 before the receipt of a DRST must be forwarded 
> > to the SGP_3 for the time controlled diversion between R2 
> to R3 or R3
> > to R2 if R2 restarts.
> > 
> > If the platform is partitioned, message sequencing cannot 
> be performed 
> > between the ASP and the ss7 SP. Another problem that occurs in a 
> > partitioned platform is that the network management 
> messages concerning 
> > one route may be sent on another route because the ss7 
> network sees the 
> > SG as an unique point code.
> > 
> > If we chose to have a partitioned platform, we must be sure that we 
> > never will receive management messages on another route 
> then the one it 
> > concerns and this depend of the ss7 network configuration. 
> > 
> > ==================================================================
> >   ALL THIS BEHAVIOR IS TRUE IF THE SGP ARE DIRECTLY CONNECTED TO 
> >   THE SS7 NETWORK WITHOUT INTERMEDIATE PROCESSES.
> > ==================================================================
> > 
> 
> -- 
> 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]
Sender: [email-masked]
Date: Fri, 20 Jul 2001 12:03:19 -0500
From: Kurt Kite <[email-masked]>
Reply-To: [email-masked]
Organization: Ericsson North America Inc.
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07 Comments
X-SMTP-HELO: imr2.ericy.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: imr2.ericy.com [12.34.240.68]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Some comments below.

/Kurt

"Brian F. G. Bidulock" wrote:

[snip]

>
> >
> > Section 1.5.1
> >
> >     The diagram shows the NIF as being above the MTP3 interface and
> >     above a (non-specified) M3UA interface.  This does not
> >     correspond to the text which requires that the NIF interact with
> >     MTP routing functions and even interact with SCTP at the
> >     management level.  It would be more accurate to show the NIF as
> >     between the stacks as follows:
> >
> >   ********   SS7   *****************   IP   ********
> >   * SEP  *---------*      SGP      *--------* ASP  *
> >   ********         *****************        ********
> >
> >   +------+       +-------------------+      +------+
> >   | ISUP |       |                   |      | ISUP |
> >   +------+       +------+ NIF +------+      +------+
> >   | MTP3 |       | MTP3 |     | M3UA |      | M3UA |
> >   +------|       +------+-+   +------+      +------+
> >   | MTP2 |       | MTP2 |  \  | SCTP |      | SCTP |
> >   +------+       +------+   +-+------+      +------+
> >   |  L1  |       |  L1  |     |  IP  |      |  IP  |
> >   +------+       +------+     +------+      +------+
> >       |_____________|             |____________|
> >
> >     SEP - SS7 Signalling End Point
> >     SCTP - Stream Control Transmission Protocol
> >     NIF - Nodal Inter-working Function
> >
> >
> > [Greg] OK.  Not sure about the NIF interacting with the SCTP at the
> > management level though.
>
> E.g, M-SCTP_ESTABLISH.

I do not see any text in the draft that indicates the NIF interacts with
SCTP.
M-SCTP_ESTABLISH
is used by Layer Management which I do not consider to be the NIF.

[snip]

> >
> >
> > Section 4.3.3
> >
> > "The SGP MUST respond to a DAUD message with the MTP3
> > availability/congested status of the routeset associated
> > with each Destination Point Code(s) in the DAUD message.
> > ..."
> >
> >     This is problematic in the case that the DAUD message if for a
> >     destination to which the SGP has no route (as opposed to a
> >     destination to which the SGP has a route, but which is currently
> >     unavailable).
> >
> > [Greg] Sorry - I'm confused.  What are you saying?
>
> The DAUD is for that point code on the mountain in Chile
> that no ASP is allowed to query the state of or send
> messages to (even though the SG receives TFP/TFA for them).
> The SG needs a way to refuse to answer an DAUD for a point
> code that the ASP is not authorized to audit the state of.
>
> Consider M3UA as a demarcation point.
>
> >
> > This is also a security issue in that an ASP
> >     should not be empowered to be able to inquire as to the status
> >     of all possible destinations: only destinations to which the ASP
> >     has authorized routes.

I'm curious. What is the security issue?

>
> >
> >
> > [Greg] I don't know how you can restrict an ASP to enquiring only about
> > certain destinations.  The SG can protect itself by not responding I
guess.
>
> The SG cannot refuse to respond unless the draft releases the
> "MUST" above.

If the SG refuses to respond what is going to prompt the ASP from continuing
to audit?
Possibly an error response to
the audit?

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Fri, 20 Jul 2001 12:09:59 -0500
From: Kurt Kite <[email-masked]>
Reply-To: [email-masked]
Organization: Ericsson North America Inc.
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M2UA - Issue #7 - ASP Active procedures
X-SMTP-HELO: imr2.ericy.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: imr2.ericy.com [12.34.240.68]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hi Ken,

If messages with multiple RCs/IIDs have to be treated atomically then I
don't see a need for the additional parameters in the Error message (as you
have already indicated); otherwise, I think it is needed.

/Kurt

Ken Morneault wrote:

> Is there any interest in adding Routing Context (M3UA) / Interface
> Identifier (M2UA) as optional parameters to the Error Message?
> Then, the Error message could be explicit about the RC/IID it
> is referring to with the "Invalid RC/IID" error without having to
> stuff something into Diagnostic Information OR create a new
> message.
>
> At 09:33 AM 7/20/01 -0400, you wrote:
> >Ken,
> >
> >The proposal that was put forward at the M3UA "bay-cough" was to add to
> >the protocol a "NACK" (Negative Acknowledge) message. The advantage of
the
> >NACK over the ERROR message is that there is clear and instant
correlation
> >to the ASP Active Msg.
> >
> >Greg forgot about this proposal when he was editing M3UA v7. He is
> >considering adding it to the next version of M3UA.
> >
> >Barry Nagelberg
> >Software Engineer
> >RadiSys, Corp.
> >Signaling Products Design Center
> >[email-masked]
> >+1-856-642-9229 x237
> >
> >
> >
> >
> >
> >Ken Morneault <[email-masked]>
> >07/19/01 10:16 PM
> >Please respond to sigtran
> >
> >
> >         To:     "sigtran" <[email-masked]>
> >         cc:
> >         Subject:        M2UA - Issue #7 - ASP Active procedures
> >
> >
> >
> >
> >Note:  This issue also impacts M3UA.  Just replace Interface Identifier
> >with Routing Context.
> >
> >If an SG receives an ASP Active message (at the proper time)
> >which has some Interface Ids indicating AS for which the ASP
> >is not configured/registered, how does the SG respond?  The
> >draft only allows for two situations that I can see:
> >
> >    1.  ASP Active is unexpected:  Error - Unexpected Message
> >    2.  ASP Active is expected:    Must return ASP Active Ack.
> >
> >We need a procedure to tell the ASP that an interface id is
> >incorrect or that some other failure has occured and which
> >describes the disposition of valid IIDs in the ASP Active.
> >
> >The use of ERR (Invalid Interface Identifier) is appropriate, however,
> >it should be mentioned in the ASP Active procedures section.
> >
> >Also, the disposition of other non-errored IIDs in the ASPAC
> >needs to be addressed for interoperability sake.
> >
> >For example, the ASP sends an ASPAC with 5 IIDs which are
> >representative of 5 ASs.  Two of them are invalid (i.e., there
> >is no configured/registered AS which has these two IIDs on the
> >SG).  The SG could respond with an ERR (Invalid Interface
> >Identifier) and an ASPAC Ack for the 3 successful IIDs, but
> >then how does the ASP know which IIDs the ERR corresponds to.
> >
> >Perhaps it is a general correspondence of ERR message problem
> >similar to that posted for M3UA today.  The proposal there was
> >to include a message and parameter diagnostic in the ERR
> >message to permit the error to be correlated with the message
> >and parameter causing the error.  If this proposal were to be
> >adopted for M2UA, it would permit an ERR (Invalid Interface
> >Identifier) with a parameter diagnostic listing the two IIDs
> >which were at fault.  Then the ASP would know to stop any
> >T(ack) timers with regard to those IIDs.
> >
> >Another approach would be to fail all 5 IIDs and only send
> >one ERR message (and no ASPAC Ack).  This would be a better
> >approach because the ASP may not want to start receiving
> >traffic for a partly unsuccessful activation attempt.
> >
> >It gets worse for IID ranges.
> >
> >Otherwise, to get expected behavior, the ASP will need to send
> >each IID in an individual ASPAC and wait for the ASPAC Ack or
> >ERR message on each before sending the next and will have to
> >be prepared to start messaging on a partially built group of
> >AS.  This would severly reduce the value and usability of placing
> >multiple IID in the ASPAC message at all.
> >
> >
> >---
> >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]
To: "sigtran" <[email-masked]>
Date: Fri, 20 Jul 2001 10:20:51 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Mailer: MailCity Service
Subject: Re: Updated SUA sent out
X-Sender-Ip: 63.96.78.21
Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80)
X-SMTP-HELO: shared1-mail.whowhere.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.185.123.82]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Folks,

We're not in Last Call yet on SUA!  John is "priming the pump", I think.  We
need SUA to be available on the IETF server, at least.

A list of major changes from v6 to v7 would also be helpful.

Cheers,

L. Ong
 
--

On Fri, 20 Jul 2001 10:54:01   Brian F. G. Bidulock wrote:
>John,
>
>What are the changes in SUAv7 over SUAv6?
>
>What is the Last Call start and end?
>
>Can you give us a week to look at the document
>before starting last call?
>
>--Brian
>
>
>John Loughney wrote:                                         (Fri, 20 Jul
2001 17:09:35)
>> Hi all,
>> 
>> I have just sent out an update version of SUA to the IETF Drafts 
>> Editor.  With any luck, it will be in an inbox near you soon.
>> For those of you who are filled with anticipation, you can get
>> a preview of it here:
>> 
>> 	http://www-nrc.nokia.com/sua/sua.htm
>> 
>> As I feel it is quite stable, I would like the WG to consider this
>> version for last call.  
>> 
>> I'm going to try to track any issues via a web page - if the WG
>> and Lyndon don't mind.  Taking a page off of the AAA WG, I suggest
>> a template that looks like the following:
>> 
>> To submit a new issue, send an e-mail to the SIGTRAN, using the
>> following template: 
>> 
>> Description of issue 
>> Submitter name: Your_Name_Here 
>> Submitter email address: Your_Email_Address_Here 
>> Date first submitted: Insert_Date_Here 
>> Reference: URL to e-mail describing problem, if available 
>> Comment type: ['T'echnical | 'E'ditorial] 
>> Priority: ['S' Must fix | '1' Should fix | '2' May fix ] 
>> Section: Insert_Section_Number_Here 
>> Rationale/Explanation of issue: 
>> Length description of problem 
>> 
>> Requested change: 
>> Proposal 
>> 
>> And if you can use [SUAv7] in any mails, I'd appreciate it.
>> 
>> Thanks,
>> John
>> 
>> 
>> ---
>> 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]

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]
Date: Fri, 20 Jul 2001 12:32:09 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07 Comments
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Kurt,

Kurt Kite wrote:                                             (Fri, 20 Jul
2001 12:03:19)
> Some comments below.
> 
> /Kurt
> 
> "Brian F. G. Bidulock" wrote:
> 
> [snip]
> 
> >
> > >
> > > Section 1.5.1
> > >
> > >     The diagram shows the NIF as being above the MTP3 interface and
> > >     above a (non-specified) M3UA interface.  This does not
> > >     correspond to the text which requires that the NIF interact with
> > >     MTP routing functions and even interact with SCTP at the
> > >     management level.  It would be more accurate to show the NIF as
> > >     between the stacks as follows:
> > >
> > >   ********   SS7   *****************   IP   ********
> > >   * SEP  *---------*      SGP      *--------* ASP  *
> > >   ********         *****************        ********
> > >
> > >   +------+       +-------------------+      +------+
> > >   | ISUP |       |                   |      | ISUP |
> > >   +------+       +------+ NIF +------+      +------+
> > >   | MTP3 |       | MTP3 |     | M3UA |      | M3UA |
> > >   +------|       +------+-----+------+      +------+
> > >   | MTP2 |       | MTP2 |     | SCTP |      | SCTP |
> > >   +------+       +------+     +------+      +------+
> > >   |  L1  |       |  L1  |     |  IP  |      |  IP  |
> > >   +------+       +------+     +------+      +------+
> > >       |_____________|             |____________|
> > >
> > >     SEP - SS7 Signalling End Point
> > >     SCTP - Stream Control Transmission Protocol
> > >     NIF - Nodal Inter-working Function
> > >
> > >
> > > [Greg] OK.  Not sure about the NIF interacting with the SCTP at the
> > > management level though.
> >
> > E.g, M-SCTP_ESTABLISH.
> 
> I do not see any text in the draft that indicates the NIF interacts with
SCTP.
> M-SCTP_ESTABLISH
> is used by Layer Management which I do not consider to be the NIF.
> 
> [snip]

Is the modification above better?

> 
> > >
> > >
> > > Section 4.3.3
> > >
> > > "The SGP MUST respond to a DAUD message with the MTP3
> > > availability/congested status of the routeset associated
> > > with each Destination Point Code(s) in the DAUD message.
> > > ..."
> > >
> > >     This is problematic in the case that the DAUD message if for a
> > >     destination to which the SGP has no route (as opposed to a
> > >     destination to which the SGP has a route, but which is currently
> > >     unavailable).
> > >
> > > [Greg] Sorry - I'm confused.  What are you saying?
> >
> > The DAUD is for that point code on the mountain in Chile
> > that no ASP is allowed to query the state of or send
> > messages to (even though the SG receives TFP/TFA for them).
> > The SG needs a way to refuse to answer an DAUD for a point
> > code that the ASP is not authorized to audit the state of.
> >
> > Consider M3UA as a demarcation point.
> >
> > >
> > > This is also a security issue in that an ASP
> > >     should not be empowered to be able to inquire as to the status
> > >     of all possible destinations: only destinations to which the ASP
> > >     has authorized routes.
> 
> I'm curious. What is the security issue?

TFP reveals competitive intelligence about service outage occurence,
duration, and location.  I'm thinking about serving--what would otherwise be
an A-link--interconnects off of a BGWS STP using M3UA.
One interconnect (SPMC) should not be permitted to inquite about the status
of routesets to point codes in the SS7 network to which the interconnect
SPMC has no authorized routes, even though the BGWS STP (SG) may know the
routeset status of 400 switches in my network.  This particular SPMC may
only be autorized to route traffic and inquire about the status of one of my
switches.  The status of the other 399 are none of his business.

> 
> >
> > >
> > >
> > > [Greg] I don't know how you can restrict an ASP to enquiring only
about
> > > certain destinations.  The SG can protect itself by not responding I
guess.
> >
> > The SG cannot refuse to respond unless the draft releases the
> > "MUST" above.
> 
> If the SG refuses to respond what is going to prompt the ASP from
continuing
> to audit?  Possibly an error response to the audit?
> 
An uninformative error response would be apt.

       Error - Invalid Destination (or whatever)

Because DAUD can contain multiple affected DPCs, this error should be able
to be correlated with which affected PC in the message was in error.

This error should notify management.  Interconnects are famous for probing a
GWS STP's screening tables.

-- 
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]
To: "sigtran" <[email-masked]>
Date: Fri, 20 Jul 2001 10:33:04 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Mailer: MailCity Service
Subject: agenda for London
X-Sender-Ip: 63.96.78.21
Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80)
X-SMTP-HELO: shared1-mail.whowhere.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: shared1-batch.whowhere.com [209.185.123.82]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Folks,

Here's a proposed agenda for London, we meet on Tuesday afternoon, for 1
hour only.  Please send me your comments.

-- Intro and Agenda Bash (5 min.)
-- Status of SCTP, M3UA, M2UA and AS (10 min.) -- Status of SUA and M2PA (10
min.)
-- V5UA Discussion (5 min.)
-- DUA (IUA extension) Discussion (5 min.) -- MIB Status Update (10 min.)
-- Bakeoff planning (10 min.)
-- Other issues (5 min.)

The documents are:
- draft-ietf-sigtran-m3ua-08.txt (to be published) -
draft-ietf-sigtran-m2ua-09.txt
- draft-ietf-sigtran-sua-07.txt (to be published) -
draft-ietf-sigtran-m2pa-03.txt (to be published) -
draft-ietf-sigtran-v5ua-01.txt
- draft-anil-sigtran-dua-01.txt (to be published) -
draft-ietf-sigtran-sctp-mib-04.txt
- draft-sigtran-m3ua-mib-01.txt

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]
Sender: [email-masked]
Date: Fri, 20 Jul 2001 12:46:31 -0500
From: Kurt Kite <[email-masked]>
Reply-To: [email-masked]
Organization: Ericsson North America Inc.
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07 Comments
X-SMTP-HELO: imr2.ericy.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: imr2.ericy.com [12.34.240.68]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hi Brian,

The ok with the picture now.

Thanks for the security lesson. I didn't know such espionage existed in the
SS7 world.

/Kurt

"Brian F. G. Bidulock" wrote:

> Kurt,
>
> Kurt Kite wrote:                                             (Fri, 20 Jul
2001 12:03:19)
> > Some comments below.
> >
> > /Kurt
> >
> > "Brian F. G. Bidulock" wrote:
> >
> > [snip]
> >
> > >
> > > >
> > > > Section 1.5.1
> > > >
> > > >     The diagram shows the NIF as being above the MTP3 interface and
> > > >     above a (non-specified) M3UA interface.  This does not
> > > >     correspond to the text which requires that the NIF interact with
> > > >     MTP routing functions and even interact with SCTP at the
> > > >     management level.  It would be more accurate to show the NIF as
> > > >     between the stacks as follows:
> > > >
> > > >   ********   SS7   *****************   IP   ********
> > > >   * SEP  *---------*      SGP      *--------* ASP  *
> > > >   ********         *****************        ********
> > > >
> > > >   +------+       +-------------------+      +------+
> > > >   | ISUP |       |                   |      | ISUP |
> > > >   +------+       +------+ NIF +------+      +------+
> > > >   | MTP3 |       | MTP3 |     | M3UA |      | M3UA |
> > > >   +------|       +------+-----+------+      +------+
> > > >   | MTP2 |       | MTP2 |     | SCTP |      | SCTP |
> > > >   +------+       +------+     +------+      +------+
> > > >   |  L1  |       |  L1  |     |  IP  |      |  IP  |
> > > >   +------+       +------+     +------+      +------+
> > > >       |_____________|             |____________|
> > > >
> > > >     SEP - SS7 Signalling End Point
> > > >     SCTP - Stream Control Transmission Protocol
> > > >     NIF - Nodal Inter-working Function
> > > >
> > > >
> > > > [Greg] OK.  Not sure about the NIF interacting with the SCTP at the
> > > > management level though.
> > >
> > > E.g, M-SCTP_ESTABLISH.
> >
> > I do not see any text in the draft that indicates the NIF interacts with
SCTP.
> > M-SCTP_ESTABLISH
> > is used by Layer Management which I do not consider to be the NIF.
> >
> > [snip]
>
> Is the modification above better?
>
> >
> > > >
> > > >
> > > > Section 4.3.3
> > > >
> > > > "The SGP MUST respond to a DAUD message with the MTP3
> > > > availability/congested status of the routeset associated
> > > > with each Destination Point Code(s) in the DAUD message.
> > > > ..."
> > > >
> > > >     This is problematic in the case that the DAUD message if for a
> > > >     destination to which the SGP has no route (as opposed to a
> > > >     destination to which the SGP has a route, but which is currently
> > > >     unavailable).
> > > >
> > > > [Greg] Sorry - I'm confused.  What are you saying?
> > >
> > > The DAUD is for that point code on the mountain in Chile
> > > that no ASP is allowed to query the state of or send
> > > messages to (even though the SG receives TFP/TFA for them).
> > > The SG needs a way to refuse to answer an DAUD for a point
> > > code that the ASP is not authorized to audit the state of.
> > >
> > > Consider M3UA as a demarcation point.
> > >
> > > >
> > > > This is also a security issue in that an ASP
> > > >     should not be empowered to be able to inquire as to the status
> > > >     of all possible destinations: only destinations to which the ASP
> > > >     has authorized routes.
> >
> > I'm curious. What is the security issue?
>
> TFP reveals competitive intelligence about service outage occurence,
> duration, and location.  I'm thinking about serving--what would
> otherwise be an A-link--interconnects off of a BGWS STP using M3UA.
> One interconnect (SPMC) should not be permitted to inquite about
> the status of routesets to point codes in the SS7 network to which
> the interconnect SPMC has no authorized routes, even though the
> BGWS STP (SG) may know the routeset status of 400 switches in my
> network.  This particular SPMC may only be autorized to route
> traffic and inquire about the status of one of my switches.  The
> status of the other 399 are none of his business.
>
> >
> > >
> > > >
> > > >
> > > > [Greg] I don't know how you can restrict an ASP to enquiring only
about
> > > > certain destinations.  The SG can protect itself by not responding I
guess.
> > >
> > > The SG cannot refuse to respond unless the draft releases the
> > > "MUST" above.
> >
> > If the SG refuses to respond what is going to prompt the ASP from
continuing
> > to audit?  Possibly an error response to the audit?
> >
> An uninformative error response would be apt.
>
>        Error - Invalid Destination (or whatever)
>
> Because DAUD can contain multiple affected DPCs, this error should
> be able to be correlated with which affected PC in the message was
> in error.
>
> This error should notify management.  Interconnects are famous
> for probing a GWS STP's screening tables.
>
> --
> 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, 20 Jul 2001 12:49:58 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: FW: M3UA (V7) DRST question
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.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

Schantz, John wrote:                                     (Fri, 20 Jul 2001
09:35:05)
> Brian,
> 	I would think that they are only clones in the management.  You
> would think that there would be a central management presence, hence,
> eliminating the need to treat the SGP as independent entities and
> eliminating the need for the SGPs to worry about network management.

Network management and SS7 MTP management are two different things.
I don't think the draft is talking about "network management" in the
Telco/OS sense of the term (because it is not defined, mentioned, or scoped
into the document anywhere--not even LM considers network management--the
MIB does).

A single view of SS7 MTP management (SNMM stuff) needs to be presented to
the SS7 network ('cause it can't handle anyting else).

The question is more one of whether the ASP needs the same single view of
the SGP as is presented to the SS7 network.  I think no.  We are exposing
the internal architecutre of the SPMC to the SG in the form of individual
ASP management, why should the ASP get off easy?

Also, what do you think of Francois' diagram?

> 
> 	From an SS7 point of view, if a link became congested, the whole
> linkset (route) was assumed to be congested.  This is a good assumption
> since all links are used in the same loadsharing scheme and if one was
> congested then all should be congest or close to being congested.

The SGP can become congested by an ASP and is permitted to use SCON to
signal this.

> 
> 	Wouldn't the SGPs connected to the ASP also fit into this model.  If
> they are loadsharing the traffic, wouldn't all SGPs be close to going into
> congestion if one of them is already congested?  Taking the congested SGP
> out of service would only guarantee that the other SGPs will go into
> congestion.

Yes.  Not too intelligent is it.  The ASP needs to treat them differently.

A key problem here is that the ASP is not required to do anything with
regard to messages going from ASP to SGP.  The SGP has no method of refusing
any DATA message the ASP cares to send.  All ASPs are even permitted in the
current model to send ALL their outgoing messages to one SGP if they want.
This kind of focusing could be disasterous.

In IUA and M2UA this is not a problem because traffic flow is symmetrical by
the nature of the communications links involved.  In M3UA/SUA, however,
either a symmetrical routing key concept must be used or at least some order
placed on how the ASP selects SGP.  If the SGP can individually send
DUNA/DAVA/DRST, then it has some definitive control over the traffic that
the ASP is permitted to present to it.

> 
> 	Can't we reused some existing models that already work?
> 
> John
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, July 20, 2001 11:01 AM
> To: sigtran
> Subject: Re: FW: M3UA (V7) DRST question
> 
> 
> John,
> 
> If the ASP does not keep track of routing on a per-SGP
> basis, then all SGP have to be identical clones.
> 
> Any clone which becomes unidentical (e.g, congested,
> looses a route) has to take itself out of service by
> dropping all SCTP associations.
> 
> That was M3UA 06.
> 
> 
> --Brian
> 
> Schantz, John wrote:                              (Fri, 20 Jul 2001
> 08:37:39)
> > 
> > 
> > -----Original Message-----
> > From: Schantz, John 
> > Sent: Friday, July 20, 2001 9:53 AM
> > To: [email-masked]'
> > Subject: RE: M3UA (V7) DRST question
> > 
> > 
> > Brian,
> > 	I don't think I am reading a lot into "single management view".
> > This is the view that all SS7 nodes have today and if any SG wants to
> > connect into an SS7 network will need to abide by the same management
> > philosophy (it is built into the SS7 protocol).
> > 
> > 	So you're telling me that a partitioned SG will have a "single
> > management view" towards the SS7 network but it will not maintain this
> view
> > for its' SGPs.  You are basically forcing the AS to have more
complicated
> > management structure because you are not willing to build a node that
> abides
> > by the general philosophy that all other nodes in the network must abide
> by.
> > So you are asking the AS to collect management messages from each SGP,
as
> > though they are independent nodes, before the AS can then determine the
> true
> > state of a remote destination.  When are you going to stop pushing all
of
> > your dirty work onto the ASs?  Why is a limited node architecture
driving
> > the standard?  Who do you think will buy a SG like this (cheap but
almost
> no
> > network management functions)?  A small protocol converter per link
would
> be
> > better than this, at least it blindly convert the management message and
> not
> > make its presence known.
> > 
> > 	You can make it OPTIONAL but thank goodness my node will be in
> > networks with real SGs.
> > 
> > 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]
> 
> 
> ---
> 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: m2ua v9 - 3.3.1.7 Congestion Indication
X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001
Date: Fri, 20 Jul 2001 14:30:08 -0400
X-MIMETrack: Serialize by Router on HQ_ACS_1/Radisys_Corporation/US(Release 
             5.0.8 |June 18, 2001) at 07/20/2001 11:32:36 AM, Serialize 
             complete at 07/20/2001 11:32:36 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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Ken,

Here are some comments on 3.3.1.7  Congestion Indication:

1. This is the first and last place in the draft that the term "MSU buffer"
is used. I would recommend stating exactly what it is and in which direction
the MSU's are going.

2. The first sentence of the first para says "can be sent", which means
optional,  while the last sentence says "SHALL send", which means mandatory.
Then in the last para you switch back to "MAY". 
Which is it?

3. "The valid values for Congestion Status and Discard Status are shown in
the following table:" But there is no indication in the table as to which
values go in the congestion param and which go in the discard param. I
assume that

       LEVEL_NONE       0x0      No congestion.
       LEVEL_1          0x1      Congestion Level 1
       LEVEL_2          0x2      Congestion Level 2
       LEVEL_3          0x3      Congestion Level 3

go in the congestion param and that

       LEVEL_4          0x4      Congestion Level 4 - Discarding

 goes in the discard param. 

But it seems Level_4 is just a more severe congestion level, and is mutually
exclusive with the first 4 levels. So why do we need 2 separate params?

Barry Nagelberg
Software Engineer
RadiSys, Corp.
Signaling Products Design Center
[email-masked]
+1-856-642-9229 x237

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Zannin, Francois" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA (V7) DRST question
Date: Fri, 20 Jul 2001 21:00:19 +0200
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: zcamail04.zca.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [161.114.32.104]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

Thank's for your answer.

In my configuration, i'm talking about a SG seen as an unique Signaling
point code by the ss7 network and distributed between several SGP for high
availability of the SG.

The route's links are also distributed in all the SPG in order to always
have some links available on all routes if one SGP fails.

Because the SG is seen as a single SP by the ss7 network, all SGP are
managed as an unique SG entity.
This involve a communication between the several SGP.

What could be the behavior of this kind of configuration in case of
communication problem between the SGP?

Regards,

Francois Z.

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Friday, July
20, 2001 6:07 PM
To: sigtran
Subject: Re: M3UA (V7) DRST question

Francois,

I think from the discussion so far that the SGPs in your diagram would be
considered to be three separate SGs, rather than a single SG as you have
drawn it.

I believe the dicussion is focussing on multiple SGPs in an SG which
represents a single SPMC or a single point code.

--Brian

Zannin, Francois wrote:                                   (Fri, 20 Jul 2001
16:31:31)
> Hello,
> 
> This is our understanding of the use of the DRST and partitioning between
> the SGP.
> See below,
> Do you agree with this?
> 
>     Regards,
>     Francois Z.
> 
>
0000000001111111111222222222233333333334444444444555555555566666666667777777
> 7778
1234567890123456789012345678901234567890123456789012345678901234567890123456
> 7890
> 
>      SS7 World                              IP World
>  ============================          =================
>                                S.G.                       A.S.
>                           ..............
>  +----+     +-----+ R1    . +-------+  .               +-------+
>  |SP_1|-----|STP_A|---------| SGP_1 |-----------[As0]--|       |
>  +----+     |     |---   ---|       |  .    ----[As1]--| ASP_1 |
>             +-----+   \ / . +---++--+  .   / ---[As2]--|       |
>                        \  .     ||     .  / /          +-------+
>  +----+     +-----+   / \ . +---++--+  . / /
>  |SP_2|-----|STP_B|---   ---| SGP_2 |---- /
>  +----+     |     |---------|       |  . /
>             +--+--+ R2    . +---++--+  ./
>           Clink|          .     ||     / 
>  +----+     +--+--+       . +---++--+ /.
>  |SP_3|-----|STP_C|---------| SGP_3 |- .
>  +----+     |     |---------|       |  .
>             +-----+ R3    . +-------+  .
>                           ..............
> 
> In this configuration,
> The destination SP_2 can be reached via R2 (STP_B) and if R2 
> fails, via R3 (STP_C).
> 
> ASP_1 is connected to SGP_1 by the association As0 
> ASP_1 is connected to SGP_2 by the association As1 
> ASP_1 is connected to SGP_3 by the association As2 
> 
> SP_2 can be reached via STP_B which is connected to SGP_1 and SGP_2
> for redundancy perspective.
> ASP_1 will use links As0 and As1 to send messages to SP_2
> and only uses As2 if As0 and As1 fail.
> 
> With this configuration the DAVA are sent from SGP_1, SGP_2 and 
> SGP_3 BUT SGP_3 can also send a DRST to inform ASP_1 that
> it should use As0 and As1 in priority. This DRST is not the result of 
> a TFR message.
> 
> If a TFR is received from STP_B, this information is distributed 
> to all the SGP and then all the SGP send a DRST to the ASP. These
> DRST can be used by the ASP to reroute the traffic on another SG if
> there is one available.
> 
> All the MTP3 information must be distributed to all the SGP because 
> if the route R2 fails, all the messages already sent from the ASP 
> to SGP_1 and SGP_2 before the receipt of a DRST must be forwarded 
> to the SGP_3 for the time controlled diversion between R2 to R3 or R3
> to R2 if R2 restarts.
> 
> If the platform is partitioned, message sequencing cannot be performed 
> between the ASP and the ss7 SP. Another problem that occurs in a 
> partitioned platform is that the network management messages concerning 
> one route may be sent on another route because the ss7 network sees the 
> SG as an unique point code.
> 
> If we chose to have a partitioned platform, we must be sure that we 
> never will receive management messages on another route then the one it 
> concerns and this depend of the ss7 network configuration. 
> 
> ==================================================================
>   ALL THIS BEHAVIOR IS TRUE IF THE SGP ARE DIRECTLY CONNECTED TO 
>   THE SS7 NETWORK WITHOUT INTERMEDIATE PROCESSES.
> ==================================================================
> 

-- 
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, 20 Jul 2001 14:01:33 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: m2ua v9 - 3.3.1.7 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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Barry,

How's it going?  Some comments...

[email-masked] wrote:                (Fri, 20 Jul 2001
14:30:08)
> Ken,
> 
> Here are some comments on 3.3.1.7  Congestion Indication:
> 
> 1. This is the first and last place in the draft that the term
> "MSU buffer" is used. I would recommend stating exactly what it is
> and in which direction the MSU's are going.

I think that we all know that it refers to the SS7 Link's internal buffer
which is used for congestion indications per Q.704.  Can you suggest better
wording?

> 
> 2. The first sentence of the first para says "can be sent", which
> means optional,  while the last sentence says "SHALL send", which
> means mandatory. Then in the last para you switch back to "MAY".
> Which is it?

"can" is not a keyword: it means "is able", not "optional"

The last "MAY" has already been removed.

> 
> 3. "The valid values for Congestion Status and Discard Status are
> shown in the following table:" But there is no indication in the
> table as to which values go in the congestion param and which go
> in the discard param. I assume that
> 
>        LEVEL_NONE       0x0      No congestion.
>        LEVEL_1          0x1      Congestion Level 1
>        LEVEL_2          0x2      Congestion Level 2
>        LEVEL_3          0x3      Congestion Level 3
> 
> go in the congestion param and that
> 
>        LEVEL_4          0x4      Congestion Level 4 - Discarding
> 
>  goes in the discard param. 
> 
> But it seems Level_4 is just a more severe congestion level, and
> is mutually exclusive with the first 4 levels. So why do we need 2
> separate params?
> 

All reference to LEVEL_4 has been removed.  Any of the remaining levels can
go in either status parameter.

-- 
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: More on m2ua v9 - 3.3.1.7 Congestion Indication
X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001
Date: Fri, 20 Jul 2001 15:01:54 -0400
X-MIMETrack: Serialize by Router on HQ_ACS_1/Radisys_Corporation/US(Release 
             5.0.8 |June 18, 2001) at 07/20/2001 12:04:23 PM, Serialize 
             complete at 07/20/2001 12:04:23 PM
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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Ken,

I suggest deleting the M2UA parameter ID "772 (0x0304) Congestion Status"
and the M3UA parameter ID "0x85 Congestion Indications", and replacing them
with a parameter ID that would be placed in the list of common parameter
Tags used by all User Adaptation layers.

Barry Nagelberg
Software Engineer
RadiSys, Corp.
Signaling Products Design Center
[email-masked]
+1-856-642-9229 x237

---
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, 20 Jul 2001 15:53:17 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: More on m2ua v9 - 3.3.1.7 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]

Barry,

I'd prefer not to change these parameter values unless folks feel there is
an overwhelming reason to do so at this time.

Regards,

Ken

At 03:01 PM 7/20/01 -0400, you wrote:
>Ken,
>
>I suggest deleting the M2UA parameter ID "772 (0x0304) Congestion Status"
and the M3UA parameter ID "0x85 Congestion Indications", and replacing them
with a parameter ID that would be placed in the list of common parameter
Tags used by all User Adaptation layers.
>
>Barry Nagelberg
>Software Engineer
>RadiSys, Corp.
>Signaling Products Design Center
>[email-masked]
>+1-856-642-9229 x237
>
>
>
>---
>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, 20 Jul 2001 15:54:53 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: m2ua v9 - 3.3.1.7 Congestion Indication
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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Barry,

Are Brian's comments sufficient or do we need to create an issue number?

Ken

At 02:01 PM 7/20/01 -0500, you wrote:
>Barry,
>
>How's it going?  Some comments...
>
>[email-masked] wrote:                (Fri, 20 Jul 2001
14:30:08)
> > Ken,
> > 
> > Here are some comments on 3.3.1.7  Congestion Indication:
> > 
> > 1. This is the first and last place in the draft that the term
> > "MSU buffer" is used. I would recommend stating exactly what it is
> > and in which direction the MSU's are going.
>
>I think that we all know that it refers to the SS7 Link's internal
>buffer which is used for congestion indications per Q.704.  Can
>you suggest better wording?
>
> > 
> > 2. The first sentence of the first para says "can be sent", which
> > means optional,  while the last sentence says "SHALL send", which
> > means mandatory. Then in the last para you switch back to "MAY".
> > Which is it?
>
>"can" is not a keyword: it means "is able", not "optional"
>
>The last "MAY" has already been removed.
>
> > 
> > 3. "The valid values for Congestion Status and Discard Status are
> > shown in the following table:" But there is no indication in the
> > table as to which values go in the congestion param and which go
> > in the discard param. I assume that
> > 
> >        LEVEL_NONE       0x0      No congestion.
> >        LEVEL_1          0x1      Congestion Level 1
> >        LEVEL_2          0x2      Congestion Level 2
> >        LEVEL_3          0x3      Congestion Level 3
> > 
> > go in the congestion param and that
> > 
> >        LEVEL_4          0x4      Congestion Level 4 - Discarding
> > 
> >  goes in the discard param. 
> > 
> > But it seems Level_4 is just a more severe congestion level, and
> > is mutually exclusive with the first 4 levels. So why do we need 2
> > separate params?
> > 
>
>All reference to LEVEL_4 has been removed.  Any of the remaining
>levels can go in either status parameter.
>
>-- 
>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: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: FW: M3UA (V7) DRST question
Date: Fri, 20 Jul 2001 12:56:10 -0700
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: ztxmail04.ztx.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [161.114.1.208]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,
	My comments are below.
John

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Friday, July
20, 2001 12:50 PM
To: sigtran
Subject: Re: FW: M3UA (V7) DRST question

John,

Schantz, John wrote:                                     (Fri, 20 Jul 2001
09:35:05)
> Brian,
> 	I would think that they are only clones in the management.  You
> would think that there would be a central management presence, hence,
> eliminating the need to treat the SGP as independent entities and
> eliminating the need for the SGPs to worry about network management.

Network management and SS7 MTP management are two different things.
I don't think the draft is talking about "network management" in the
Telco/OS sense of the term (because it is not defined, mentioned, or scoped
into the document anywhere--not even LM considers network management--the
MIB does).

[John] We are in agreement that we are talking about SS7 network management.

A single view of SS7 MTP management (SNMM stuff) needs to be presented to
the SS7 network ('cause it can't handle anyting else).

[John] It is also proven and it works and I don't see why it should change
with the addition of SS7 over IP.  You are trying to get IP into the SS7
network.  You won't do it by discarding its main strength. 

The question is more one of whether the ASP needs the same single view of
the SGP as is presented to the SS7 network.  I think no.  We are exposing
the internal architecutre of the SPMC to the SG in the form of individual
ASP management, why should the ASP get off easy?

[John]  I don't see why you see it this way.  The ASPs have been given all
of responsibility to drive the states of the connection while the SGPs can
just set back and see if it can send traffic or not.  Heaven forbid if a
connection goes down and you have to redistribute the traffic to the other
connections between the "SG" and the "AS".  

Also, what do you think of Francois' diagram?

[John]  Actually I think is is an invalid configuration.  All links between
the "AS" and the "SG" would be considered part of the same linkset.  Hence,
you can not divide up the traffic and only send it on selected links within
the linkset.

> 
> 	From an SS7 point of view, if a link became congested, the whole
> linkset (route) was assumed to be congested.  This is a good assumption
> since all links are used in the same loadsharing scheme and if one was
> congested then all should be congest or close to being congested.

The SGP can become congested by an ASP and is permitted to use SCON to
signal this.

[John]  How is it doing this and what is it intended to mean?  It is
returning a SCON for the remote destinations or is sending it just for the
SG.  In either case, it doesn't matter which SGP sent it and which ASP
received it.  The SCON is still based on PCs.  Hence, the text should be
tighten up to only state SG and AS, instead of SGP and ASP.  Only single
messages are needed, every ASP at an AS does not need to receive the
message.
	If it is sending it for the SG then I'm afraid that it didn't do
very much.  Since most traffic is for remote destinations and almost none of
the traffic is for the SG, there won't be any traffic adjustment.

> 
> 	Wouldn't the SGPs connected to the ASP also fit into this model.  If
> they are loadsharing the traffic, wouldn't all SGPs be close to going into
> congestion if one of them is already congested?  Taking the congested SGP
> out of service would only guarantee that the other SGPs will go into
> congestion.

Yes.  Not too intelligent is it.  The ASP needs to treat them differently.

[John]  Can't, see my comment above, it will do no good.

A key problem here is that the ASP is not required to do anything with
regard to messages going from ASP to SGP.  The SGP has no method of refusing
any DATA message the ASP cares to send.  All ASPs are even permitted in the
current model to send ALL their outgoing messages to one SGP if they want.
This kind of focusing could be disasterous.

[John]  Well, I don't plan on doing it this way.  We will not focus the
traffic but use the SS7 model in loadsharing it across all links (hence, all
SGPs).

In IUA and M2UA this is not a problem because traffic flow is symmetrical by
the nature of the communications links involved.  In M3UA/SUA, however,
either a symmetrical routing key concept must be used or at least some order
placed on how the ASP selects SGP.  If the SGP can individually send
DUNA/DAVA/DRST, then it has some definitive control over the traffic that
the ASP is permitted to present to it.

[John]  You are trying to treat a connection/link/association as a route,
NO.  Symmetrical configurations should be recommended instead.  IUA and M2UA
are using an SS7 network model, M3UA should do the same; then there wouldn't
be this problem.

> 
> 	Can't we reused some existing models that already work?
> 
> John
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, July 20, 2001 11:01 AM
> To: sigtran
> Subject: Re: FW: M3UA (V7) DRST question
> 
> 
> John,
> 
> If the ASP does not keep track of routing on a per-SGP
> basis, then all SGP have to be identical clones.
> 
> Any clone which becomes unidentical (e.g, congested,
> looses a route) has to take itself out of service by
> dropping all SCTP associations.
> 
> That was M3UA 06.
> 
> 
> --Brian
> 
> Schantz, John wrote:                              (Fri, 20 Jul 2001
> 08:37:39)
> > 
> > 
> > -----Original Message-----
> > From: Schantz, John 
> > Sent: Friday, July 20, 2001 9:53 AM
> > To: [email-masked]'
> > Subject: RE: M3UA (V7) DRST question
> > 
> > 
> > Brian,
> > 	I don't think I am reading a lot into "single management view".
> > This is the view that all SS7 nodes have today and if any SG wants to
> > connect into an SS7 network will need to abide by the same management
> > philosophy (it is built into the SS7 protocol).
> > 
> > 	So you're telling me that a partitioned SG will have a "single
> > management view" towards the SS7 network but it will not maintain this
> view
> > for its' SGPs.  You are basically forcing the AS to have more
complicated
> > management structure because you are not willing to build a node that
> abides
> > by the general philosophy that all other nodes in the network must abide
> by.
> > So you are asking the AS to collect management messages from each SGP,
as
> > though they are independent nodes, before the AS can then determine the
> true
> > state of a remote destination.  When are you going to stop pushing all
of
> > your dirty work onto the ASs?  Why is a limited node architecture
driving
> > the standard?  Who do you think will buy a SG like this (cheap but
almost
> no
> > network management functions)?  A small protocol converter per link
would
> be
> > better than this, at least it blindly convert the management message and
> not
> > make its presence known.
> > 
> > 	You can make it OPTIONAL but thank goodness my node will be in
> > networks with real SGs.
> > 
> > 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]
> 
> 
> ---
> 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: [email-masked]
To: "sigtran" <[email-masked]>
Subject: Re: m2ua v9 - 3.3.1.7 Congestion Indication
X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001
Date: Fri, 20 Jul 2001 15:59:33 -0400
X-MIMETrack: Serialize by Router on HQ_ACS_1/Radisys_Corporation/US(Release 
             5.0.8 |June 18, 2001) at 07/20/2001 01:02:02 PM, Serialize 
             complete at 07/20/2001 01:02:02 PM
X-SMTP-HELO: radisys.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [206.102.10.35]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Ken,

I think we need an issue number. 

If Brian is correct when he says that "Any of the remaining levels can go in
either status parameter", then either

a. we don't need two separate parameters or b. the values that go in each
param, and the circumstances for using them, have to be better explained.

Barry Nagelberg
Software Engineer
RadiSys, Corp.
Signaling Products Design Center
[email-masked]
+1-856-642-9229 x237

Ken Morneault <[email-masked]>
07/20/01 03:54 PM
Please respond to sigtran

        To:     "sigtran" <[email-masked]>
        cc: 
        Subject:        Re: m2ua v9 - 3.3.1.7 Congestion Indication

Barry,

Are Brian's comments sufficient or do we need to create an issue number?

Ken

At 02:01 PM 7/20/01 -0500, you wrote:
>Barry,
>
>How's it going?  Some comments...
>
>[email-masked] wrote:                (Fri, 20 Jul 2001
14:30:08)
> > Ken,
> > 
> > Here are some comments on 3.3.1.7  Congestion Indication:
> > 
> > 1. This is the first and last place in the draft that the term
> > "MSU buffer" is used. I would recommend stating exactly what it is
> > and in which direction the MSU's are going.
>
>I think that we all know that it refers to the SS7 Link's internal
>buffer which is used for congestion indications per Q.704.  Can
>you suggest better wording?
>
> > 
> > 2. The first sentence of the first para says "can be sent", which
> > means optional,  while the last sentence says "SHALL send", which
> > means mandatory. Then in the last para you switch back to "MAY".
> > Which is it?
>
>"can" is not a keyword: it means "is able", not "optional"
>
>The last "MAY" has already been removed.
>
> > 
> > 3. "The valid values for Congestion Status and Discard Status are
> > shown in the following table:" But there is no indication in the
> > table as to which values go in the congestion param and which go
> > in the discard param. I assume that
> > 
> >        LEVEL_NONE       0x0      No congestion.
> >        LEVEL_1          0x1      Congestion Level 1
> >        LEVEL_2          0x2      Congestion Level 2
> >        LEVEL_3          0x3      Congestion Level 3
> > 
> > go in the congestion param and that
> > 
> >        LEVEL_4          0x4      Congestion Level 4 - Discarding
> > 
> >  goes in the discard param. 
> > 
> > But it seems Level_4 is just a more severe congestion level, and
> > is mutually exclusive with the first 4 levels. So why do we need 2
> > separate params?
> > 
>
>All reference to LEVEL_4 has been removed.  Any of the remaining
>levels can go in either status parameter.
>
>-- 
>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: Fri, 20 Jul 2001 16:16:15 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: M2UA issues summary
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:

So far, there have been 8 issues registered against M2UA v9.  Below is an
update:

Issue #1 - clarification of Correlation ID / Data Ack text, reason behind
REG and DEREG message

    Status:  CLOSED

    I'm closing this issue because the Correlation ID / Data Ack is now 
    Issue #6 and reason for REG / DEREG has been sent.

Issue #2 - ASP Identifier mandatory OR addition of new Error codes

    Status:  OPEN

    There has been some good discussion on this issue.  It seems that
    the consensus is leaning towards making ASP Identifier mandatory.
    Comments?

Issue #3 - re-add Heartbeat / Heartbeat Ack

    Status:  CLOSED

    Consensus to re-add and remove limitation that ASP side must 
    initiate.

Issue #4 - Remove Reason parameter in ASP Down (Down Ack) message

    Status:  CLOSED

    Consensus to remove because no justification for Reason parameter.

Issue #5  - Support for SG Processes in M2UA

    Status:  OPEN

     Brian or I will propose text to list.

Issue #6 - Text clarification to Correlation ID / Data Ack message

    Status:  OPEN

    I need to propose text to list for adoption.

Issue #7 - how to handle Invalid Interface identifiers in ASP Active

     Status:  OPEN

     Agreement that text needs to be added to ASP Active section to describe
     procedure.  Suggested procedure is use of Error Indication (Invalid
Interface
     Identifier).  Also, suggestion to add Interface Identifier as optional
parameter
     to Error Indication so that the Invalid Interface Identifiers can be
returned
     to the ASP (instead of putting them into the Diagnostic Information
field).

Issue #8 - Need to clarify that ASP cannot send DEREG message while 
     in ASP-ACTIVE state

     Status:  OPEN

     This issue will be closed as soon as clarification text is added to the
     text.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 20 Jul 2001 15:27:49 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA (V7) DRST question
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Francois,

I'm sorry, I didn't realize from the diagram that the SGPs had the same
point code.  I suppose it was because R1/R2 looked like the way we normally
draw B/D links and R3, A links.  If what you are saying is that all the
links from the SG in the SS7 network are A-Links, then your drawing exactly
fits the case we were discussing.

Please see comments below...

Zannin, Francois wrote:                                   (Fri, 20 Jul 2001
21:00:19)
> Brian,
> 
> Thank's for your answer.
> 
> In my configuration, i'm talking about a SG seen as an unique Signaling
> point code by the ss7 network and distributed between several SGP for high
> availability of the SG.
> 
> The route's links are also distributed in all the SPG in order to always
> have some links available on all routes if one SGP fails.
> 
> Because the SG is seen as a single SP by the ss7 network, all SGP are
> managed as an unique SG entity.
> This involve a communication between the several SGP.
> 
> What could be the behavior of this kind of configuration in case of
> communication problem between the SGP?
> 
> Regards,
> 
> Francois Z.
> 
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, July 20, 2001 6:07 PM
> To: sigtran
> Subject: Re: M3UA (V7) DRST question
> 
> 
> Francois,
> 
> I think from the discussion so far that the SGPs in your
> diagram would be considered to be three separate SGs,
> rather than a single SG as you have drawn it.
> 
> I believe the dicussion is focussing on multiple SGPs in
> an SG which represents a single SPMC or a single point code.
> 
> --Brian
> 
> 
> Zannin, Francois wrote:                                   (Fri, 20 Jul
2001
> 16:31:31)
> > Hello,
> > 
> > This is our understanding of the use of the DRST and partitioning
between
> > the SGP.
> > See below,
> > Do you agree with this?
> >     Regards,
> >     Francois Z.
0000000001111111111222222222233333333334444444444555555555566666666667777777
> > 7778
1234567890123456789012345678901234567890123456789012345678901234567890123456
> > 7890
> > 
> >      SS7 World                              IP World
> >  ============================          =================
> >                                S.G.                       A.S.
> >                           ..............
> >  +----+     +-----+ R1    . +-------+  .               +-------+
> >  |SP_1|-----|STP_A|---------| SGP_1 |-----------[As0]--|       |
> >  +----+     |     |---   ---|       |  .    ----[As1]--| ASP_1 |
> >             +-----+   \ / . +---++--+  .   / ---[As2]--|       |
> >                        \  .     ||     .  / /          +-------+
> >  +----+     +-----+   / \ . +---++--+  . / /
> >  |SP_2|-----|STP_B|---   ---| SGP_2 |---- /
> >  +----+     |     |---------|       |  . /
> >             +--+--+ R2    . +---++--+  ./
> >           Clink|          .     ||     / 
> >  +----+     +--+--+       . +---++--+ /.
> >  |SP_3|-----|STP_C|---------| SGP_3 |- .
> >  +----+     |     |---------|       |  .
> >             +-----+ R3    . +-------+  .
> >                           ..............
> > 
> > In this configuration,
> > The destination SP_2 can be reached via R2 (STP_B) and if R2 
> > fails, via R3 (STP_C).
> > 
> > ASP_1 is connected to SGP_1 by the association As0 
> > ASP_1 is connected to SGP_2 by the association As1 
> > ASP_1 is connected to SGP_3 by the association As2 
> > 
> > SP_2 can be reached via STP_B which is connected to SGP_1 and
> > SGP_2 for redundancy perspective.  ASP_1 will use links As0 and
> > As1 to send messages to SP_2 and only uses As2 if As0 and As1
> > fail.

Ok.

> > 
> > With this configuration the DAVA are sent from SGP_1, SGP_2 and
> > SGP_3 BUT SGP_3 can also send a DRST to inform ASP_1 that it
> > should use As0 and As1 in priority. This DRST is not the result
> > of a TFR message.

Ok. This was what Greg was driving at: use of the DRST to allow the SGP to
communicate internal inefficiencies to the ASPs.

> > 
> > If a TFR is received from STP_B, this information is distributed
> > to all the SGP and then all the SGP send a DRST to the ASP.
> > These DRST can be used by the ASP to reroute the traffic on
> > another SG if there is one available.

Ok. Makes sense.

> > 
> > All the MTP3 information must be distributed to all the SGP
> > because if the route R2 fails, all the messages already sent
> > from the ASP to SGP_1 and SGP_2 before the receipt of a DRST
> > must be forwarded to the SGP_3 for the time controlled diversion
> > between R2 to R3 or R3 to R2 if R2 restarts.

I think you mean DUNA here instead of DRST.

Here I disagree SGP_1 still has a route to SP_2 and you told us that the ASP
only uses As0 (until it fails) so the ASP can still route as normal.  If by
"R2 fails" a double linkset failure at STP_B, I can tell you this (a)
doesn't happen and (b) even the SS7 network is not designed to handle
simultaneous double linkset failures.

Nevertheless, if there is this double link failure, SGP_1 (the only one
receiving traffic) must transfer buffered and collected messages to SGP_3.

See below...

> > 
> > If the platform is partitioned, message sequencing cannot be
> > performed between the ASP and the ss7 SP. Another problem that
> > occurs in a partitioned platform is that the network management
> > messages concerning one route may be sent on another route
> > because the ss7 network sees the SG as an unique point code.
> > 
> > If we chose to have a partitioned platform, we must be sure that
> > we never will receive management messages on another route then
> > the one it concerns and this depend of the ss7 network
> > configuration. 
> > 
> > ==================================================================
> >   ALL THIS BEHAVIOR IS TRUE IF THE SGP ARE DIRECTLY CONNECTED TO 
> >   THE SS7 NETWORK WITHOUT INTERMEDIATE PROCESSES.
> > ==================================================================
> > 

Your rather artificial example shows excellent reasons why:

	1.  We don't build SS7 network that way, and,

	2.  We don't build Signalling Gateways that way.

Here is a real example of a real SS7 network and an intelligent partitioned
SS7 design: (I'll just borrow most of your diagram...)

     SS7 World                              IP World
============================          =================
                               S.G.                       A.S.
                          ..............
 +----+A0   +-----+  L0   . +-------+  .               +-------+
|SP_1|-----|STP_A|---------| SGP_1 |-----------[As0]--|       |  +----+   /
|     |-- L1  --|       |  .    ----[As0]--| ASP_1 |
    A1 \ /  +-----+  \   /. +-------+  .   / ---[As0]--|       |
     A2 X   /  |   \  \ / .     |      .  / /          +-------+  +----+/ \
/   | L2 \  X  . +-------+  . / /  |SP_2|   X C-links  \/ ----| SGP_2 |----
/  +----+\ / \   |     /\ ----|       |  . /
     A3 X   \  | L3 /  X  . +-------+  ./
    A4 / \   \ |   /  / \ .     |      /  +----+   \ +--+--+  /   \.
+-------+ /.
 |SP_3|-----|STP_C|-- L4  --| SGP_3 |- .
 +----+A5   |     |---------|       |  .
            +-----+  L5   . +-------+  .
                          ..............

Now, in this example the SPs are connected full fishbone, as they should.
The links of the linksets between the STPs and the SGP are groomed across
all SGP, but the SGP still represent a signle point code.  ASP_1 is
configured/ registered against As0 for all of the SGP.  ASP_1 uses a
distribution algorithm which loadshares messages over the available SGP on
the basis of SLS.

     SS7 World                              IP World
============================          =================
                               S.G.                       A.S.
                          ..............
 +----+A0            L0   . +-------+  .               +-------+  |SP_1|
STP_A       ---| SGP_1 |-----------[As0]--|       |  +----+               L1
--|       |  .    ----[As0]--| ASP_1 |
    A1 \                 /. +-------+  .   / ---[As0]--|       |
     A2 X      |        / .     |      .  / /          +-------+  +----+  \
| L2    X  . +-------+  . / /  |SP_2|   X C-links   /  ---| SGP_2 |---- /
+----+\   \   |     /  ----|       |  . /
     A3 X   \  | L3 /  X  . +-------+  ./
    A4   \   \ |   /  /   .     |      /  +----+   \ +--+--+  /    .
+-------+ /.
 |SP_3|-----|STP_C|-- L4  --| SGP_3 |- .
 +----+A5   |     |---------|       |  .
            +-----+  L5   . +-------+  .
                          ..............

Now, let's get blue moon: STP_A fails completely as shown above.
(Now this takes a natural disaster because STPs are built well.) Links L0,
L1, and L2 vaporize.  The SG does not even tell the ASP.  It changes over
traffic from L0->L3, L1->L4 and L2->L5 without even consulting the ASP.  To
perform normal changeover may require the transfer of COO/COA between SGP,
but that's low traffic.  If SGP become partitioned, changeover will still
complete as emergency changeover.

Ok, STP_A recovers and we change back.  We had a natural disaster and didn't
lose a message.

     SS7 World                              IP World
============================          =================
                               S.G.                       A.S.
                          ..............
 +----+A0   +-----+  L0   . +-------+  .               +-------+
|SP_1|-----|STP_A|---------| SGP_1 |-----------[As0]--|       |  +----+
|     |-- L1  --|       |  .    ----[As0]--| ASP_1 |
    A1 \    +-----+  \   /. +-------+  .   / ---[As0]--|       |
     A2 X   /  |   \  \ / .     |      .  / /          +-------+  +----+  \
/   | L2 \  X  . +-------+  . / /  |SP_2|   X C-links  \/ ----| SGP_2 |----
/  +----+\ / \   |     /\ ----|       |  . /
     A3 X   \  | L3 /  X  . +-------+  ./
    A4 / \   \ |   /  / \ .     |      /  +----+   \ +--+--+  /   \.
+-------+ /.
 |SP_3|-----|STP_C|-- L4  --| SGP_3 |- .
 +----+A5   |     |---------|       |  .
            +-----+  L5   . +-------+  .
                          ..............

Now suppose that SP_2 loses link A2 as shown above.  STP_A will changeover
traffic to SP_2 to its C-links and send a TFR with respect to SP_2 on, say,
L0.  SGP_1 must communicate the TFR to the SGP_2 and SGP_3, but again, that
is not traffic.  Then SGP_1, SGP_2 and SGP_3 perform controlled rerouting of
traffic to SP_2 from L0, L1 and L2 to L3, L4 and L5.  The ASP does not need
to be informed.

Link A2 recovers.  The SGP's controlled reroute SP_2 traffic back to all
links.

     SS7 World                              IP World
============================          =================
                               S.G.                       A.S.
                          ..............
 +----+A0   +-----+  L0   . +-------+  .               +-------+
|SP_1|-----|STP_A|---------| SGP_1 |-----------[As0]--|       |  +----+   /
|     |-- L1  --|       |  .    ----[As0]--| ASP_1 |
    A1 \ /  +-----+      /. +-------+  .   / ---[As0]--|       |
     A2 X   /  |   \    / .     |      .  / /          +-------+  +----+/ \
/   | L2 \  X  . +-------+  . / /  |SP_2|   X C-links  \/    -| SGP_2 |----
/  +----+\ / \   |     /\    -|       |  . /
     A3 X   \  | L3 /  X  . +-------+  ./
    A4 / \   \ |   /    \ .     |      /  +----+   \ +--+--+      \.
+-------+ /.
 |SP_3|-----|STP_C|-- L4  --| SGP_3 |- .
 +----+A5   |     |---------|       |  .
            +-----+  L5   . +-------+  .
                          ..............

So, now, assume that SGP_2 loses both its links L1 and L4, as shown above.
This is a blue moon occurence because L1 and L4 are space diverse and the
probability of dual failure is extremely small (it is more likely that SGP_2
will fail).  SGP_2 does not need to send anything to the ASP.  It ABORTs the
association.  Because this is a blue moon occurence and the SG is acting as
an SEP which does not necessarily have to be lossless, SGP_2 could
optionally discard any collected or buffered messages.  It could also
transfer half of them (by SLS) to SGP_1 and the other half to SGP_3.

If SGP_2 can access the link processors for L0, L1, L4 or L5, it can change
over traffic onto the links without communicating with SGP_1 and SGP_3.

ASP_1 is forced to hold back traffic for a time (i.e., perform
time-controlled changeover) before starting the old traffic on the new SGP.

L1 and L4 recover. SGP_2 now permits associations and/or ASPAC from ASP_1.
ASP_1 holds its traffic for a time and then resumes its load sharing with
SGP_2 included.

     SS7 World                              IP World
============================          =================
                               S.G.                       A.S.
                          ..............
 +----+A0   +-----+  L0   . +-------+  .               +-------+
|SP_1|-----|STP_A|---------| SGP_1 |-----------[As0]--|       |  +----+
|     |-- L1   -|       |  .    ----[As0]--| ASP_1 |
    A1 \    +-----+  \    . +-------+  .   / ---[As0]--|       |
     A2 X   /  |   \  \   .     |      .  / /          +-------+  +----+  \
/   | L2 \  X  . +-------+  . / /  |SP_2|   X C-links  \  ----| SGP_2 |----
/  +----+\ / \   |      \    -|       |  . /
     A3 X   \  | L3    X  . +-------+  ./
    A4 / \   \ |        \ .     |      /  +----+   \ +--+--+      \.
+-------+ /.
 |SP_3|-----|STP_C|-  L4  --| SGP_3 |- .
 +----+A5   |     |-       -|       |  .
            +-----+  L5   . +-------+  .
                          ..............

So.  How does the ASP get a DRST? or a DUNA?

To send a DRST I would have to fail SP_2-A2, L3, L4, and L5, as shown above.
That's a quadruple simultaneous link failure.
The SS7 network is having a hard time today!  STP_A will send TFR on, say,
L0 and SGP_1 will distribute it to SGP_2 and SGP_3.
Each SGP will realize that it has no other route and send DRST to ASP_1.
ASP_1, realizing that it has no other route, will do nothing.

     SS7 World                              IP World
============================          =================
                               S.G.                       A.S.
                          ..............
 +----+A0   +-----+  L0   . +-------+  .               +-------+
|SP_1|-----|STP_A|---------| SGP_1 |-----------[As0]--|       |  +----+
|     |-- L1   -|       |  .    ----[As0]--| ASP_1 |
    A1 \    +-----+  \    . +-------+  .   / ---[As0]--|       |
     A2 X   /      \  \   .     |      .  / /          +-------+  +----+  \
/     L2 \  X  . +-------+  . / /  |SP_2|   X C-links  \  ----| SGP_2 |----
/  +----+\ / \          \    -|       |  . /
     A3 X   \    L3    X  . +-------+  ./
    A4 / \   \          \ .     |      /  +----+   \ +--+--+      \.
+-------+ /.
 |SP_3|-----|STP_C|-  L4  --| SGP_3 |- .
 +----+A5   |     |-       -|       |  .
            +-----+  L5   . +-------+  .
                          ..............

Now, (even a worse day for the SS7 network), STP_A loses its C-links (all of
them), as shown above.  Now the STP_A can no longer communicate with SP_2
and it sends TFP to the S.G.
on, say, L2.  SGP_3 distributes routing updates to SGP_1 and SGP_2.  All
SGPs send DUNA to ASP_1.  ASP_1 stops traffic for SP_2 and delivers
MTP-PAUSE(SP_2) to users which have a route to SP_2.

     SS7 World                              IP World
============================          =================
                               S.G.                       A.S.
                          ..............
 +----+A0   +-----+  L0   . +-------+  .               +-------+
|SP_1|-----|STP_A|---------| SGP_1 |-----------[As0]--|       |  +----+
|     |-- L1   -|       |  .    ----[As0]--| ASP_1 |
    A1 \    +-----+       . +-------+  .   / ---[As0]--|       |
     A2 X   /      \      .     |      .  / /          +-------+  +----+  \
/     L2 \  X  . +-------+  . / /  |SP_2|   X C-links  \     -| SGP_2 |----
/  +----+\ / \          \ ----|       |  . /
     A3 X   \    L3    X  . +-------+  ./
    A4 / \   \        / \ .     |      /  +----+   \ +--+--+  /   \.
+-------+ /.
 |SP_3|-----|STP_C|-- L4  --| SGP_3 |- .
 +----+A5   |     |-       -|       |  .
            +-----+  L5   . +-------+  .
                          ..............

Now let's mix it up.  Let's recover link L3 and fail link L2 resulting in
the above.  ASP_1 is sent DAVA for SP_2 only from SGP_2.  ASP_1, because it
is performing per-SGP routing restarts traffic to SP_2 to SGP_2 and sends
MTP-RESUME(SP_2) to its users.

Now with all these links down, we have still not lost any messages and there
has been no situation where we have needed to route DATA traffic between
SGP.  Which is what I said: I don't want to have to route User Data traffic
between SGP.

Note that this will only work if the ASP pays attention.

--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: Fri, 20 Jul 2001 15:32:41 -0500
From: Jeff Copley <[email-masked]>
Organization: Alcatel USA, Inc.
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: Updated SUA sent out
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]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Are we supposed to use this new form for last call or just for any ole
comment?  Also, does this suggest that comments not following this form will
be treated with less preference?  And is this form IETF procedure? 
Just learning.  jc

[email-masked] wrote:
> 
> Hi all,
> 
> I have just sent out an update version of SUA to the IETF Drafts
> Editor.  With any luck, it will be in an inbox near you soon.
> For those of you who are filled with anticipation, you can get
> a preview of it here:
> 
>         http://www-nrc.nokia.com/sua/sua.htm
> 
> As I feel it is quite stable, I would like the WG to consider this
> version for last call.
> 
> I'm going to try to track any issues via a web page - if the WG
> and Lyndon don't mind.  Taking a page off of the AAA WG, I suggest
> a template that looks like the following:
> 
> To submit a new issue, send an e-mail to the SIGTRAN, using the
> following template:
> 
> Description of issue
> Submitter name: Your_Name_Here
> Submitter email address: Your_Email_Address_Here
> Date first submitted: Insert_Date_Here
> Reference: URL to e-mail describing problem, if available
> Comment type: ['T'echnical | 'E'ditorial]
> Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
> Section: Insert_Section_Number_Here
> Rationale/Explanation of issue:
> Length description of problem
> 
> Requested change:
> Proposal
> 
> And if you can use [SUAv7] in any mails, I'd appreciate it.
> 
> Thanks,
> John
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked] Attachment Converted:
"c:\program files\qualcomm\eudora pro\attach\Jeff.Copley7.vcf" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 20 Jul 2001 15:40:39 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: m2ua v9 - 3.3.1.7 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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Barry,

Would it suffice to reference, say, ANSI T1.111.4 Section 3.8.2. ?

[email-masked] wrote:                (Fri, 20 Jul 2001
15:59:33)
> Ken,
> 
> I think we need an issue number. 
> 
> If Brian is correct when he says that "Any of the remaining levels can go
in
> either status parameter", then either
> 
> a. we don't need two separate parameters or 
>
> b. the values that go in each param, and the circumstances for using them,
>    have to be better explained.

-- 
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 v9 - 3.3.1.7 Congestion Indication
X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001
Date: Fri, 20 Jul 2001 16:52:11 -0400
X-MIMETrack: Serialize by Router on HQ_ACS_1/Radisys_Corporation/US(Release 
             5.0.8 |June 18, 2001) at 07/20/2001 01:54:39 PM, Serialize 
             complete at 07/20/2001 01:54:39 PM
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]

Brian,

If the referenced document sufficiently explains what these params mean and
when they should be used, then it is sufficient.

Barry Nagelberg
Software Engineer
RadiSys, Corp.
Signaling Products Design Center
[email-masked]
+1-856-642-9229 x237

"Brian F. G. Bidulock" <[email-masked]> 07/20/01 04:40 PM
Please respond to sigtran

        To:     "sigtran" <[email-masked]>
        cc: 
        Subject:        Re: m2ua v9 - 3.3.1.7 Congestion Indication

Barry,

Would it suffice to reference, say, ANSI T1.111.4 Section 3.8.2. ?

[email-masked] wrote:                (Fri, 20 Jul 2001
15:59:33)
> Ken,
> 
> I think we need an issue number. 
> 
> If Brian is correct when he says that "Any of the remaining levels can go
in
> either status parameter", then either
> 
> a. we don't need two separate parameters or 
>
> b. the values that go in each param, and the circumstances for using them,
>    have to be better explained.

-- 
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, 20 Jul 2001 15:25:59 +0530
From: manish kumar mishra <[email-masked]>
Reply-To: [email-masked]
Organization: Mercury Corporation
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
To: Ken Morneault <[email-masked]>, Lyndon Ong
<[email-masked]>
Subject: m2ua comments

<draft-ietf-sigtran-m2ua-09.txt>
 few comments on M2UA draft 9:
3.3.1.1 Data
        "The Correlation Id parameter uniquely identifies the MSU carried in
the protocol Data within a Routing Context. This Correlation Id parameter is
assigned by the sending M3UA."

        Nowhere in the draft anything about Routing Context is mentioned.
Routing context is a term used in M3UA. Perhaps this text was originally
proposed for M3UA.

3.3.1.5  State Confirm
        "The State Confirm message will be sent by the SG in response to a
State Request from the MGC."
 After deleting the Result field from the message in version 9,the response
from the SG is always taken as success by ASP. why have the state confirm
message at all?

3.3.1.6  State Indication
        "The MTP2 State Indication message can be sent from a gateway to an
ASP to indicate a condition on a link."

   EVENT_RPO_ENTER      Remote entered processor outage
   EVENT_RPO_EXIT       Remote exited processor outage
   EVENT_LPO_ENTER      Link entered processor outage
   EVENT_LPO_EXIT       Link exited processor outage

        What is the difference between RPO Enter and LPO Enter and RPO Exit
and LPO Exit? What is the relation between STATUS_LPO_SET/CLEAR in state
request/confirm and EVENT_LPO_ENTER/EXIT in state indication?

3.3.1.8  Retrieval Request
        "The valid values for Action are shown in the following table.
        Define         Value       Description
   ACTION_RTRV_BSN      0x1     Retrieve the backward sequence number
   ACTION_RTRV_MSGS     0x2     Retrieve the PDUs from the transmit
                                                        and retransmit
queues
In the Retrieval Request message, the Sequence Number field SHOULD NOT be
present if the Action field is ACTION_RTRV_BSN, ACTION_DROP_MSGS or
ACTION_RTRV_TRANS."

3.3.1.9  Retrieval Confirm
        "For a Retrieval Confirm with an Action of ACTION_DROP_MSGS, the
Result value will indicate success or failure.  The Sequence Number field is
not used with ACTION_DROP_MSGS."

        Since ACTION_DROP_MSGS and ACTION_RTRV_TRANS havebeen removed both
these texts are inconsistent with the valid values of the Action field as
defined in section 3.3.1.8

Best Regards,
Manish

Sender: [email-masked]
Date: Fri, 20 Jul 2001 10:02:40 -0500
From: Tom George <[email-masked]>
Organization: Alcatel USA, Inc.  http://www.usa.alcatel.com 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: en
To: [email-masked], Lyndon Ong <[email-masked]>
Subject: draft-ietf-sigtran-m2pa-03.txt

 Network Working Group                                      Tom George
INTERNET-DRAFT                                                Alcatel
                                                            Ram Dantu
                                                        Cisco Systems
                                                      Malleswar Kalla
                                                            Telcordia
                                           Hanns Juergen Schwarzbauer
                                                              Siemens
                                                      Greg Sidebottom
                                                        Ken Morneault
                                                        Cisco Systems

  Expires January 2002                                    July 20, 2001

             SS7 MTP2-User Peer-to-Peer Adaptation Layer
                  <draft-ietf-sigtran-m2pa-03.txt> 

Status of This Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. Internet-Drafts are working documents
of the Internet Engineering Task Force (IETF), its areas, and its working
groups.  Note that other groups may also distribute working documents as
Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and
may be updated, replaced, or obsoleted by other documents at any time.  It
is inappropriate to use Internet-Drafts as reference material or to cite
them other than as 'work in progress.'

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

To learn the current status of any Internet-Draft, please check the
'1id-abstracts.txt' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

George, et al                                                 [Page 1] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

Abstract

This Internet Draft defines a protocol supporting the transport of Signaling
System Number 7 (SS7) Message Transfer Part (MTP) Layer 3 signaling messages
over Internet Protocol (IP) using the services of the Stream Control
Transmission Protocol (SCTP).  This protocol would be used between SS7
Signaling Points employing the MTP Level 3 protocol. The SS7 Signaling
Points may also employ standard SS7 links using the SS7 MTP Layer 2 to
provide transport of MTP Layer 3 signaling messages.

George, et al                                                 [Page 2] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

                        TABLE OF CONTENTS

1.  Introduction............................................. 4
  1.1  Scope................................................. 4
  1.2  Terminology........................................... 4
  1.3  Abbreviations......................................... 5
  1.4  Conventions........................................... 6
  1.5  Signaling Transport Architecture...................... 6
  1.6  Services Provided by M2PA............................. 8
  1.7  Functions Provided by M2PA............................ 9
  1.8  Definition of the M2PA Boundaries.....................10
  1.9  Differences Between M2PA and M2UA.....................12 2.  Protocol
Elements........................................14
  2.1  Common Message Header.................................14
  2.2  M2PA Messages.........................................16 3.  M2PA
Link State Control..................................19 4.
Procedures...............................................22
  4.1  Procedures to Support MTP2 Features...................22
  4.2  Procedures to Support the MTP3/MTP2 Interface.........31 5.  Examples
of M2PA Procedures..............................36
  5.1  Link Initialization (Alignment).......................36
  5.2  Message Transmission and Reception....................39
  5.3  Link Status Indication................................39
  5.4  Link Status Message (Processor Outage)................40
  5.5  Level 2 Flow Control..................................41
  5.6  MTP3 Signaling Link Congestion........................43
  5.7  Link Deactivation.....................................44
  5.8  Link Changeover.......................................45 6.
Security.................................................47
  6.1  Threats...............................................47
  6.2  Protecting Confidentiality............................47 7.  IANA
Considerations......................................48
  7.1  SCTP Payload Protocol Identifier......................48
  7.2  M2PA Protocol Extensions..............................48 8.
Acknowledgements.........................................49 9.
References...............................................50 10. Authors'
Addresses.......................................51

George, et al                                                 [Page 3] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

1. Introduction

1.1 Scope

There is a need for Switched Circuit Network (SCN) signaling protocol
delivery over an IP network.  This includes message transfer between the
following: 

   - a Signaling Gateway (SG) and a Media Gateway Controller (MGC)
     [1]

   - a SG and an IP Signaling Point (IPSP)

   - an IPSP and an IPSP

This could allow for convergence of some signaling and data networks. SCN
signaling nodes would have access to databases and other devices in the IP
network domain that do not employ SS7 signaling links. Likewise, IP
telephony applications would have access to SS7 services. There may also be
operational cost and performance advantages when traditional signaling links
are replaced by IP network "connections".

The delivery mechanism described in this document allows for full MTP3
message handling and network management capabilities between any two SS7
nodes, communicating over an IP network. An SS7 node equipped with an IP
network connection is called an IP Signaling Point (IPSP). The IPSPs
function as traditional SS7 nodes using the IP network instead of SS7 links.

The delivery mechanism should

   - Support seamless operation of MTP3 protocol peers over an IP
     network connection.

   - Support the MTP Level 2 / MTP Level 3 interface boundary.

   - Support management of SCTP transport associations and traffic
     instead of MTP2 Links.

   - Support asynchronous reporting of status changes to management.

1.2 Terminology

MTP - The Message Transfer Part of the SS7 protocol [2] [3].

MTP2 - MTP Level 2, the MTP signaling link layer.

MTP3 - MTP Level 3, the MTP signaling network layer.

George, et al                                                 [Page 4] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

MTP2-User - A protocol that normally uses the services of MTP Level 2. The
only MTP2 user is MTP3. The MTP2 user is equivalent to the M2PA user.

Signaling End Point (SEP) - A node in an SS7 network that originates or
terminates signaling messages.  One example is a central office switch.

IP Signaling Point (IPSP) - An SS7 Signaling Point with an IP network
connection used for SS7 over IP. 

Signaling Gateway (SG) - A signaling agent that receives/sends SCN native
signaling at the edge of the IP network [4]. In this context, an SG is an
SS7 Signaling Point that has both an IP network connection used for SS7 over
IP, and a traditional (non-IP) link to an SS7 network.

Signaling Transfer Point (STP) - A node in an SS7 network that routes
signaling messages based on their destination point code in the SS7 network.

Association - An association refers to a SCTP association [5]. The
association provides the transport for MTP3 protocol data units and M2PA
adaptation layer peer messages.

Network Byte Order - Most significant byte first, also known as "Big
Endian". See [15], Appendix B Data Transmission Order.

Stream - A stream refers to a SCTP stream [5].  

1.3 Abbreviations

BSNT   - Backward Sequence Number to be Transmitted

FSNC   - Forward Sequence Number of last message accepted by 
         remote level 2

LI     - Length Indicator

MSU    - Message Signal Unit

SCCP   - Signaling Connection Control Part

SCN    - Switched Circuit Network

SCTP   - Stream Control Transmission Protocol

SIF    - Signaling Information Field

SIO    - Service Information Octet

SLC    - Signaling Link Code

George, et al                                                 [Page 5] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

SS7    - Signaling System Number 7

SSN    - Stream Sequence Number

STP    - Signal Transfer Point

1.4 Conventions

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [8].

1.5 Signaling Transport Architecture

The architecture that has been defined [4] for Switched Circuit Network
(SCN) signaling transport over IP uses multiple components, including an IP
transport protocol, the Stream Control Transmission Protocol (SCTP), and an
adaptation module to support the services expected by a particular SCN
signaling protocol from its underlying protocol layer.

Within this framework architecture, this document defines an SCN adaptation
module that is suitable for the transport of SS7 MTP3 messages.

Figure 1 shows the seamless interworking at the MTP3 layer.  MTP3 is adapted
to the SCTP layer using the MTP2 User Peer-to-peer Adaptation Layer (M2PA).
All the primitives between MTP3 and MTP2 are supported by M2PA.  The SCTP
association acts as one SS7 link between the IPSPs.
An IPSP may have the Signaling Connection Control Part (SCCP) and other SS7
layers above MTP3.

George, et al                                                 [Page 6] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

            ********   IP   ********
            * IPSP *--------* IPSP *
            ********        ********

            +------+        +------+
            | TCAP |        | TCAP |
            +------+        +------+
            | SCCP |        | SCCP |
            +------+        +------+
            | MTP3 |        | MTP3 | 
            +------+        +------+    
            | M2PA |        | M2PA |    
            +------+        +------+    
            | SCTP |        | SCTP | 
            +------+        +------+
            | IP   |        | IP   |
            +------+        +------+

    IP    - Internet Protocol
    IPSP  - IP Signaling Point
    SCTP  - Stream Control Transmission Protocol
            (see Reference [5])

         Figure 1:  M2PA Symmetrical Peer-to-Peer Architecture

Figure 2 shows an example of M2PA used in a Signaling Gateway (SG). The SG
is an IPSP equipped with both traditional SS7 and IP network connections.
In effect, the Signaling Gateway acts as a Signal Transfer Point (STP).  Any
of the nodes in the diagram could have SCCP or other SS7 layers. STPs may or
may not be present in the SS7 path between the SEP and the SG.

George, et al                                                 [Page 7] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

    ********  SS7   ***************   IP   ********
    * SEP  *--------*     SG      *--------* IPSP *
    ********        ***************        ********

    +------+                               +------+
    | TCAP |                               | TCAP |
    +------+                               +------+
    | SCCP |                               | SCCP |
    +------+        +-------------+        +------+
    | MTP3 |        |    MTP3     |        | MTP3 | 
    +------+        +------+------+        +------+    
    | MTP2 |        | MTP2 | M2PA |        | M2PA |    
    +------+        +------+------+        +------+    
    | MTP1 |        | MTP1 | SCTP |        | SCTP | 
    |      |        |      +------+        +------+
    |      |        |      | IP   |        | IP   |
    +------+        +------+------+        +------+

    SEP   - SS7 Signaling Endpoint

         Figure 2:  M2PA in IP Signaling Gateway

Figure 2 is only an example. Other configurations are possible. For example,
IPSPs without traditional SS7 links could use the protocol layers
MTP3/M2PA/SCTP/IP to route SS7 messages in a network with all IP links.

Another example, related to Figure 2, is that two SGs could be connected
over an IP network to form an SG mated pair similar to the way STPs are
provisioned in traditional SS7 networks.

1.5.1  Point Code Representation

The MTP specification requires that each node with an MTP3 layer is
identified by an SS7 point code. In particular, each IPSP must have its own
SS7 point code.

1.6 Services Provided by M2PA

The SS7 MTP3/MTP2 (MTP2-User) interface is retained in the IPSP. The M2PA
protocol layer is required to provide the equivalent set of services to its
user as provided by MTP Level 2 to MTP Level 3.

These services are described in the following subsections.

1.6.1 Support for MTP Level 2 / MTP Level 3 interface boundary

This interface is the same as the MTP2/MTP3 interface described in [2], [3]
and [10], with the addition of support for larger sequence numbers in [3]
and [7].

George, et al                                                 [Page 8] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

Because SCTP uses larger sequence numbers than MTP, the MTP3 Changeover
procedure must use the Extended Changeover Order and Extended Changeover
Acknowledgment messages described in [7] and [3]. This will allow for use of
the SCTP stream sequence numbers in the changeover messages.

Also, the following MTP3/MTP2 primitives must use the larger sequence
numbers:

   - BSNT Confirmation

   - Retrieval Request and FSNC

1.6.2 Support for peer-to-peer communication

In SS7, MTP Level 2 sends three types of messages, known as signal units:
Message Signal Units (MSUs), Link Status Signal Units (LSSUs), and Fill-In
Signal Units (FISUs).

MSUs originate at a higher level than MTP2, and are destined for a peer at
another node. Likewise, M2PA passes these messages from MTP3 to SCTP as data
for transport across a link. These are called User Data messages in M2PA.

LSSUs allow peer MTP2 layers to exchange status information. Analogous
messages are needed for M2PA. The Link Status message serves this purpose.

FISUs are sent when no other signal units are waiting to be sent. This
purpose is served by the heartbeat messages in SCTP. FISUs also carry
acknowledgment of messages. This function is performed by SCTP. Therefore,
it is unnecessary for M2PA to provide a protocol data unit like the FISU.

1.7 Functions Provided by M2PA

1.7.1 Support of MTP3/MTP2 Primitives

M2PA receives the primitives sent from MTP3 to its lower layer. M2PA
processes these primitives or maps them to appropriate primitives at the
M2PA/SCTP interface. Likewise, M2PA sends primitives to MTP3 like those used
in the MTP3/MTP2 interface.

1.7.2 MTP2 Functionality

M2PA provides MTP2 functionality that is not provided by SCTP. This includes

George, et al                                                 [Page 9] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

   - Data retrieval to support the MTP3 changeover procedure

   - Reporting of link status changes to MTP3

   - Processor outage procedure

   - Link alignment procedure

1.7.3 Mapping of SS7 and IP Entities

The M2PA layer must maintain a map of each of its SS7 links to the
corresponding SCTP association.

1.7.4 SCTP Stream Management

SCTP allows a user-specified number of streams to be opened during the
initialization.  It is the responsibility of the M2PA layer to ensure proper
management of the streams allowed within each association.

M2PA uses two streams in each direction for each association. Stream 0 in
each direction is designated for Link Status messages. Stream 1 is
designated for User Data and Proving Data messages. Separating the Link
Status and User Data messages onto separate stream allows M2PA to prioritize
the messages in a manner similar to MTP2.

1.7.5  Retention of MTP3 in the SS7 Network 

M2PA allows MTP3 to perform all of its Message Handling and Network
Management functions with IPSPs as with other SS7 nodes.

1.8 Definition of the M2PA Boundaries

1.8.1 Definition of the M2PA / MTP Level 3 boundary

The upper layer primitives provided by M2PA are the same as those provided
by MTP2 to MTP3. These primitives are described in [2], [3], and [10].
Following is a list of the primitives.

Primitives sent from MTP3 to M2PA:

Data Request - Used to send a Data Message for transmission.

Start Request - Used to activate a link.

Stop Request - Used to deactivate a link.

Retrieve BSNT Request - Request the BSNT for the changeover procedure.

George, et al                                                [Page 10] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

Retrieval Request and FSNC - Request retrieval of unacknowledged and unsent
messages. This request includes the FSNC received from the remote end. 

Local Processor Outage Request - Informs M2PA of a local processor outage
condition.

Local Processor Outage Recovered Request - Informs M2PA that a local
processor outage condition has ceased.

Flush Buffers Request - Requests that all transmit and receive buffers be
emptied.

Continue Request - Requests that processing resume after a processor outage.

Emergency Request - Requests that M2PA use the emergency alignment
procedure.

Emergency Ceases Request - Requests that M2PA use the normal alignment
procedure.

Primitives sent from M2PA to MTP3:

Data Indication - Used to deliver received Data Message to MTP3.

Congestion Indication - Indicates change in congestion status. The
indication includes the congestion status, if the protocol is using the
optional congestion levels. The indication also includes the discard status.

In Service Indication - Indicates that the link is in service.

Out of Service Indication - Indicates that the link is out of service.

Retrieved Messages Indication - Indicates delivery of unacknowledged and
unsent messages.

Retrieval Complete Indication - Indicates that delivery of unacknowledged
and unsent messages is complete.

BSNT Confirm - Replies to the BSNT Request. The confirmation includes the
BSNT.

BSNT Not Retrievable Confirm - Replies to the BSNT Request when the BSNT
cannot be determined.

Remote Processor Outage Indication - Indicates processor outage at remote
end.

Remote Processor Recovered Indication - Indicates recovery from processor
outage at remote end.

George, et al                                                [Page 11] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

1.8.2 Definition of the Lower Layer Boundary between M2PA and SCTP

The upper layer primitives provided by SCTP are described in Reference [5]
Section 10 "Interface with Upper Layer".

1.9 Differences Between M2PA and M2UA

The MTP2 User Adaptation Layer (M2UA) [6] also adapts the MTP3 layer to the
SCTP/IP stack. It does so through a backhauling architecture [4]. This
section intends to clarify some of the differences between the M2PA and M2UA
approaches.

A possible M2PA architecture is shown in Figure 3. Here the IPSP's MTP3 uses
its underlying M2PA as a replacement for MTP2. Communication between the two
layers MTP3/M2PA is defined by the same primitives as in SS7 MTP3/MTP2. M2PA
performs functions similar to MTP2.

A comparable architecture for M2UA is shown in Figure 4. In M2UA, the MGC's
MTP3 uses the SG's MTP2 as its lower SS7 layer. Likewise, the SG's MTP2 uses
the MGC's MTP3 as its upper SS7 layer. In SS7, communication between the
MTP3 and MTP2 layers is defined by primitives. In M2UA, the MTP3/MTP2
communication is defined as M2UA messages and sent over the IP connection.

George, et al                                                [Page 12] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

    ********  SS7   ***************   IP   ********
    * SEP  *--------*     SG      *--------* IPSP *
    ********        ***************        ********

    +------+        +-------------+        +------+
    | SCCP |        |    SCCP     |        | SCCP |
    +------+        +-------------+        +------+
    | MTP3 |        |    MTP3     |        | MTP3 | 
    +------+        +------+------+        +------+    
    | MTP2 |        | MTP2 | M2PA |        | M2PA |    
    +------+        +------+------+        +------+    
    | MTP1 |        | MTP1 | SCTP |        | SCTP | 
    |      |        |      +------+        +------+
    |      |        |      | IP   |        | IP   |
    +------+        +------+------+        +------+

         Figure 3:  M2PA in IP Signaling Gateway

    ********  SS7   ***************   IP   ********
    * SEP  *--------*     SG      *--------* MGC  *
    ********        ***************        ********

    +------+                               +------+
    | SCCP |                               | SCCP |
    +------+                               +------+
    | MTP3 |             (NIF)             | MTP3 | 
    +------+        +------+------+        +------+    
    | MTP2 |        | MTP2 | M2UA |        | M2UA |    
    +------+        +------+------+        +------+    
    | MTP1 |        | MTP1 | SCTP |        | SCTP | 
    |      |        |      +------+        +------+
    |      |        |      | IP   |        | IP   |
    +------+        +------+------+        +------+

       NIF   - Nodal Interworking Function

         Figure 4:  M2UA in IP Signaling Gateway

George, et al                                                [Page 13] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

M2PA and M2UA are similar in that:

   a. Both transport MTP3 data messages.

   b. Both present an MTP2 upper interface to MTP3.

Differences between M2PA and M2UA include:

   a. M2PA: IPSP processes MTP3/MTP2 primitives.
      M2UA: MGC transports MTP3/MTP2 primitives between the SG's MTP2
            and the MGC's MTP3 (via the NIF) for processing. 

   b. M2PA: SG-IPSP connection is an SS7 link.
      M2UA: SG-MGC connection is not an SS7 link. It is an 
            extension of MTP to a remote entity.

   c. M2PA: SG is an SS7 node with a point code.
      M2UA: SG is not an SS7 node and has no point code.

   d. M2PA: SG can have upper SS7 layers, e.g., SCCP.
      M2UA: SG does not have upper SS7 layers since it has no MTP3.

   e. M2PA: relies on MTP3 for management procedures.
      M2UA: uses M2UA management procedures.

Potential users of M2PA and M2UA should be aware of these differences when
deciding how to use them for SS7 signaling transport over IP networks.

2.  Protocol Elements

This section describes the format of various messages used in this protocol.

All fields in an M2PA message must be transmitted in the network byte order,
i.e., most significant byte first, unless otherwise stated.

2.1 Common Message Header

The protocol messages for M2PA require a message header structure which
contains a version, message type and message length. The header structure is
shown in Figure 5.

George, et al                                                [Page 14] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |     Spare     | Message Class | Message Type  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Message Length                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 5:  Common Message Header

2.1.1  Version

The version field contains the version of M2PA. The supported versions are:

       Value    Version
       -----    -------
         1      Release 1.0 of M2PA protocol

2.1.2  Spare

The Spare field SHOULD be set to all zeroes (0's) by the sender and ignored
by the receiver. The Spare field SHOULD NOT be used for proprietary
information.

2.1.3  Message Class

The following List contains the valid Message Classes:

         Value    
       (decimal)  Message Class
       ---------  -------------
          11      M2PA Messages 

Other values are invalid for M2PA.

2.1.4  Message Type

The following list contains the message types for the defined messages.

       Value      Message Type
       -----      ------------
         1        User Data
         2        Link Status
         3        Proving Data

Other values are invalid.

George, et al                                                [Page 15] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

2.1.4  Message Length

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

2.2 M2PA Messages

The following section defines the messages and parameter contents.  An M2PA
message consists of a Common Message Header followed by the data appropriate
to the message.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 ...
   |                     Common Message Header                     |
                                 ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 ...
   |                         Message Data                          |
                                 ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.2.1 User Data 

The User Data is the data sent from MTP3. The format for the User Data
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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 ...
   |                            Data                               |
                                 ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Data field contains the following fields of the MTP Message Signal Unit
(MSU):

   - Length Indicator (LI), including the two undefined bits between
     the SIO and LI fields.
   - Service Information Octet (SIO)
   - Signaling Information Field (SIF)

The MTP MSU described in [2] Q.703, section 2.2 Signal Unit Format, and [3]
T1.111.3 section 2.2 Signal Unit Format. 

M2PA does not add padding to the MTP3 message. 

George, et al                                                [Page 16] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

Note that the Data field SHALL NOT contain other components of the MTP MSU
format:

   - Flag
   - Backward Sequence Number (BSN)
   - Backward Indicator Bit (BIB)
   - Forward Sequence Number (FSN)
   - Forward Indicator Bit (FIB)
   - Check bits (CK) 

The Data field SHALL be transmitted in the byte order as defined by MTP3. 

It is not necessary to put the message length in the LI octet as in MTP2.
The LI octet is included because the two spare bits in the LI octet are used
by MTP3 in at least one national version of SS7 to carry MTP3 information.
For example, the Japan TTC standard uses these spare bits as an MTP3 Message
Priority field. See [9], section 14 "Common Characteristics of message
signal unit formats", section 14.2 (A) Priority Indicator (PRI). For
versions of MTP that do not use these two bits, the entire octet is spare.

Therefore in M2PA the format of the LI octet is:

    0               
    0 1 2 3 4 5 6 7 
   +-+-+-+-+-+-+-+-+
   |   spare   |PRI| (followed by SIO, SIF) 
   +-+-+-+-+-+-+-+-+

   PRI - Priority used only in national MTP defined in [9].
         Spare for other MTP versions.

Since the LI octet is not used for a message length, there is no need to
support the expanded LI field in [2], Q.703 Annex A. Therefore the LI field
in M2PA is always one octet.

Note: In the SS7 Recommendations, the format of the messages and fields
within the messages are based on bit transmission order.  In these
recommendations the Least Significant Bit (LSB) of each field is positioned
to the right.  The received SS7 fields are populated octet by octet as
received into the 4-octet word as shown below.

As an example, in the ANSI MTP protocol, the Data field format is shown
below:

George, et al                                                [Page 17] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

   |MSB---------------------------------------------------------LSB|
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   spare   |PRI|      SIO      |   SIF octet   |      ...      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                               :                               \

   /                               :                               /
   \                               :                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      ...      |      ...      |      ...      |   SIF octet   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Within each octet the Least Significant Bit (LSB) per the SS7
Recommendations is to the right (e.g., bit 15 of SIO is the LSB).

2.2.2  Link Status

The MTP2 Link Status message can be sent between M2PA peers to indicate link
status. This message performs a function similar to the the Link Status
Signal Unit in MTP2. Except as modified later in this section, the format
for the Link Status 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            State                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The valid values for State are shown in the following table. 

         Value  
       (decimal)  Description
       ---------  -----------
           1      Alignment
           2      Proving Normal
           3      Proving Emergency
           4      Ready
           5      Processor Outage
           6      Processor Outage Ended
           7      Busy
           8      Busy Ended

2.2.3 Proving Data 

The Proving Data message is used during the proving period. The format for
the message is as follows.

George, et al                                                [Page 18] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 ...
   |                            Data                               |
                                 ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It is recommended that the length of the Data field be similar to the size
of the User Data messages that will be carried on the link.

It is recommended that the Data field contain a number pattern which varies
among the Proving Data messages, and that will allow the SCTP checksum to be
used to verify the accuracy of transmission.

3.  M2PA Link State Control

The M2PA link moves from one state to another in response to various events.
The events that may result in a change of state include:

   - MTP3 primitive requests

   - SCTP notifications

   - Receipt of Status messages from the peer M2PA

   - Expiration of certain timers

Figure 6 illustrates state changes together with the causing events.
Note that some of the error conditions are not shown in the state diagram.

Following is a list of the M2PA Link States and a description of each.

IDLE - State of the link during power-up initialization.

OOS - Out Of Service. Power-up initialization is complete. 

AIP - Alignment In Progress. M2PA is attempting to exchange Alignment
messages with its peer.

PROVING - M2PA is sending Proving Data messages to its peer.

ALIGNED READY - Proving is complete. M2PA is waiting until peer completes
proving.

INS - In Service. Link is ready for traffic.

RETRIEVAL - Link no longer carries traffic. M2PA is waiting for request for
message retrieval from MTP3.

George, et al                                                [Page 19] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

                              +-----------+
                              |   IDLE    |
                              +-----------+
                                    |
                                    | Power On
                                    |
                                    |   +--------------------------+
                                    |   |       (Associate)        |
                                    V   V                          |
                              +-----------+                        |
                      +------>|    OOS    |<--+                    |
                      |       +-----------+   | Link Configured    |
                      |             |   |     | (Associate)        |
                      |             |   +-----+                    |
                      |             |                              |
                      |             | MTP3 Start                   |
                      | MTP3 Stop   |                              |
                      |             V                              |
                      |       +-----------+                        |
                      +<------|    AIP    |----------------------->+
                      |       +-----------+     SCTP Comm Error    |
                      |             |        OR SCTP Comm Lost     |
                      |             |        OR T1 Expiry          |
                      |             |                              |
                      |             | Receive LS Alignment         |
                      |             |      OR LS Proving           |
                      | MTP3 Stop   |                              |
                      |             V                              |
                      |       +-----------+                        |
                      +<------|  PROVING  |----------------------->+
                      |       +-----------+     SCTP Comm Error    |
                      |             |        OR SCTP Comm Lost     |
                      |             |                              |
                      |             | T2 Expiry                    |
                      | MTP3 Stop   |                              |
                      |             V                              |
                      |       +-----------+                        |
                      +<------|  ALIGNED  |                        |
                              |   READY   |----------------------->+
                              +-----------+                        |
                                    |           SCTP Comm Error    |
                                    |        OR SCTP Comm Lost     |
                                    |        OR T3 Expiry          |
                                    |                              |
                                    | Receive LS Proving Complete  |
                                    | OR Receive User Data         |
                                    |                              |
                                    V                              |
                              +-----------+                        |
                              |    INS    |                        |
                              +-----------+                        |
                                    |                              |
                                    |                              |
                                    |                              |

George, et al                                                [Page 20] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

                                    |                              |
                                    |                              |
                                    |    MTP3 Stop                 |
                                    | OR SCTP Comm Error           |
                                    | OR SCTP Comm Lost            |
                                    | OR T6 Expiry                 |
                                    |                              |
                                    V                              |
                              +-----------+                        |
                              | RETRIEVAL |----------------------->+
                              +-----------+    Retrieval Complete
                                            OR MTP3 Start

                Figure 6: M2PA Link State Transition Diagram

Figure 7 illustrates state changes in the M2PA management of the SCTP
association together with the causing events.  Note that some of the error
conditions are not shown in the state diagram.

Following is a list of the M2PA Association States and a description of
each.

IDLE - State of the association during power-up initialization.

ASSOCIATE - M2PA is attempting to establish an SCTP association.

ESTABLISHED - SCTP association is established. 

                             +-----------+
        +------------------->|   IDLE    |
        |                    +-----------+
        |                          |
        | (Issue SCTP              | Associate
        |    Abort)                | (Issue SCTP associate)
        |                          |
        |                          |   +----------------------+
        |                          |   |         (Issue SCTP  |
        |                          V   V          associate)  |
        |      Abort         +-----------+                    |
        +<-------------------| ASSOCIATE |------------------->+
        |                    +-----------+    SCTP Comm Error |
        |                          |                          |
        |                          |                          |
        |                          | SCTP Comm Up             |
        |                          |                          |
        |                          V                          |
        |      Abort         +-------------+                  |
        +<-------------------| ESTABLISHED |----------------->+
                             +-------------+   SCTP Comm Error
                                            OR SCTP Comm Lost

                Figure 7: M2PA Association State Transition Diagram

George, et al                                                [Page 21] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

4.  Procedures

4.1 Procedures to Support MTP2 Features

4.1.1 Signal Unit Format, Delimitation, Acceptance

Messages for transmission across the network must follow the format
described in section 2.

SCTP provides reliable, in-sequence delivery. Therefore the related
functionality of MTP2 is not needed. SCTP does not provide functions related
to Link State Control in MTP2. These functions must be provided by M2PA.

4.1.2 MTP and SCTP Entities

This section describes how M2PA relates MTP and SCTP entities.

To prevent duplicate associations from being established, it must be decided
in advance which endpoint initiates the establishment of the association. In
a pair of endpoints, the endpoint that initiates the establishment of the
association is called the client. The other endpoint is the server. An
endpoint may be a client in its relationship with one endpoint, and a server
in its relationship with another endpoint. The designations of client and
server are needed only to decide which endpoint initiates the establishment
of the association. After that, the endpoints function as peers.

The client initiates the association using the server's IP address and the
M2PA well-known port number as the destination endpoint. If only one
association is to be established between these two IP addresses, then the
client should use its own IP address and the M2PA well-known port number as
the source endpoint.

If it is desirable to create multiple associations (for multiple links)
between the two IP addresses, the client uses a different local port number
for each association. 

The client M2PA should establish the association for a link when the link is
configured for operation by MTP signaling management. 

Whenever the association is terminated, the client M2PA should establish the
association as soon as the termination procedure is complete.

The client M2PA establishes an association by sending the SCTP ASSOCIATE
primitive to SCTP. The client should attempt to establish the association
periodically until it is successful.

Once the association is established and MTP3 has issued its Start Request,
M2PA begins the alignment procedure. The M2PA at either end may initiate the
alignment procedure first. There is no client/server distinction once the
SCTP association is established.

George, et al                                                [Page 22] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

Each combination of client IP address/port and server IP address/port (i.e.,
each association) must be mapped to the same Signaling Link Code (SLC) in
the client and server, so that each endpoint knows which link is being
created at the time the SCTP association is established. However, M2PA does
not do any processing based on the SLC.

Following are examples of the relationships between associations and links.
Note that a link is an SCTP association identified by two endpoints, in this
case a client and server. Each endpoint is identified by an IP address and
port number. Each association is mapped to an SLC. 

Figure 8 shows a case with two IPSPs, each with two IP addresses. Two
associations are the links that connect the two IPSPs. Since these links are
in the same link set, they must have different SLCs.

Table 1 shows the relationships in tabular form. Table 1 is only conceptual.
The actual method for mapping the SCTP associations to the SLCs is
implementation dependent.

                IPSP X                        IPSP Y

            +-------------+               +-------------+
            |             |     SCTP      |             |
            |         IPA | association 1 | IPB         |
            |   port = PW +---------------+ port = PW   |
            |     SLC = a |               | SLC = a     |
            |      Client |               | Server      |
            |             |               |             |
            |             |     SCTP      |             |
            |         IPC | association 2 | IPD         |
            |   port = PW +---------------+ port = PW   |
            |     SLC = b |               | SLC = b     |
            |      Client |               | Server      |
            |             |               |             |
            +-------------+               +-------------+

      IPx    = IP address
      PW     = Well-known port number for M2PA

                Figure 8: Associations and Links - 
                 Two IPSPs with Two IP Addresses Each

George, et al                                                [Page 23] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

     +-------------+---------------------------------------+-----+
     | Association |      Client       |      Server       | SLC |
     |             +------------+------+------------+------+     |
     |             | IP address | Port | IP address | Port |     |
     +=============+============+======+============+======+=====+
     |      1      |    IPA     |  PW  |    IPB     |  PW  |  a  |
     +-------------+------------+------+------------+------+-----+
     |      2      |    IPC     |  PW  |    IPD     |  PW  |  b  |
     +-------------+------------+------+------------+------+-----+

                Table 1: Associations and SLCs - 
                 Two IPSPs with Two IP Addresses Each

Figure 9 and Table 2 show an example with three IPSPs. Note that in this
example, the two links are in different link sets. Therefore, it is possible
that the values a and b may be equal.

George, et al                                                [Page 24] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

                IPSP X                        IPSP Y

            +-------------+               +-------------+
            |             |     SCTP      |             |
            |         IPA | association 1 | IPB         |
            |   port = PW +---------------+ port = PW   |
            |     SLC = a |               | SLC = a     |
            |      Client |               | Server      |
            |             |               |             |
            |             |     SCTP      |             |
            |         IPC | association 2 |             |
            |   port = PW +-------+       |             |
            |     SLC = b |       |       |             |
            |      Client |       |       |             |
            |             |       |       |             |
            +-------------+       |       +-------------+
                                  |
                                  |
                                  |           IPSP Z
                                  |
                                  |       +-------------+
                                  |       |             |
                                  |       | IPD         |
                                  +-------+ port = PW   |
                                          | SLC = b     |
                                          | Server      |
                                          |             |
                                          |             |
                                          |             |
                                          |             |
                                          |             |
                                          |             |
                                          |             |
                                          +-------------+

      IPx    = IP address
      PW     = Well-known port number for M2PA

                Figure 9: Associations and Links - 
                 One IPSP Connected to Two IPSPs

     +-------------+---------------------------------------+-----+
     | Association |      Client       |      Server       | SLC |
     |             +------------+------+------------+------+     |
     |             | IP address | Port | IP address | Port |     |
     +=============+============+======+============+======+=====+
     |      1      |    IPA     |  PW  |    IPB     |  PW  |  a  |
     +-------------+------------+------+------------+------+-----+
     |      2      |    IPC     |  PW  |    IPD     |  PW  |  b  |
     +-------------+------------+------+------------+------+-----+

                Table 2: Associations and SLCs - 
                 One IPSP Connected to Two IPSPs

George, et al                                                [Page 25] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

Figure 10 and Table 3 show two associations between the same endpoints. This
is accomplished by using different port numbers for each association at the
client.

                IPSP X                        IPSP Y

            +-------------+               +-------------+
            |             |     SCTP      |             |
            |         IPA | association 1 | IPB         |
            |   port = P1 +---------------+ port = PW   |
            |     SLC = a |               | SLC = a     |
            |      Client |               | Server      |
            |             |               |             |
            |             |     SCTP      |             |
            |         IPA | association 2 | IPB         |
            |   port = PW +---------------+ port = PW   |
            |     SLC = b |               | SLC = b     |
            |      Client |               | Server      |
            |             |               |             |
            +-------------+               +-------------+

      IPx    = IP address
      P1     = Pre-selected port number for Client
      PW     = Well-known port number for M2PA

                Figure 10: Associations and SLCs -
             Multiple Associations Between Two IP Addresses

     +-------------+---------------------------------------+-----+
     | Association |      Client       |      Server       | SLC |
     |             +------------+------+------------+------+     |
     |             | IP address | Port | IP address | Port |     |
     +=============+============+======+============+======+=====+
     |      1      |    IPA     |  P1  |    IPB     |  PW  |  a  |
     +-------------+------------+------+------------+------+-----+
     |      2      |    IPA     |  PW  |    IPB     |  PW  |  b  |
     +-------------+------------+------+------------+------+-----+

                Table 3: Associations and SLCs -
             Multiple Associations Between Two IP Addresses

The association shall contain two streams in each direction. Stream 0 is
designated for Link Status messages. Stream 1 is designated for User Data
and Proving Data messages.

George, et al                                                [Page 26] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

4.1.3  Link Alignment

The purposes of the alignment procedure are:

1. To provide a handshaking procedure so that both endpoints are
   prepared to send SS7 traffic, and to prevent traffic from being
   sent before the other end is ready.

2. Verify that the SCTP association is suitable for use as an SS7
   link.

3. Optionally, to overcome the SCTP slow start period.

Link alignment takes place after the association is established. If SCTP
fails to establish the association, and M2PA has received a Start Request
from its MTP3, then M2PA shall report to MTP3 that the link is out of
service. 

Once the association is established and M2PA has received a Start Request
from MTP3, M2PA sends the Link Status Alignment message to its peer. If M2PA
has not already received the Link Status Alignment message from its peer,
then M2PA starts timer T1.

(Note that if the remote M2PA has not received a Start Request from its
MTP3, it will not send the Link Status Alignment message to the local M2PA.
Eventually timer T1 in the local M2PA will expire.)

M2PA stops timer T1 when it has received the Link Status Alignment message
from its peer.

If timer T1 expires, then M2PA reports to MTP3 that the link is out of
service. M2PA should leave the association established. M2PA waits for MTP3
to initiate the alignment procedure again.

When M2PA has both sent and received the Link Status Alignment message, it
has completed alignment and moves to the proving state.

M2PA starts the proving period timer T2. During the proving period, M2PA
sends Link Status Proving messages to its peer at an interval defined by the
protocol parameter Status_Interval. M2PA sends either the Proving Normal or
Proving Emergency message, according to the Emergency and Emergency Ceases
commands from MTP3. M2PA uses the value of T2 corresponding to the Normal or
Emergency state. However, if M2PA receives a Link Status Proving Emergency
message from its peer, then M2PA shall use the Emergency value for T2.

Also while T2 is running, M2PA shall send Proving Data messages on the User
Data stream. These messages are sent at a rate equal to the protocol
parameter Proving_Data_Rate.

When the proving period timer T2 expires, M2PA shall determine the
association's performance as described in section 4.1.6 Error

George, et al                                                [Page 27] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

Monitoring. If the association's performance is inadequate, M2PA shall
report to MTP3 that the link is out of service. M2PA should leave the
association established. M2PA waits for MTP3 to initiate the alignment
procedure again.

If the association's performance is satisfactory, M2PA shall start the timer
T3 and send Link Status Ready messages to its peer at interval
Status_Interval. These messages are used to verify that both ends have
completed proving.

M2PA shall stop timer T3 when it receives a Link Status Proving Complete or
User Data message from its peer. If timer T3 expires, then M2PA reports to
MTP3 that the link is out of service. M2PA should leave the association
established. M2PA waits for MTP3 to initiate the alignment procedure again.

Note that if M2PA has already received a Link Status Ready message from its
peer when it finishes checking the association's performance, there is no
need to start timer T3. M2PA can just send Link Status Ready to the peer and
continue along.

When all of the following are true:

   (a) M2PA has received a Start Request from MTP3.

   (b) M2PA's proving period T2 has expired.

   (c) M2PA has sent a Link Status Ready to its peer.

   (d) M2PA has received a Link Status Ready OR User Data
       message from its peer.

then M2PA shall send Link In Service to its MTP3. 

If there is a local processor outage condition, M2PA sends Link Status
Processor Outage to its peer. When the local processor outage condition
ends, then M2PA shall send Link Status Processor Outage Ended to its peer.
M2PA shall attempt to complete the alignment procedure during the local
processor outage condition.

If M2PA receives a Link Status Processor Outage during alignment, and M2PA
had received a Start Request from its MTP3, M2PA shall report Remote
Processor Outage to MTP3.

Recommended values:

T1 Alignment - Range: 1-60 seconds   Default: 10 seconds

T2 Proving -  

   Normal - Range: 1-60 seconds   Default: 10 seconds

   Emergency - Range: 400-600 milliseconds   Default: 500 milliseconds

George, et al                                                [Page 28] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

T3 Ready -  Range: 1-60 seconds   Default: 10 seconds

Status_Interval - implementation dependent.

Proving_Data_Rate - implementation dependent.

4.1.4 Processor Outage

A processor outage occurs when M2PA cannot transfer messages because of a
condition at a higher layer than M2PA.

When M2PA detects a local processor outage, it sends a Link Status message
to its peer with status Processor Outage. M2PA shall also cease sending User
Data messages to SCTP for transmission.

M2PA should periodically send a Link Status Processor Outage message as long
as there is a local processor outage.

The peer M2PA, upon receiving the Link Status Processor Outage message,
shall report Remote Processor Outage to its MTP3. The peer M2PA ceases
sending User Data messages. M2PA stops the Remote Congestion timer T6 if it
is running.

MTP3 sends a Flush Buffers or Continue command to M2PA. When the processor
outage ceases, MTP3 sends a Local Processor Recovered indication to M2PA.
The local M2PA notifies its peer by sending a Link Status message with
status Processor Outage Ended. The peer uses the Remote Processor Recovered
Indication to notify its MTP3 that the remote processor outage condition has
ceased.

4.1.5 Level 2 Flow Control

Notification of receive congestion from SCTP to M2PA is implementation
dependent. This section assumes that M2PA has some means of determining when
SCTP is in receive congestion, such as a receive congestion notification
from SCTP to M2PA. Since SCTP has its own congestion control, the purpose of
the M2PA level 2 flow control is to monitor the association and decide if it
should be aborted.

If M2PA determines that SCTP is in receive congestion for an association,
M2PA shall send a Link Status Busy message to its peer on that association.

M2PA should periodically send a Link Status Busy message as long as its SCTP
is in receive congestion.

When the peer M2PA receives the Link Status Busy message, it shall start the
Remote Congestion timer T6. If timer T6 expires, M2PA shall use the ABORT
primitive to end the association and take the link out of service.

The peer M2PA shall continue transmitting messages to SCTP while its

George, et al                                                [Page 29] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

T6 timer is running, i.e., while the other end is Busy. 

If M2PA determines that SCTP is no longer in receive congestion for the
association, M2PA shall send a Link Status Busy Ended message to its peer on
that association.

When the peer M2PA receives the Link Status Busy Ended message, it shall
stop timer T6.

Recommended value of T6 is 1-6 seconds. 

4.1.6 Error Monitoring

If M2PA loses the SCTP association for a link, M2PA shall report to MTP3
that the link is out of service.

As long as the SCTP association is up, M2PA shall regularly monitor the
association performance. It is recommended that M2PA use the following data
to determine the performance of the association:

   - Smooth Round Trip Time (SRTT). This can be obtained from SCTP by
     invoking the SCTP GETSRTTREPORT primitive.

   - Frequency of SCTP retransmissions. 

   - Frequency of SCTP Gap Acknowledgements received. 

If these values are not acceptable, the link is considered failed and taken
out of service. 

The acceptable values of these data are implementation dependent. 

The interval between successive checks of the performance data should be a
configurable parameter. Its value is implementation dependent.

4.1.7  Transmission and Reception Priorities

In MTP, Link Status messages have priority over User Data messages ([2]
Q.703, section 11.2). To achieve this in M2PA, M2PA shall send Link Status
and User Data messages on separate streams in its SCTP association. All
messages are sent using the ordered delivery option.

M2PA SHOULD give higher priority to reading the Link Status stream over the
User Data stream.

M2PA SHOULD give higher priority to receiving notifications from SCTP over
reading either the Link Status stream or the User Data stream.

Implementation Note: If the SCTP implementation allows streams to have
different priorities for sending messages, then M2PA SHOULD set the Link
Status stream to a higher priority than the User Data stream. See [13] for a
possible extension to SCTP to allow for stream priorities.

George, et al                                                [Page 30] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

4.1.8  M2PA Version Control

A node upgraded to a newer version of M2PA SHOULD support the older versions
used on other nodes with which it is communicating. If that is the case,
then alignment can proceed normally.

In particular, it is recommended that for future modifications to this
protocol:

- Any newer version should be able to process the messages from a
  lower version.

- A newer version of M2PA should refrain from sending messages to an
  older version of M2PA messages that the older version cannot
  process.

- If an older version of M2PA receives a message that it cannot
  process, it should discard the message.

- In cases where different processing is done in two versions for the
  same format of a message, then the newer version should contain
  procedures to recognize this and handle it appropriately.

In case a newer version of M2PA is incompatible with an older version, the
newer version should recognize this and prevent the alignment of the link.
If a Link Status Alignment message with an unsupported version is received
by the newer version, the receiving end's M2PA shall not complete the
alignment procedure.

4.2 Procedures to Support the MTP3/MTP2 Interface

4.2.1  Sending/receiving messages

When MTP3 sends a message for transmission to M2PA, M2PA passes the
corresponding M2PA message to SCTP using the SEND primitive.

M2PA Link Status messages are passed to SCTP using the SEND primitive.

Link Status and User Data messages shall be sent via SCTP on separate
streams.

When M2PA receives a User Data message from SCTP, M2PA passes the message to
MTP3.

If M2PA receives a message from SCTP with an invalid Message Class or
unsupported Message Type in the Common Message Header, M2PA shall discard
the message.

4.2.2  Link activation and restoration

When MTP3 requests that M2PA activate or restore a link by a Start

George, et al                                                [Page 31] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

Request, M2PA shall follow the alignment procedure in section 4.1.3.

4.2.3  Link deactivation

When MTP3 requests that M2PA deactivate a link by a Stop command, M2PA shall
send an ABORT primitive to SCTP.

4.2.4  Flush Buffers, Continue

The Flush Buffers and Continue commands allow M2PA to resume normal
operations (i.e., transmission of messages to SCTP and receiving messages
from SCTP) after a processor outage (local and/or remote) ceases.

If M2PA receives a Flush Buffers command from MTP3, M2PA:

   (a) shall not transmit any messages to SCTP that are currently
       waiting to be transmitted to SCTP. These messages shall be
       discarded.

   (b) shall discard all messages currently waiting to be passed 
       to MTP3.

If M2PA receives either a Flush Buffers or Continue command from MTP3, and
the processor outage condition ceases, M2PA shall resume receiving and
transmitting messages.

4.2.5 MTP3 Signaling Link Congestion

Notification of transmit congestion from SCTP to its upper layer (M2PA) is
implementation dependent. Nevertheless, M2PA should receive notification
from SCTP adequate to allow MTP3 to meet its requirements for signaling link
transmit congestion in [2] Q.704, section 3.8.

M2PA shall use the Congestion Indication primitive to notify its upper layer
MTP3 of changes in the signaling link congestion status and the signaling
link discard status. For national networks with multiple congestion
threshold levels, M2PA shall notify MTP3 of the congestion and discard
status levels.

Note: M2PA does not discard messages because of transmit congestion.
Discarding of messages due to transmit congestion is performed by MTP3.

4.2.6 Changeover

The objective of the changeover is to ensure that signaling traffic carried
by the unavailable signaling link is diverted to the alternative signaling
link(s) as quickly as possible while avoiding message loss, duplication, or
mis-sequencing.  For this purpose, the changeover procedure includes data
retrieval, which is performed before opening the alternative signaling links
to the diverted

George, et al                                                [Page 32] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

traffic.  Data retrieval consists of these steps:

   (1) buffer updating, i.e., identifying all those User Data 
       messages in the retransmission buffer of the unavailable
       signaling link which have not been received by the far end
       SCTP, as well as untransmitted messages, and

   (2) transferring those messages to the transmission buffers of the
       alternate links.

Note that only User Data messages are retrieved and transmitted over the
alternate links. Link Status messages shall not be retrieved and transmitted
over the alternate links. References to stream sequence numbers in this
section refer only to the User Data stream's stream sequence numbers.

In order to support changeover in M2PA, the SCTP Stream Sequence Numbers
must be used in place of the Forward and Backward Sequence Numbers (FSN/BSN)
of SS7.

Stream Sequence Numbers used by SCTP are 16 bits long.  MTP2's Forward and
Backward Sequence Numbers are only seven bits long.  Hence it is necessary
for MTP3 to accommodate the larger SSNs. This is done through the use of the
Extended Changeover Order (XCO) and Extended Changeover Acknowledgement
(XCA) messages instead of the Changeover Order (COO) and Changeover
Acknowledgement (COA) messages. The XCO and XCA messages are specified in
Reference [7] section 9.8.1 and Reference [3] T1.111.4, section 15.4. Only
the XCO and XCA messages from [7] or [3] are required. The SSN is placed in
the XCO/XCA message as explained in [7] and [3].

(Note that the Stream Sequence Numbers are used instead of the Transmission
Sequence Numbers. The Transmission Sequence Numbers are 32 bits long, and
therefore would not fit in the XCO and XCA messages. Furthermore, TSNs do
not number User Data messages consecutively. TSNs also number Link Status
and SCTP-originated messages, which should not be retrieved during the
changeover procedure.)

Also, the following MTP3/MTP2 primitives must use the larger sequence
numbers:

   - BSNT Confirmation

   - Retrieval Request and FSNC

For data retrieval, MTP3 requests the Backward Sequence Number to be
Transmitted (BSNT) from M2PA through the Retrieve BSNT request. Normally,
SCTP receives messages in order, in which case the BSNT is the last message
received by SCTP. However, because of congestion or a failure condition, the
sequence numbers of the acknowledged messages may have gaps.  In particular,
the SCTP SACK (selective acknowledgement message) message can have several
of these gaps. In this case, it is necessary to scan through these gaps and

George, et al                                                [Page 33] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

find the sequence number before the first gap. This is the number considered
as the BSNT and communicated to MTP3. M2PA sends the BSNT value to MTP3 in
the BSNT confirmation. In the same way, the remote end also detects its
BSNT. The MTP3 layers exchange BSNT values through the XCO and XCA messages.
The BSNT received from the other end is called the FSNC. When MTP3 receives
the FSNC from the other end, MTP3 retrieves all the unsent and
unacknowledged messages starting with sequence number (FSNC + 1).  This is
accomplished through a Retrieval Request and FSNC request. After all the
messages are sent from M2PA to MTP3, M2PA sends a Retrieval Complete
indication to MTP3.

As an example of how the BSNT is determined, suppose the following SSNs had
been received by SCTP on the Data Stream when it is time to do the
changeover procedure: 1-10, 13, 14, 16. Then M2PA tells its upper layer that
the last message it received (the BSNT) was 10. SCTP has not delivered 13,
14, and 16 to M2PA because to do so would violate ordered delivery within
the stream. The value of 10 is transmitted to the remote end by MTP3 in the
XCO/XCA message. So the remote end will retransmit 11-16 on an alternate
link.

If there are any messages on the SCTP receive queue, M2PA SHOULD receive
these messages and deliver them to MTP3. Note that SCTP does not deliver
incoming messages after the first gap (if any) in the SSNs, since this would
violate ordered delivery within the stream. In the example above, this would
mean that messages 1-10 SHOULD be received. Otherwise, these unreceived
messages might be lost, since SCTP might have acknowledged them.

Note that the sequence numbers and messages requested by MTP3 may be
obtained by M2PA from SCTP via the Communication Lost primitive [5].
Retrieval of messages is an optional feature in SCTP that is required by
M2PA. To perform data retrieval, it is necessary that SCTP identify the SSNs
of the messages that M2PA retrieves. SCTP must retain the messages for
retrieval by MTP3/M2PA whenever an association is aborted. SCTP must be able
to return messages to M2PA so that M2PA can perform retrieval for MTP3.
There are various ways that this can be implemented, such as:

   (1) SCTP provides a way for M2PA to request retrieval of messages
       for a specified stream and SSN(s).

   (2) SCTP retrieves all messages and identifies the stream and SSN
       of each message. M2PA then must select the appropriate messages
       to pass up to MTP3.

M2PA must be able to respond to the BSNT request from MTP3. There are
various ways of implementing this, such as having SCTP provide the BSNT.

It is helpful for M2PA to have access to the first and last SSN in SCTP's
transmission queue. This information could be used to determine if the FSNC
received from the remote end is a valid value.

George, et al                                                [Page 34] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

If M2PA receives a Retrieve BSNT request from MTP3, M2PA shall respond with
the BSNT confirmation. The BSNT value is the SCTP stream sequence number of
the last message received by SCTP User Data stream before any gaps in the
stream sequence numbers.

(Note that any messages received with a stream sequence number greater than
this BSNT value have been acknowledged by the receiving SCTP, but have not
been passed up to M2PA. These messages are discarded by the receiving SCTP
and are not delivered to the upper layer M2PA. Therefore these messages
should be retransmitted by the far end on the alternate link.)

If M2PA receives a Retrieval Request and FSNC request from MTP3, M2PA shall
retrieve from SCTP in order and deliver to MTP3:

   (a) any transmitted User Data messages beginning with the first
       unacknowledged message with stream sequence number greater
       than FSNC.

   (b) any untransmitted User Data messages in SCTP.

   (c) any untransmitted User Data messages M2PA has not delivered
       to SCTP for transmission.

Then M2PA shall send the Retrieval Complete indication to MTP3.

For emergency changeover, MTP3 retrieves only the unsent messages for
transmission on the alternate link(s). If M2PA receives a Retrieval Request
and FSNC request with no FSNC value, or with an invalid FSNC, then M2PA
shall retrieve from SCTP in order and deliver to MTP3:

   (a) any untransmitted User Data messages in SCTP.

   (b) any untransmitted User Data messages M2PA has not delivered
       to SCTP for transmission.

Then M2PA shall send the Retrieval Complete indication to MTP3.

4.2.6.1 Multiple User Data Streams and Changeover

The changeover procedure makes it problematic for M2PA to have multiple User
Data streams in one direction for a link. Buffer updating would have to be
done for each User Data stream separately to avoid duplication or loss of
messages. But MTP3 provides for only one XCO/XCA message for sending the
last-received SSN. 

M2PA links with multiple User Data streams would be possible if a
multiple-BSNT XCO/XCA message is defined in MTP3, or MTP3 allows multiple
XCO/XCA messages (one for each User Data stream) to be sent during a
changeover. This is beyond the scope of this document.

Another attempt to solve this problem and allow for multiple User Data
streams, without changes to MTP3 messages and procedures, is to

George, et al                                                [Page 35] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

introduce sequence numbering of User Data messages at the M2PA layer. The
M2PA sequence numbers would be used instead of SCTP SSNs in the XCO/XCA
messages. However, since the M2PA messages would be delivered over multiple
streams, there could be a gap in the M2PA sequence numbers at the receiving
end when the changeover procedure begins. There would be a possibility of
losing the messages in the gap, or duplicating messages after the gap.

5.  Examples of M2PA Procedures

In general, messages passed between MTP3 and M2PA are the same as those
passed between MTP3 and MTP2.  M2PA interprets messages from MTP3 and sends
the appropriate message to SCTP. Likewise, messages from SCTP are used to
generate a meaningful message to MTP3.

Note that throughout this section, the primitives between MTP3 and M2PA are
named using the MTP terminology [1][2]. Communications between M2PA and SCTP
are named using SCTP terminology.

5.1  Link Initialization (Alignment)

An example of the message flow to bring an SS7 link in service is shown
below. Alignment is done by both ends of the link. To simplify the diagram,
alignment is shown on one end only. It is assumed in this example that SCTP
has been initialized.

George, et al                                                [Page 36] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

    MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
    ----        ----        ----        ----        ----        ----

     Emergency OR
     Emergency Ceases
     ------------>

     Start
     ------------>

                 Associate
                 ------------>

                             (SCTP Association
                              procedure)

                 Communication Up        Communication Up
                 <------------           ------------>

    MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
    ----        ----        ----        ----        ----        ----

                 Link Status Alignment
                 ------------------------------------>

                 Start timer T1

                                 Link Status Alignment
                 <------------------------------------

                 Stop timer T1
                 Start timer T2

Proving period begins. (Messages from remote end not shown.)

George, et al                                                [Page 37] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

                 Link Status Proving 
                 Proving Data
                 ------------------------------------>
                 ------------------------------------>
                 ------------------------------------>
                 ------------------------------------>
                 ------------------------------------>
                 ------------------------------------>

                 Timer T2 expires

Proving period ends. Check association performance.

                 Get SRTT Report
                 ------------>

Send Link Status Ready until the remote end completes its proving period.

                 Start timer T3

                 Link Status Ready
                 ------------------------------------>
                 ------------------------------------>
                 ------------------------------------>
                 ------------------------------------>

                                     Link Status Ready
                 <------------------------------------

                 Stop timer T3

     In Service                                      In Service
     <------------                                   ------------>

At this point, MTP3 may begin sending data messages.

George, et al                                                [Page 38] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

5.2  Message Transmission and Reception

Messages are transmitted using the Data Request primitive from MTP3 to M2PA.
The diagram shows the case where the Link is In Service. The message is
passed from MTP3 of the source to MTP3 of the destination.

    MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
    ----        ----        ----        ----        ----        ----

     Message for 
     transmission
     ------------>

                 Send
                 (Data Message)
                 ------------>

                             (SCTP sends message)

                                         Receive
                                         ------------>

                                                  Received message
                                                     ------------>

5.3  Link Status Indication

If SCTP sends a Communication Lost primitive to M2PA, M2PA notifies MTP3
that the link is out of service. MTP3 responds in its usual way.

    MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
    ----        ----        ----        ----        ----        ----

                 Communication Lost
                 <------------

     Out of Service
     <------------

George, et al                                                [Page 39] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

5.4  Link Status Message (Processor Outage)

This example shows how M2PA responds to a local processor outage. M2PA sends
a Link Status message to its peer. The peer M2PA notifies MTP3 of the
outage. MTP3 can then follow the processor outage procedures in [2].

    MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
    ----        ----        ----        ----        ----        ----

             M2PA detects 
             Local Processor 
             Outage

                 Link Status
                 Processor Outage
                 ------------>

                             (SCTP sends message)

                                         Receive
                                         ------------>

                                                  Remote Processor
                                                  Outage
                                                     ------------>

                 Link Status
                 Processor Outage
                 Ended
                 ------------>

                             (SCTP sends message)

                                         Receive
                                         ------------>

                                                  Remote Processor
                                                  Outage Ceases
                                                     ------------>

George, et al                                                [Page 40] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

5.5  Level 2 Flow Control

This illustrates the Level 2 Flow Control procedure. In the first diagram,
congestion ceases before timer T6 expires. The second diagram shows the case
where T6 expires.

    MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
    ----        ----        ----        ----        ----        ----

                 Implementation dependent 
                 indication of receive 
                 congestion onset
                 <------------

                 Link Status Busy
                 ------------------------------------>

                                                    Start 
                                                    Timer T6

                 Implementation dependent 
                 indication of receive 
                 congestion abatement
                 <------------

                 Link Status Busy Ended
                 ------------------------------------>

                                                    Stop
                                                    Timer T6

George, et al                                                [Page 41] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

    MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
    ----        ----        ----        ----        ----        ----

                 Implementation dependent 
                 indication of receive 
                 congestion onset
                 <------------

                 Link Status Busy
                 ------------------------------------>

                                                    Start 
                                                    Timer T6
                                                      :
                                                      :
                                                    Timer T6
                                                    Expires

                                                 Abort
                                         <------------

                                         Comm Lost
                                         ------------>

                                                    Out of Service
                                                     ------------>

George, et al                                                [Page 42] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

5.6  MTP3 Signaling Link Congestion

In this example, it is assumed that SCTP notifies M2PA of congestion onset
and abatement. The notification includes the congestion level, if there are
levels of congestion defined.

    MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
    ----        ----        ----        ----        ----        ----

                 Implementation dependent 
                 indication of transmit 
                 congestion onset (level)
                 <------------

     Congestion Indication
     (level)
     <------------

                 Implementation dependent 
                 indication of transmit 
                 congestion abatement (level)
                 <------------

     Congestion Indication
     (level)
     <------------

George, et al                                                [Page 43] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

5.7  Link Deactivation

The MTP3 can request that a SS7-IP link be taken out-of-service. M2PA uses
the Abort message as shown below.

    MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
    ----        ----        ----        ----        ----        ----

     Stop
     ------------>

                 Abort
                 ------------>

                           (SCTP performs its
                           termination procedure)

                 Communication Lost
                 <------------

     Out of Service
     <------------

George, et al                                                [Page 44] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

5.8  Link Changeover

In this example, MTP3 performs a changeover because the link went out of
service. MTP3 selects a different link to retransmit the unacknowledged and
unsent messages.

Note that in this example, the sequence numbers and messages requested by
MTP3 are sent from SCTP to M2PA in the Communication Lost primitive. In
general, the retrieval of sequence numbers and messages is implementation
dependent.

George, et al                                                [Page 45] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

    MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
    ----        ----        ----        ----        ----        ----

                 Communication Lost
                 <------------

     Out of Service
     <------------

     Retrieve BSNT
     ------------>

                 (M2PA locates
                  first gap in
                  received messages)

     BSNT Confirmation
     <------------

     XCO (BSNT) on another link
     ------------------------------------------------------------>

                                                     Retrieve BSNT
                                                     <------------

                                                 BSNT Confirmation
                                                     ------------>

                                                        XCA (BSNT)
     <------------------------------------------------------------

     Retrieval Request
     and FSNC 
     ------------>

                 (M2PA locates
                  first gap in
                  acknowledgements)

     Retrieved Message
     <------------
     
     Retrieved Message
     <------------

     Retrieval Complete
     <------------

     Send messages on another link.

George, et al                                                [Page 46] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

6. Security

M2PA is designed to carry signaling messages for telephony services. As
such, M2PA MUST involve the security needs of several parties: the end users
of the services, the network providers, and the applications involved.
Additional requirements MAY come from local regulation.  While having some
overlapping security needs, any security solution SHOULD fulfill all of the
different parties' needs.

6.1 Threats

There is no quick-fix, one-size-fits-all solution for security. As a
transport protocol, M2PA has the following security objectives:

   - Availability of reliable and timely user data transport.

   - Integrity of user data transport.

   - Confidentiality of user data.

M2PA runs on top of SCTP.  SCTP [5] provides certain transport related
security features, such as:

   - Blind Denial of Service Attacks

   - Flooding

   - Masquerade

   - Improper Monopolization of Services

When M2PA is running in professionally managed corporate or service provider
network, it is reasonable to expect that this network includes an
appropriate security policy framework. The "Site Security Handbook" [11]
SHOULD be consulted for guidance.

When the network in which M2PA runs involves more than one party (e.g., a
non-private network), it MAY NOT be reasonable to expect that all parties
have implemented security in a sufficient manner.  In such a case, it is
recommended that IPSEC be used to ensure confidentiality of user payload.
Consult [12] for more information on configuring IPSEC services.

6.2 Protecting Confidentiality

Particularly for mobile users, the requirement for confidentiality MAY
include the masking of IP addresses and ports. In this case
application-level encryption is not sufficient. IPSEC ESP SHOULD be used
instead.  Regardless of which level performs the encryption, the IPSEC
ISAKMP service SHOULD be used for key management.

George, et al                                                [Page 47] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

7.  IANA Considerations

7.1 SCTP Payload Protocol Identifier

The SCTP (and UDP/TCP) Registered User Port Number Assignment for M2PA is
TBD.

The value assigned by IANA for the Payload Protocol Identifier in the SCTP
Payload Data chunk is 

        M2PA     TBD

The SCTP Payload Protocol Identifier is included in each SCTP Data chunk, to
indicate which protocol the SCTP is carrying. This Payload Protocol
Identifier is not directly used by SCTP but may be used by certain network
entities to identify the type of information being carried in a Data chunk.

The User Adaptation peer may use the Payload Protocol Identifier as a way of
determining additional information about the data being presented to it by
SCTP.

7.2  M2PA Protocol Extensions

This protocol may be extended through IANA in three ways:

   - through definition of additional message classes,
   - through definition of additional message types, and
   - through definition of additional message parameters.

The definition and use of new message classes, types, and parameters is an
integral part of SIGTRAN adaptation layers.  Thus, these extensions are
assigned by IANA through an IETF Consensus action as defined in [14].

The proposed extension must in no way adversely affect the general working
of the protocol.

7.2.1 IETF Defined Message Classes

The documentation for a new message class MUST include the following
information:

   (a) A long and short name for the message class.
   (b) A detailed description of the purpose of the message class.

7.2.2 IETF Defined Message Types

Documentation of the message type MUST contain the following information:

George, et al                                                [Page 48] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

   (a) A long and short name for the new message type.
   (b) A detailed description of the structure of the message.
   (c) A detailed definition and description of the intended use 
       of each field within the message.
   (d) A detailed procedural description of the use of the new
       message type within the operation of the protocol.
   (e) A detailed description of error conditions when receiving this
       message type.

When an implementation receives a message type which it does not support, it
MUST discard the message.

7.2.3 IETF-defined Parameter Extension

Documentation of the message parameter MUST contain the following
information:

   (a) Name of the parameter type.
   (b) Detailed description of the structure of the parameter field.
   (c) Detailed definition of each component of the parameter value.
   (d) Detailed description of the intended use of this parameter type,
       and an indication of whether and under what circumstances
       multiple instances of this parameter type may be found within
       the same message type.

8.  Acknowledgements

The authors would like to thank the following for their valuable comments
and suggestions: Brian Tatum, Jeff Copley, Monique Bernard, Wayne Davis,
Cliff Thomas, Brian Bidulock, Ian Rytina, Al Varney.

George, et al                                                [Page 49] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

9.  References 

[1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling 
    System No. 7 (SS7)'.

[2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 
    (SS7) - Message Transfer Part (MTP)'.

[3] ANSI T1.111-2000, American National Standard for
    Telecommunications - Signaling System Number 7 (SS7) - 
    Message Transfer Part (MTP), 2000.

[4] RFC 2719, Framework Architecture for Signaling Transport, 
    October 1999.

[5] RFC 2960, Stream Control Transmission Protocol,
    October 2000.

[6] SS7 MTP2-User Adaptation Layer, draft-ietf-sigtran-m2ua-09.txt, 
    July 2001.

[7] ITU-T Recommendation Q.2210, 'Message transfer part level 3
    functions and messages using the services of ITU-T 
    Recommendation Q.2140'.

[8] Bradner, S. "Key words for use in RFCs to Indicate Requirement
    Levels", BCP 14, RFC 2119, March 1997.

[9] Telecommunication Technology Committee (TTC) Standard JT-Q704,
    'Message Transfer Part Signaling Network Functions', 
    April 28, 1992.  

[10] ITU-T Recommendation Q.2140, 'B-ISDN ATM Adaptation Layer', 
     February 1995.

[11] RFC 2196, Site Security Handbook, September 1997.

[12] RFC 2401, Security Architecture for the Internet Protocol, 
     November 1998.

[13] SCTP Extensions for Dynamic Reconfiguration of IP Addresses
     and Enforcement of Flow and Message Limits,  
     draft-ietf-tsvwg-addip-sctp-02.txt, June 29, 2001.

[14] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
     Considerations Section in RFCs", BCP 26, RFC 2434, October 
     1998.

[15] RFC 791, Internet Protocol, September 1981.

George, et al                                                [Page 50] 
Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

10.  Authors' Addresses

Tom George                                        Tel: +1-972-519-3168
Alcatel USA, Inc.                    EMail: [email-masked] 1000
Coit Road          
Plano, TX 75075    
USA

Ram Dantu, Ph.D.                                  Tel: +1-469-255-0716 Cisco
Systems Inc.                             EMail: [email-masked] 17919
Waterview Parkway
Dallas, TX 75252
USA

Malleswar Kalla                                   Tel: +1-973-829-5212
Telcordia Technologies             EMail: [email-masked] MCC
1J211R
445 South Street
Morristown, NJ 07960
USA

Hanns Juergen Schwarzbauer                       Tel: +49-89-722-24236
SIEMENS AG                    [email-masked]
Hofmannstr. 51
81359 Munich
Germany

Greg Sidebottom Kanata, Ontario                               EMail:
[email-masked] Canada

Ken Morneault                                     Tel: +1-703-484-3323 Cisco
Systems Inc.                           EMail: [email-masked] 13615
Dulles Technology Drive
Herndon, VA 20171
USA

This Internet Draft expires January 2002.

George, et al                                                [Page 51]
From: Satish K <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Dynamic Registration in M3UA
Date: Sat, 21 Jul 2001 10:56:53 +0530
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-SMTP-HELO: smtp.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]

Brain,
   I just wated to confirm one thing ie, we talk about dynamic Registration
ie Registering new ASPs with New routing key with the AS does it mean we can
only register the ASPs dynamically and AS are registered Stactically?
   What happens when new ASP in New AS tries to register with the SGP? by
new AS i mean this Routing Key is not yet registered in SGP.
Thanks
Satish

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
X-Lotus-FromDomain: HSS
To: "sigtran" <[email-masked]>
Date: Sat, 21 Jul 2001 11:44:17 +0530
Subject: Re: SUA-06: Segmentation/Reassembly/Sequencing
X-SMTP-HELO: hindon.hss.co.in
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [202.54.26.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian ,

Please see some comments below.

Regards,
Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 07/20/2001 10:15:18 PM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]> cc:
[email-masked] (bcc: Sandeep Mahajan/HSS)

Subject:  Re: SUA-06: Segmentation/Reassembly/Sequencing

Vakul,

[email-masked] wrote:                                  (Fri, 20 Jul 2001
18:32:53)
>
>
> John
>
> I am not able to userstand the very basic question,
> why SUA should support segmentation/reassembly
> of messages when it is implicitly being provided by
> the userlying transport layer SCTP. I have followed
> the older mails exchanged on this topic and could
> figure out that it is being supported for two reasons:
>
> 1. SCCP at SG should not wait for all the messages
> for reassembly and subsequent delivery to upper
> layer because it may lead to delays in transport
> of messages to ASP.

True for connection-oriented, false for connection-less.
A connection-less data transfer is a "unit" data transfer.  The NSD does not
support partial-delivery of unitdata and must wait for the last segment.

>
> For e.g. if segmented XUDT messages are received
> at SG, SCCP at SG may reassemble them and give
> whole of the combined message to SUA or it may
> give individual segmented XUDT messages
> which will get reassembled at SUA at ASP.

Bad example.  An SS7 relay point (STP) must fragment LUDT messages into XUDT
when interworking between broadband and narrowband links.  The SS7 part of
the SG might have to support this anyway.

Read the SCCP specs.  For N-UNITDATA, the procedure require that the SCCP
reassemble XUDT before delivery to the user.  This is becase NSD N-UNITDATA
does not support partial delivery (as most UDP sockets don't do partial even
though they are allowed to).

However, for DT1 and DT2, N-DATA does support partial delivery (with a more
flag, much like the use of MSG_EOR in SCTP socket).

Sandeep>> I am copying text from section 3.5.3 of Q.714 where
segmentation/reassembly procedures of connection oriented protocol classes
are listed. It does not state any where that SCCP connection control
procedure can pass data to SCCP-User without completely reassembling it.

"3.5.3  Segmenting and reassembly ( Q.714) During the data transfer phase,
the N-DATA request primitive is used to request transfer of octet-aligned
data (NSDUs) on a signalling connection. NSDUs longer than 255 octets must
be segmented before insertion into the "data" field of a DT message.

The  more-data  indicator  (M-bit)  is  used to reassemble an NSDU that has
been segmented  for  conveyance in multiple DT messages. The M-bit is set to
1 in all DT  messages  except  the  last message whose data field relates to
a particular NSDU. In this way, the SCCP can reassemble the NSDU by
combining the data fields of  all  DT  messages with the M-bit set to 1 with
the following DT message with the M-bit set to 0. The NSDU is then delivered
to the SCCP user using the N-DATA indication.  DT  messages in which the
M-bit is set to 1 do not necessarily have the maximum length.

Segmentation  and  reassembly are not required if the length of the NSDU is
less than or equal to 255 octets."
I wonder what is that I am missing ??

BTW SCTP can only deliver partial data to its user when it detects that it
has run out of buffers while re-assembling a SINGLE message. I can not think
of a SS7 application that will ever be sending such a big message that will
consume all receiver buffer space !!

Your argument holds for connection-oriented.

>
> 2. SCTP at ASP may also deliver partial messages
> to SUA due to which it will have to support reassembly.

Huh?

>
>
> Which primitive SCCP provides for delivery of segmented
> messages to upper layer?

N-DATA supports partial delivery.

Sandeep>> I checked up following sections ..
   ITU-Q.711, Chap 6.1.1.2.3 (Tab 3/Q.711) (I have version dated 07/96)
   ANSI-T1.112 Chap 2.1.1.2.3 (Tab 3/T1.112.1) (I have version dated Jan,
1996) In neither of these sections I could find parameter "More Flag"
present in N-Data Request/Indication) primitive. Was this added in later
versions of the specifications or am I looking at some wrong place ??

N-UNITDATA and N-EXPEDITED-DATA do not.  But ED doesn't fragment anyway.

>
> As partial delivery of SCTP is concerned, any SCTP application
> should support it and this may not be the motivation behind
> supporting segmentation in SUA.
>

--
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: Sat, 21 Jul 2001 01:31:32 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: m2ua-09: comment #5
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

Here is a propsal for addressing comment #5.  I have sent you diffs under
separate cover.  Here is a summary of the proposed text changes:

Add the following definitions:

> Signalling Data Link - An SDL refers to a specific communications
> facility that connects two Signalling Link Terminals.
> 
> Signalling Gateway - An SG is a signalling agent at the edge of the IP
> network.  An SG appears to the SS7 as one or more Signalling Link
> Terminals that are connected to one or more Signalling Data Links in
> the SS7 network.  An SG contains a set of one or more unique
> Signalling Gateway Processes, on which one or more is normally
> actively processing traffic.  Where an SG contains more than one SGP,
> the SG is a logical entity.
> 
> Signalling Gateway Process - A process instance that uses M2UA to
> communicate to and from a Signalling Link Terminal.  It serves as an
> active, backup or load-sharing proces of a Signalling Gateway.

Change:
  
< Depending of course on the reliability of the SG and ASP functional <
elements, this can typically be met by the spreading links in a linkset <
across SGs, the provision of redundant QoS-bounded IP network paths for

to

> Depending of course on the reliability of the SGP and ASP functional
> elements, this can typically be met by the spreading links in a linkset
> across SGPs or SGs, the provision of redundant QoS-bounded IP network
         ^^^^^^^^^^^

Change Figure 2 to look like:

>        **************                              **************
>        *  ********__*______________________________*__********  * Host1
>   SG1  *  * SGP1 *__*________________       _______*__* ASP1 *  *
>        *  ********  *                |     |       *  ********  *
>        *      .     *                |     |       *            *
>        *      .     *                |     |       **************
>        **************                |     |
>                                      |     |
>        **************                |     |
>        *  ********__*______________________|
>   SG2  *  * SGP2 *__*________        |
>        *  ********  *        |       |
>        *      .     *        |       |
>        *      .     *        |       |
>        **************        |       |             **************
>                              |       |_____________*__********  * Host2
>                              |_____________________*__* ASP2 *  *
>               .                                    *  ********  *
>               .            SCTP Associations       *            *
>               .                                    **************
>                                                            .
>                                                            .
>                                                            .

Above the figure in "Section 1.5.1 Mapping", add the paragraph:

> Note that only one SGP SHOULD provide Signalling Link Terminal
> services to an SS7 link.  Therefore, within an SG, an Application
> Server MUST be active for only one SGP at any given point in time.

In Section 4.3.3.4 ASP Active, add the paragraph:

> If the SGP determines that an Interface Identifier in the received ASP
> Active message is invalid, or the AS associated with the Interface
> Identifier is active for a different SGP in the SG, the SGP SHOULD
> respond to the ASP Active message with an Error message indicating
> Invalid Interface Identifier.

Everywhere in the text that refers to the "SG" in the context of messages or
associations to ASPs or maintaining state of ASPs, ASs, or in reference to
Interface Identifiers or Link Keys, change "SG" to "SGP" and "Signalling
Gateway" to "Signalling Gateway Process".  (Too many places to show here.)

--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: Sat, 21 Jul 2001 02:44:44 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUA-06: Segmentation/Reassembly/Sequencing
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.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Sandeep,

Please see comments below...

[email-masked] wrote:                            (Sat, 21 Jul 2001
11:44:17)
> 
> Hi Brian ,
> 
> Please see some comments below.
> 
> Regards,
> Sandeep
> 
> "Brian F. G. Bidulock" <[email-masked]> on 07/20/2001 10:15:18 PM
> 
> Please respond to [email-masked]
> 
> To:   "sigtran" <[email-masked]>
> cc:   [email-masked] (bcc: Sandeep Mahajan/HSS)
> 
> Subject:  Re: SUA-06: Segmentation/Reassembly/Sequencing
> 
> Vakul,
> 
> [email-masked] wrote:                                  (Fri, 20 Jul
2001
> 18:32:53)
> >
> >
> > John
> >
> > I am not able to userstand the very basic question,
> > why SUA should support segmentation/reassembly
> > of messages when it is implicitly being provided by
> > the userlying transport layer SCTP. I have followed
> > the older mails exchanged on this topic and could
> > figure out that it is being supported for two reasons:
> >
> > 1. SCCP at SG should not wait for all the messages
> > for reassembly and subsequent delivery to upper
> > layer because it may lead to delays in transport
> > of messages to ASP.
> 
> True for connection-oriented, false for connection-less.
> A connection-less data transfer is a "unit" data
> transfer.  The NSD does not support partial-delivery
> of unitdata and must wait for the last segment.
> 
> >
> > For e.g. if segmented XUDT messages are received
> > at SG, SCCP at SG may reassemble them and give
> > whole of the combined message to SUA or it may
> > give individual segmented XUDT messages
> > which will get reassembled at SUA at ASP.
> 
> Bad example.  An SS7 relay point (STP) must fragment
> LUDT messages into XUDT when interworking between
> broadband and narrowband links.  The SS7 part of
> the SG might have to support this anyway.
> 
> Read the SCCP specs.  For N-UNITDATA, the procedure
> require that the SCCP reassemble XUDT before delivery
> to the user.  This is becase NSD N-UNITDATA does
> not support partial delivery (as most UDP sockets
> don't do partial even though they are allowed to).
> 
> 
> However, for DT1 and DT2, N-DATA does support
> partial delivery (with a more flag, much like
> the use of MSG_EOR in SCTP socket).
> 
> 
> Sandeep>> I am copying text from section 3.5.3 of Q.714 where
> segmentation/reassembly procedures of connection oriented protocol classes
are
> listed. It does not state any where that SCCP connection control procedure
can
> pass data to SCCP-User without completely reassembling it.
> 
> "3.5.3  Segmenting and reassembly ( Q.714)
> During the data transfer phase, the N-DATA request primitive is used to
request
> transfer of octet-aligned data (NSDUs) on a signalling connection. NSDUs
longer
> than 255 octets must be segmented before insertion into the "data" field
of a DT
> message.
> 
> The  more-data  indicator  (M-bit)  is  used to reassemble an NSDU that
has been
> segmented  for  conveyance in multiple DT messages. The M-bit is set to 1
in all
> DT  messages  except  the  last message whose data field relates to a
particular
> NSDU. In this way, the SCCP can reassemble the NSDU by combining the data
fields
> of  all  DT  messages with the M-bit set to 1 with the following DT
message with
> the M-bit set to 0. The NSDU is then delivered to the SCCP user using the
N-DATA
> indication.  DT  messages in which the M-bit is set to 1 do not
necessarily have
> the maximum length.
> 
> Segmentation  and  reassembly are not required if the length of the NSDU
is less
> than or equal to 255 octets."
> I wonder what is that I am missing ??

Ok.  Now go read the normative reference ITU-Q.713 (ISO/IEC 8348) Section 9,
which describes the partial-delivery interface for the NSD and pay
particular attention to the queue model objects "Octets of NS-user-data" and
"End-of-NSDU".  The NPI implements this as (drum roll) the N_MORE_DATA_FLAG
in the N_DATA_IND primitive.

The necessity of partial delivery of NSDUs in the queueing model is so that
an "Expedited NSDU" object can be, indeed, expedited ahead of "Octets of
NS-user-data".  It would not be expeditious to force an "Expedited NSDU" to
wait for all of the "Octets of NS-user-data" and the "End-of-NSDU" events to
be processed before servicing the ENSDU.

On delivery, most interfaces (e.g. NPI) do not reassemble.  They just copy
the MORE bit right out of the packet into the N_DATA_IND primitive.  Not
only is this efficient, but the connection-oriented procedures provide a
primitive to permit the NS-Provider (SCCP in this case), to "call back"
partial NSDUs: the N-RESET primitive.

This is in full support of the concept of "stream" data, where the
"End-of-NSDU" event may not occur until some arbitrary time in the future.
You can see that this is somewhat TCP-like.  TCP inserts urgent data
mid-stream and most implementations will advance it ahead of waiting data
segments in the write queue.

On the other hand the N-UNITDATA (see Section 19, ISO/IEC 8348) for the
connection-less service has no such partial delivery interface.

The addition to SCCP of secmented NSDU for connection-less service will not
permit a partial-delivery interface to the SCCP-User: because of the "Return
on Error" features of SCCP.  The NSP/NSU interface (N-UNITDATA Request,
N-UNITDATA Indication) provides no mechanism for SCCP to call any partial
pieces back if an error occurs in the reassembly process and an XUDTS needs
be sent.
Because of this NSDUs for connection-less network service have an absolute
maximum and the transfer of larger NSDUs is discouraged because of its
impact on transfer throughput.  You can see that this is somewhat UDP-like.

> 
> BTW SCTP can only deliver partial data to its user when it detects that it
has
> run out of buffers while re-assembling a SINGLE message. I can not think
of a
> SS7 application that will ever be sending such a big message that will
consume
> all receiver buffer space !!

That is simply not true.  There is nothing in RFC 2960 precluding an
implementation from from delivering segmented chunks to the user as they
arrive.

Even the socket interface provide for this with the MSG_EOR (read:
"End-of-NSDU") flag.  In my socket implementation of SCTP, this is exactly
what it does.  A call to readmsg() can return partial data for the stream,
subsequent reads return more data until the last partial read returns
MSG_EOR.  An full or partial out-of-order chunks can also be delivered
intermingled with the sequenced stream data by using the MSG_URGENT flag to
tell the caller of recvmsg() which partial chunk is returned.  MSG_EOR and
MSG_URGENT indicates the last partial read of out-of-order data.

The same approach is taken to sendmsg() where a partial write of data does
not set MSG_EOR, and the final partial write does.
Out of order data can be expedited around normal data by moving to setting
MSG_URGENT and advancing partial writes of out-of-order data around normal
data.  The socket semantic even permits expediting out-of-order data around
normal data when multiple writers (processes) share the same socket
descriptor.  Once a partial MSG_URGENT write begins, the implementation
refuses all subsequent ~MSG_URGENT writes with EAGAIN or blocking until the
final MSG_URGENT|MSG_EOR segment is written.

> 
> 
> Your argument holds for connection-oriented.
> 
> >
> > 2. SCTP at ASP may also deliver partial messages
> > to SUA due to which it will have to support reassembly.
> 
> Huh?
> 
> >
> >
> > Which primitive SCCP provides for delivery of segmented
> > messages to upper layer?
> 
> N-DATA supports partial delivery.
> 
> Sandeep>> I checked up following sections ..
>    ITU-Q.711, Chap 6.1.1.2.3 (Tab 3/Q.711) (I have version dated 07/96)
>    ANSI-T1.112 Chap 2.1.1.2.3 (Tab 3/T1.112.1) (I have version dated Jan,
1996)
> In neither of these sections I could find parameter "More Flag" present in
> N-Data Request/Indication) primitive. Was this added in later versions of
the
> specifications or am I looking at some wrong place ??

The NPI is the most standard implementation of ISO/IEC 8348 that you will
find.  Here are its N-DATA primitives:

(These are from the standard include file /usr/include/sys/npi.h for
SVR4.2.)

|	/*
|	 * Incoming data indication for an NC |	 */
|	typedef struct
|	{
|	    np_ulong   PRIM_type;	   /* always N_DATA_IND */ |
np_ulong   DATA_xfer_flags;	   /* data transfer flags */ |	}
N_data_ind_t;

|	/*
|	 * NPI MORE_DATA_FLAG for segmenting NSDU into more than 1 NIDUs |
*/
|	#define N_MORE_DATA_FLAG    0x00000001L /* Indicates that the next
NIDU is */ |						/* part of this NSDU
*/

> 
> 
> N-UNITDATA and N-EXPEDITED-DATA do not.  But ED doesn't
> fragment anyway.
> 
> >
> > As partial delivery of SCTP is concerned, any SCTP application
> > should support it and this may not be the motivation behind
> > supporting segmentation in SUA.
> >
> 
> --
> 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
[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: Sat, 21 Jul 2001 03:07:06 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Dynamic Registration in M3UA
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Satish,

I think I get what you're driving at, but I don't think that the M3UA makes
any restrictions here.  It is pretty much up to the SGP/ASP to agree.  That
said, here's how I think that it `could' work:

If, as you say, the Routing Key is not already configured in the SGP, and if
the AS is not provisioned in the SGP, then what will the SGP do when it gets
a registration request for this "new" Routing Key?

Well, if the Routing Key is supported by the SGP (i.e, the SGP is capable of
providing traffic and routing on that key) and the key doesn't cause a
problem for the SGP by overlappping with other keys; then, it is possible
for the SGP to store the key and assign a Routing Context to the key to
return in the REG RSP.

If, as you say, the AS has not been provisioned, there exists no AS object
at this time.  The SGP is not really forced to create one yet.

Now, say the ASP performs an ASPAC for the Routing Context which corresponds
to our new Routing Key.  The SGP can create an AS object at this time.  The
only information that the SGP really needs to create the AS object is the
Traffic Mode.

The SGP implementation *could* either simply accept the the Traffic Mode
type presented in the ASPAC, if it is capable of supporting that mode, or,
the SGP/ASP could have agreed `a priori' (that is, they were configured to
agree on what traffic modes and precise distribution algorithms to use for
"new" routing keys of this sort).

So, I don't believe that there is anything stopping an SGP from dynamically
creating an AS based on the Routing Key information and local configuration
information.  I don't think that the SGP needs to be statically configured
for all the AS that it will support, regardless of the registration
procedure.

There is another way to look at this too.  There is nothing stopping the SGP
from statically provisioning *all* Routing Keys and associating Routing
Context and AS information with them at provisioning time.  What the
registration procedure affords in this scenario is being relieved from
having to match Routing Contexts provisioning in the ASP with that of the
SGP.

M3UA really doesn't restrict things here.  Kudos to whoever proposed it!

--Brian

Satish K wrote:                                            (Sat, 21 Jul 2001
10:56:53)
> Brain,
>    I just wated to confirm one thing ie, we talk about dynamic
Registration
> ie Registering new ASPs with New routing key with the AS does it mean we
can
> only register the ASPs dynamically and AS are registered Stactically?
>    What happens when new ASP in New AS tries to register with the SGP? by
> new AS i mean this Routing Key is not yet registered in SGP.
> Thanks
> Satish
> 
> 
> 
> ---
> 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: Satish K <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Dynamic Registration in M3UA
Date: Sat, 21 Jul 2001 14:00:13 +0530
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-SMTP-HELO: smtp.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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brain,
   I agree with you, I just wanted to confirm this as it was not clear in
the Draft in terms of implementation wise of AS side. as the Draft always
talks about dynamic registration of ASPs.
Thanks
Satish

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: 21 July 2001
13:37
To: sigtran
Subject: Re: Dynamic Registration in M3UA

Satish,

I think I get what you're driving at, but I don't think that the M3UA makes
any restrictions here.  It is pretty much up to the SGP/ASP to agree.  That
said, here's how I think that it `could' work:

If, as you say, the Routing Key is not already configured in the SGP, and if
the AS is not provisioned in the SGP, then what will the SGP do when it gets
a registration request for this "new" Routing Key?

Well, if the Routing Key is supported by the SGP (i.e, the SGP is capable of
providing traffic and routing on that key) and the key doesn't cause a
problem for the SGP by overlappping with other keys; then, it is possible
for the SGP to store the key and assign a Routing Context to the key to
return in the REG RSP.

If, as you say, the AS has not been provisioned, there exists no AS object
at this time.  The SGP is not really forced to create one yet.

Now, say the ASP performs an ASPAC for the Routing Context which corresponds
to our new Routing Key.  The SGP can create an AS object at this time.  The
only information that the SGP really needs to create the AS object is the
Traffic Mode.

The SGP implementation *could* either simply accept the the Traffic Mode
type presented in the ASPAC, if it is capable of supporting that mode, or,
the SGP/ASP could have agreed `a priori' (that is, they were configured to
agree on what traffic modes and precise distribution algorithms to use for
"new" routing keys of this sort).

So, I don't believe that there is anything stopping an SGP from dynamically
creating an AS based on the Routing Key information and local configuration
information.  I don't think that the SGP needs to be statically configured
for all the AS that it will support, regardless of the registration
procedure.

There is another way to look at this too.  There is nothing stopping the SGP
from statically provisioning *all* Routing Keys and associating Routing
Context and AS information with them at provisioning time.  What the
registration procedure affords in this scenario is being relieved from
having to match Routing Contexts provisioning in the ASP with that of the
SGP.

M3UA really doesn't restrict things here.  Kudos to whoever proposed it!

--Brian

Satish K wrote:                                            (Sat, 21 Jul 2001
10:56:53)
> Brain,
>    I just wated to confirm one thing ie, we talk about dynamic
Registration
> ie Registering new ASPs with New routing key with the AS does it mean we
can
> only register the ASPs dynamically and AS are registered Stactically?
>    What happens when new ASP in New AS tries to register with the SGP? by
> new AS i mean this Routing Key is not yet registered in SGP.
> Thanks
> Satish
>
>
>
> ---
> 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-EM-Version: 5, 0, 0, 19
X-EM-Registration: #01B0530810E603002D00
Reply-To: [email-masked]
From: "David C. Dickson" <[email-masked]>
To: [email-masked]
Subject: 21st Century Commerce Int'l EXPO 2001 - Training Conference -
Phoenix, 
         AZ
Date: Sat, 21 Jul 2001 05:15:39 -0400
X-SMTP-HELO: smtp-hub.mrf.mail.rcn.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [207.172.4.107]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>

To:    [email-masked]

TRAINING CONFERENCE:

21st Century Commerce International EXPO 2001 E-Business://Building
Integrated Solutions

September 10-13, 2001
Phoenix Civic Plaza
Phoenix, Arizona

Main Program:

Registration: 7:30 a.m., September 11
Program Begins: 8:30 a.m., September 11 Wrap-up: 3:30 p.m., September 13

Continental Breakfast, Refreshments and Lunches included.

About the Conference:

The 21st Century Commerce International EXPO 2001 will be held in Phoenix,
Arizona, September 10-13, 2001. The conference was created in 1987 as a
conference and trade exhibition focused on IT solutions for the government
marketplace and the Department of Defense. The EXPO has expanded to
encompass commercial marketplace best business practices.  EXPO offers you
an opportunity to hear from some of the nations top business leaders who
will discuss and examine all aspects of e-business, from infrastructure to
enterprise architecture, to hardware and software, to security issues. On
the trade show floor, you will see successful e-business in action:  from
government agencies to Fortune 500 companies to small- and medium-size
enterprises making a difference for tomorrow's wired world.

Who should attend:

*  Senior Managers (government and Industry) *  Chief Information Officers
*  Knowledge Officers
*  International Business Leaders
*  eBusiness Architects
*  Information Technology Officers
*  Program Managers
*  Product Data Managers
*  Customer Relations Managers
*  Technology Providers
*  Small-Medium-Large Enterprises
*  Data Conversion Managers and Providers *  Application Service Providers

Among those areas that will be discussed in the tracks are:

*  Defining Requirements for Integrated Solutions *  Strategy Focused
Execution
*  Exploiting Value Chain Management
*  Electronic Enterprises-Broadening Your Space *  Integrated Technologies
*  Electronic Government Enterprise-Governing Beyond Borders

Key Presentations:

*  Mr. Robert D. Johnson, Executive Vice President and COO, Honeywell
International and President and CEO, Honeywell Aerospace *  Ms. Mary J.
Mitchell, Program Executive for Electronic Government Policy, General
Services Administration *  Mr. Jack Garrison, Director of Integrated
Logistics, Lockheed Martin *  LTG Daniel G. Brown, Deputy Commander in
Chief, US Transportation Command *  LTG Charles S. Mahan, Jr., Deputy Chief
of Staff for Logistics, US Army *  RADM Ray Archer, Defense Logistics Agency
*  Ms. Ariane Whittemore, Assistant Deputy Chief of Naval Operations, (Fleet
Readiness and Logistics) *  Dr. Palmer Smith, Director of Government
Solutions, Sabre, Inc.
*  Mr. John F. Phillips, Vice President of Aftermarket Growth, Honeywell *
Mr. Barry Lerner, Vice President of Government Sales, Exostar, LLC *  Mr.
Walt Kozak, PricewaterhouseCoopers *  Mr. Pat Holcomb, CommerceOne
*  Mr. Craig York, Honeywell International

Three ways to register:

*  On-line at www.21cc.org
*  By fax at 703-522-3192
*  By mail:  AFEI, 2111 Wilson Boulevard, Suite 400, Arlington, VA  22201

Register prior to August 31 for Early Bird rates!
AFEI Members: $750
Government Employees: $825
Non-Member: $900

Tutorials:  $100 (September 10)
GSA (MOBIS/LOGWORLD Training): $75 (September 10)

Tutorials Sessions Include:

*  Introduction to Supply Chain Management including practical steps in
planning for implementation *  How to conduct auctions on the Internet.
Reverse auctions - how they work - how DoD is using reverse auctions to save
money *  Strategy Focused Execution including an introduction to Enterprise
Resource Planning (ERP) and Customer Relationship Management (CRM) *  XML
with examples of the practical application of XML within Industry and
Government *  Introduction to Enterprise Application Integration (EAI) *
Configuration Management (The transition to an Industry-wide standard)

We are pleased to announce that GSA will be holding a LOGWORLD/ MOBIS
training session during the EXPO this year.

This year the General Services Administration's (GSA) procurement
innovations will be presented at the 21st Century Commerce International
EXPO 2001 on September 10.  GSA will provide training at EXPO 2001 for
contractors and Federal agencies interested in the Logistics Worldwide
(LOGWORLD) and Management, Organizational and Business Improvement Services
(MOBIS) schedule contracts.

LOGWORLD enables Federal agencies to procure comprehensive logistics
solutions to enhance or replace existing operations and capabilities.
Examples of the type of services provided under this schedule include Supply
and Value Chain Management; Acquisition Logistics; Distribution and
Transportation Logistics; Deployment Logistics; Logistics training services,
support products and new services.  MOBIS provides Federal agencies with a
tool to seek expert advice for improving management and organizational
effectiveness.  Examples of the type of services provided under the MOBIS
schedule are consulting services; facilitation services; survey services;
Alternative Dispute Resolution (ADR) services; A76 study support; project
management services; training services and support products.
www.northwest.gsa.gov/fss/msc

Executive Roundtable:

This years Executive Roundtable (ERT) theme is Returns on Business
Investments in the New Reality. The ERT is a special session for senior
management (CEO, COO, CIO, CTO, Sr. Vice Presidents, Presidents, Executive
Directors) and is offered by invitation only. If you would like to request
an invitation, please contact Michelle Bourke at [email-masked].

Exhibit:

Booth space will be reserved on a first-come, first-served basis. Reserve
your preferred location as soon as possible. The floorplan has been
configured to maximize traffic throughout the display area, and the program
schedule will be designed to encourage attendee participation.  For more
information on available booth space and prices, go to
http://www.21cc.org/01exhibits.htm. We have already sold 50% of our booth
spaces! Sign up soon!

Conference Sponsors:

*  EXOSTAR
*  Sprint E Solutions
*  CSC
*  Phoenix Business Journal
*  Government Computer News
*  National Defense Industrial Association *  National Defense Magazine
*  Thomas Group
*  BidSource
*  The Greater Phoenix Chamber of Commerce

To view sponsorship opportunities, please visit the website at www.21cc.org

Contact:

Michelle Beckner Bourke, EXPO Conference Manager, at (703) 247-9473,
[email-masked];

If you wish to be REMOVED from this list, please REPLY by placing REMOVE in
the subject line.

Thank you

Date: Sat, 21 Jul 2001 04:17:05 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Dynamic Registration in M3UA
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.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Satish,

Well... ASPs are really registering "into" one or more AS.

I thought of another interesting spin on registration.  It is completely
possible to have the ASP, when it comes up with ASPUP have a "default"
routing.  But the ASP could then do a DEREG REQ against that "default"
routing context and REG REQ against a different one.  If things were set up
well, the ASP could use some special value of RC to indicate "my default
AS", say, 0.

What's the value in this?  What it permits is provisioning a platform so
that when it goes down hard, it comes up with a default configuration (BOCs
would love it) which does not require any dynamic registration to get
started.  That is it would come up static.  Once the platform had stablized,
it would be possible for ASPs to DEREG and REG to "move" traffic around here
and there to optimize the platform to current conditions (i.e, available
processors, load balance, time of day/day of week, etc.)

This would work really well for M2UA where the Signalling Data Link
allocations at restart need to be fixed at both ends of the signalling
links, but dynamic allocation of Signalling Data Links can do its job after
that.

--Brian

Satish K wrote:                            (Sat, 21 Jul 2001 14:00:13)
> Brain,
>    I agree with you, I just wanted to confirm this as it was not clear in
> the Draft in terms of implementation wise of AS side. as the Draft always
> talks about dynamic registration of ASPs.
> Thanks
> Satish
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 21 July 2001 13:37
> To: sigtran
> Subject: Re: Dynamic Registration in M3UA
> 
> 
> Satish,
> 
> I think I get what you're driving at, but I don't think that
> the M3UA makes any restrictions here.  It is pretty much up
> to the SGP/ASP to agree.  That said, here's how I think that
> it `could' work:
> 
> If, as you say, the Routing Key is not already configured in
> the SGP, and if the AS is not provisioned in the SGP, then
> what will the SGP do when it gets a registration request for
> this "new" Routing Key?
> 
> Well, if the Routing Key is supported by the SGP (i.e, the
> SGP is capable of providing traffic and routing on that key)
> and the key doesn't cause a problem for the SGP by overlappping
> with other keys; then, it is possible for the SGP to store
> the key and assign a Routing Context to the key to return
> in the REG RSP.
> 
> If, as you say, the AS has not been provisioned, there exists
> no AS object at this time.  The SGP is not really forced to
> create one yet.
> 
> Now, say the ASP performs an ASPAC for the Routing Context
> which corresponds to our new Routing Key.  The SGP can create
> an AS object at this time.  The only information that the SGP
> really needs to create the AS object is the Traffic Mode.
> 
> The SGP implementation *could* either simply accept the the
> Traffic Mode type presented in the ASPAC, if it is capable
> of supporting that mode, or, the SGP/ASP could have agreed
> `a priori' (that is, they were configured to agree on what
> traffic modes and precise distribution algorithms to use for
> "new" routing keys of this sort).
> 
> So, I don't believe that there is anything stopping an SGP
> from dynamically creating an AS based on the Routing Key
> information and local configuration information.  I don't
> think that the SGP needs to be statically configured for all
> the AS that it will support, regardless of the registration
> procedure.
> 
> 
> There is another way to look at this too.  There is nothing
> stopping the SGP from statically provisioning *all* Routing
> Keys and associating Routing Context and AS information with
> them at provisioning time.  What the registration procedure
> affords in this scenario is being relieved from having to
> match Routing Contexts provisioning in the ASP with that
> of the SGP.
> 
> M3UA really doesn't restrict things here.  Kudos to whoever
> proposed it!
> 
> --Brian
> 
> 
> Satish K wrote:                                            (Sat, 21 Jul
2001
> 10:56:53)
> > Brain,
> >    I just wated to confirm one thing ie, we talk about dynamic
> Registration
> > ie Registering new ASPs with New routing key with the AS does it mean we
> can
> > only register the ASPs dynamically and AS are registered Stactically?
> >    What happens when new ASP in New AS tries to register with the SGP?
by
> > new AS i mean this Routing Key is not yet registered in SGP.
> > Thanks
> > Satish
> >
> >
> >
> > ---
> > 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]

-- 
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: Satish K <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Dynamic Registration in M3UA
Date: Sat, 21 Jul 2001 15:52:14 +0530
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-SMTP-HELO: smtp.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]

Brian,
   I feel this sought of dynamic registration(first come up with default key
and later dynamically register with another key) might be required in m3ua.
    This might come in use when the AS has data to be carried to other
destined SGP, which it has not registered now it can register and with the
default key and send data it need not wait for another new reigstraion.
Later if required depending on the Traffic it can continue with the new
Registration key.
Thanks
Satish

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: 21 July 2001
14:47
To: sigtran
Subject: Re: Dynamic Registration in M3UA

Satish,

Well... ASPs are really registering "into" one or more AS.

I thought of another interesting spin on registration.  It is completely
possible to have the ASP, when it comes up with ASPUP have a "default"
routing.  But the ASP could then do a DEREG REQ against that "default"
routing context and REG REQ against a different one.  If things were set up
well, the ASP could use some special value of RC to indicate "my default
AS", say, 0.

What's the value in this?  What it permits is provisioning a platform so
that when it goes down hard, it comes up with a default configuration (BOCs
would love it) which does not require any dynamic registration to get
started.  That is it would come up static.  Once the platform had stablized,
it would be possible for ASPs to DEREG and REG to "move" traffic around here
and there to optimize the platform to current conditions (i.e, available
processors, load balance, time of day/day of week, etc.)

This would work really well for M2UA where the Signalling Data Link
allocations at restart need to be fixed at both ends of the signalling
links, but dynamic allocation of Signalling Data Links can do its job after
that.

--Brian

Satish K wrote:                            (Sat, 21 Jul 2001 14:00:13)
> Brain,
>    I agree with you, I just wanted to confirm this as it was not clear in
> the Draft in terms of implementation wise of AS side. as the Draft always
> talks about dynamic registration of ASPs.
> Thanks
> Satish
>
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 21 July 2001 13:37
> To: sigtran
> Subject: Re: Dynamic Registration in M3UA
>
>
> Satish,
>
> I think I get what you're driving at, but I don't think that
> the M3UA makes any restrictions here.  It is pretty much up
> to the SGP/ASP to agree.  That said, here's how I think that
> it `could' work:
>
> If, as you say, the Routing Key is not already configured in
> the SGP, and if the AS is not provisioned in the SGP, then
> what will the SGP do when it gets a registration request for
> this "new" Routing Key?
>
> Well, if the Routing Key is supported by the SGP (i.e, the
> SGP is capable of providing traffic and routing on that key)
> and the key doesn't cause a problem for the SGP by overlappping
> with other keys; then, it is possible for the SGP to store
> the key and assign a Routing Context to the key to return
> in the REG RSP.
>
> If, as you say, the AS has not been provisioned, there exists
> no AS object at this time.  The SGP is not really forced to
> create one yet.
>
> Now, say the ASP performs an ASPAC for the Routing Context
> which corresponds to our new Routing Key.  The SGP can create
> an AS object at this time.  The only information that the SGP
> really needs to create the AS object is the Traffic Mode.
>
> The SGP implementation *could* either simply accept the the
> Traffic Mode type presented in the ASPAC, if it is capable
> of supporting that mode, or, the SGP/ASP could have agreed
> `a priori' (that is, they were configured to agree on what
> traffic modes and precise distribution algorithms to use for
> "new" routing keys of this sort).
>
> So, I don't believe that there is anything stopping an SGP
> from dynamically creating an AS based on the Routing Key
> information and local configuration information.  I don't
> think that the SGP needs to be statically configured for all
> the AS that it will support, regardless of the registration
> procedure.
>
>
> There is another way to look at this too.  There is nothing
> stopping the SGP from statically provisioning *all* Routing
> Keys and associating Routing Context and AS information with
> them at provisioning time.  What the registration procedure
> affords in this scenario is being relieved from having to
> match Routing Contexts provisioning in the ASP with that
> of the SGP.
>
> M3UA really doesn't restrict things here.  Kudos to whoever
> proposed it!
>
> --Brian
>
>
> Satish K wrote:                                            (Sat, 21 Jul
2001
> 10:56:53)
> > Brain,
> >    I just wated to confirm one thing ie, we talk about dynamic
> Registration
> > ie Registering new ASPs with New routing key with the AS does it mean we
> can
> > only register the ASPs dynamically and AS are registered Stactically?
> >    What happens when new ASP in New AS tries to register with the SGP?
by
> > new AS i mean this Routing Key is not yet registered in SGP.
> > Thanks
> > Satish
> >
> >
> >
> > ---
> > 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]

--
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: Sat, 21 Jul 2001 05:56:29 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: Dynamic Registration in M3UA
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: [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Satish,

It might make a good extension draft.

Satish K wrote:                                            (Sat, 21 Jul 2001
15:52:14)
> Brian,
>    I feel this sought of dynamic registration(first come up with default
key
> and later dynamically register with another key) might be required in
m3ua.
>     This might come in use when the AS has data to be carried to other
> destined SGP, which it has not registered now it can register and with the
> default key and send data it need not wait for another new reigstraion.
> Later if required depending on the Traffic it can continue with the new
> Registration key.
> Thanks
> Satish
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 21 July 2001 14:47
> To: sigtran
> Subject: Re: Dynamic Registration in M3UA
> 
> 
> Satish,
> 
> Well... ASPs are really registering "into" one or more AS.
> 
> I thought of another interesting spin on registration.  It
> is completely possible to have the ASP, when it comes up
> with ASPUP have a "default" routing.  But the ASP could
> then do a DEREG REQ against that "default" routing context
> and REG REQ against a different one.  If things were set
> up well, the ASP could use some special value of RC to
> indicate "my default AS", say, 0.
> 
> What's the value in this?  What it permits is provisioning
> a platform so that when it goes down hard, it comes up with
> a default configuration (BOCs would love it) which does not
> require any dynamic registration to get started.  That is
> it would come up static.  Once the platform had stablized,
> it would be possible for ASPs to DEREG and REG to "move"
> traffic around here and there to optimize the platform to
> current conditions (i.e, available processors, load
> balance, time of day/day of week, etc.)
> 
> This would work really well for M2UA where the Signalling
> Data Link allocations at restart need to be fixed at both
> ends of the signalling links, but dynamic allocation of
> Signalling Data Links can do its job after that.
> 
> --Brian
> 
> Satish K wrote:                            (Sat, 21 Jul 2001 14:00:13)
> > Brain,
> >    I agree with you, I just wanted to confirm this as it was not clear
in
> > the Draft in terms of implementation wise of AS side. as the Draft
always
> > talks about dynamic registration of ASPs.
> > Thanks
> > Satish
> >
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: 21 July 2001 13:37
> > To: sigtran
> > Subject: Re: Dynamic Registration in M3UA
> >
> >
> > Satish,
> >
> > I think I get what you're driving at, but I don't think that
> > the M3UA makes any restrictions here.  It is pretty much up
> > to the SGP/ASP to agree.  That said, here's how I think that
> > it `could' work:
> >
> > If, as you say, the Routing Key is not already configured in
> > the SGP, and if the AS is not provisioned in the SGP, then
> > what will the SGP do when it gets a registration request for
> > this "new" Routing Key?
> >
> > Well, if the Routing Key is supported by the SGP (i.e, the
> > SGP is capable of providing traffic and routing on that key)
> > and the key doesn't cause a problem for the SGP by overlappping
> > with other keys; then, it is possible for the SGP to store
> > the key and assign a Routing Context to the key to return
> > in the REG RSP.
> >
> > If, as you say, the AS has not been provisioned, there exists
> > no AS object at this time.  The SGP is not really forced to
> > create one yet.
> >
> > Now, say the ASP performs an ASPAC for the Routing Context
> > which corresponds to our new Routing Key.  The SGP can create
> > an AS object at this time.  The only information that the SGP
> > really needs to create the AS object is the Traffic Mode.
> >
> > The SGP implementation *could* either simply accept the the
> > Traffic Mode type presented in the ASPAC, if it is capable
> > of supporting that mode, or, the SGP/ASP could have agreed
> > `a priori' (that is, they were configured to agree on what
> > traffic modes and precise distribution algorithms to use for
> > "new" routing keys of this sort).
> >
> > So, I don't believe that there is anything stopping an SGP
> > from dynamically creating an AS based on the Routing Key
> > information and local configuration information.  I don't
> > think that the SGP needs to be statically configured for all
> > the AS that it will support, regardless of the registration
> > procedure.
> >
> >
> > There is another way to look at this too.  There is nothing
> > stopping the SGP from statically provisioning *all* Routing
> > Keys and associating Routing Context and AS information with
> > them at provisioning time.  What the registration procedure
> > affords in this scenario is being relieved from having to
> > match Routing Contexts provisioning in the ASP with that
> > of the SGP.
> >
> > M3UA really doesn't restrict things here.  Kudos to whoever
> > proposed it!
> >
> > --Brian
> >
> >
> > Satish K wrote:                                            (Sat, 21 Jul
> 2001
> > 10:56:53)
> > > Brain,
> > >    I just wated to confirm one thing ie, we talk about dynamic
> > Registration
> > > ie Registering new ASPs with New routing key with the AS does it mean
we
> > can
> > > only register the ASPs dynamically and AS are registered Stactically?
> > >    What happens when new ASP in New AS tries to register with the SGP?
> by
> > > new AS i mean this Routing Key is not yet registered in SGP.
> > > Thanks
> > > Satish
> > >
> > >
> > >
> > > ---
> > > 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]
> 
> --
> 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
[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: Sat, 21 Jul 2001 06:02:27 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Ken Morneault <[email-masked]>
Subject: M2UA-09: Traffic Mode
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 
                      GAA07644
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <