Subject: M3UA Issues List

From: Greg Sidebottom <[email-masked]>
Date: Fri, 17 Aug 2001 15:15:48 -0400

Guys,

I'm sure this incomplete as I still have some unread mail but here is a
first view.  Any missed Issues please send them to me directly so I can
assign Issue Numbers as John and Ken did for the M2UA and SUA.

I think the first three or four issues are the "controversial" ones that we
need to get through as soon as possible.  I think we can get through these
with a little compromise - to me a good compromise is where everyone is
equally unhappy  2;^)

Cheers,

   Greg

M3UA Issues (August 17th):

1) Change Network Appearance semantics/format.           Status: Open

Options: Network Appearance = indication of the SS7 network attached at SG
or also includes the Point Code used (current definition).  Possible
re-format of Network Appearance indicating Network Id and Concerned Point
Code (=OPC?)?

2) Add Routing Context in Data & SSNM messages.         Status: Open

Options: Add RC in Data message (delete NA as then redundant?).   Add
optional Concerned Point Code (=OPC?) and/or Routing Context in SSNM
message. (or use expanded Network Appearance semantics if agreed in Issue
1).  SSNM issue is SGs with multiple attachments (and Point Codes) in the
same Network Appearance.  DATA message issue is ease of processing at ASP.
More details in Brian's e-mail of Aug9

3) SSNM messages semantics at the SGP or SG level.         Status: Open

Options:  SSNM messages apply to each SGP (current) or SG-wide (previous).
Or define an new SG-level message set (extension draft?)

4) Format of Routing Label/SIO in DATA message.                Status: Open

Options: New Protocol Data 3 parameter or just have one choice with all
Routing Label/SIO elements parameterized.

5) Add optional Correlation Id parameter to DATA message Status:
Agreed/Closed.

Needed as part of the agreed Broadcast mode procedures to allow a new ASP to
synchronize with the other ASPs.

6) Delete SSN in Routing Key parameter and TRId from example.   Status:
Agreed/Closed

Using the SSN in the SG RK can break the SCCP subsystem management and/or
SCCP routing going on a layer above the M3UA.

7) Change-over / Change-back support.             Status: Open

Equivalent to changeover procedures in MTP3.  Not agreed in the past.

8) Delete the restriction on Heartbeat to allow any time
Status: Agreed/Closed

Allow Heartbeat in both directions and allow in ASP-Down state.  Some
editorial cleanup required to align ALs.

9) Change Traffic Mode to optional in REG REQ, ASP Active, ASP Active Ack
Status: Agreed?

Needed to allow flexibility for future traffic modes / loadshare policies.
Some semantics outstanding (e.g., when to be included in REG REQ and ASP
Active and what values used..

10) User Part Unavailable support - STP-mode, SEP Mode
Status: Open

Whether to support UPU at SG using STP model.   Also SEP model

11) IPSP cases supported or not.                     Status: Open

Proposal from Maria-Cruz to incorporate IPSP into Examples.    Brian's
comments to remove IPSP entirely.

12) REG Response Message Format                         Status: Open

Add Tags/Lengths to parameters within Registration Result parameter?  Or
clarify that Tags/Lengths not present as all sub-parameters are mandatory
and fixed length. (e-mail from Brian)

13) Lining up of value assignments in UA Common parameters
Status: Open?

Lining up of values for common Reason, Traffic Mode Type and Error Code
parameters (Roland Jesske's e-mail).  John has proposed solution from SUA?

14) Error response to DAUD for "Invalid" destination       Status:
Agreed/Open

Allow an SG to refuse to give the status of a Point Code for security
reasons.  Editor to propose text to list.

15) Open up RK format to allow NA range, multiple DPCs etc       Status:
Agreed/Open

Proposal from Maria-Cruz seems fine but not added yet.

16) Routing Context Definition                             Status: Open

Alignment with SUA?   (see e-mail from Brian)

Others:

- Editors to ensure that parameter Tag assignments are correct/consistent
across all ALs
- Editors to align definitions and management procedure descriptions
wherever they are in common.

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

---

From: [email-masked]
Date: Fri, 17 Aug 2001 15:45:34 -0400

Greg,

Good list! Thanks.

About #4: Format of Routing Label/SIO in DATA message.                Status: 
Open
Options: New Protocol Data 3 parameter or just have one choice with all
Routing Label/SIO elements parameterized.

I would like to add a third option: No routing parameters at all. My 
rationale is that M3UA shouldn't deal with or try to specify contents of 
MTP3 data packets, including the routing label. M3UA just forwards them to 
the MTP3-user at the ASP or to the MTP3 layer at the SG.

We talked about this a lot at the bakeoff, among ourselves and with you. 
You put an initial format in v5, and then tried to correct it in v6. But 
according to Kurt and Brian, both versions were incorrect. My feeling is 
that whatever you put in the draft, there will always be some variant, 
somewhere in the world, for which the specified format will be incorrect. 

Furthermore, the routing label is NOT needed by the receiver of the DATA 
message. The originator of the DATA message simply peeks at the routing 
label of the MTP3 packet to determine the correct ASP/SGP to receive the 
message.

Barry Nagelberg
Software Engineer
RadiSys, Corp.
Signaling Products Design Center
[email-masked]
+1-856-642-9229 x237

---

---

From: Lyndon Ong <[email-masked]>
Date: Fri, 17 Aug 2001 13:05:05 -0700

One correction: the issue of RC in DATA messages
is currently closed (unless a bunch of people who had objected to
this change their minds). 

Thanks,

L. Ong
--

On Fri, 17 Aug 2001 15:15:48   Greg Sidebottom wrote:
>You are currently subscribed to sigtran as: [email-masked]

Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 17 Aug 2001 15:51:22 -0500

Lyndon,

It is not closed.  See NA/RC proposal which meets John's requirements
using RC in data.

--brian

Lyndon Ong wrote:                                          (Fri, 17 Aug 2001 13:05:05)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 17 Aug 2001 16:07:21 -0500

Barry,

Please see questions below...

[email-masked] wrote:                (Fri, 17 Aug 2001 15:45:34)
> the MTP3-user at the ASP or to the MTP3 layer at the SG.

The MTP-TRANSFER primitive includes OPC, DPC, SLS and SIO, and DATA as
arguments of the primitive.  How was the ASP going to populate the
arguments of the MTP-TRANSFER primitive to the MTP-User if it does not
have routing parameters in the DATA message to populate them from?
I don't understand what you are trying to propose here.  Please clarify.

I think that routing parameters are required somewhere in the DATA
message, if nothing else, does not the MTP-User need them?

> somewhere in the world, for which the specified format will be incorrect. 

The MTP-TRANSFER primitive is standarized over all variants of MTP.
It is standardized and has not been changed from some 10 or so years.  How can
it's format be incorrect for some variant?  Please clarify.

I think that the format provided for the MTP-TRANSFER primitive is
guaranteed to be appropriate for all MTP-Users.

> label of the MTP3 packet to determine the correct ASP/SGP to receive the 

With RC in DATA it would not be necessary for the ASP to examine the
RL in the message.  Without it, the ASP must examing the RL contents
to determine the MTP-User to which the message applies.  This is clear
and supported by three requests (not from me, I'm a fourth) to include
RC in DATA so that what you say could be true.

How else, for example, can one distinguish DATA messages which are
destined for the MTP-User 5.255.3/ISUP from the MTP-User 5.255.3/SCCP?

I think that it is clear from the MTP specification that MTP-Users are
identified by SI value and that getting the DATA message to the correct
MTP-User at the ASP requires an examination of at least DPC and SI
values in the Routing Label.  If RC is placed in DATA, however, the ASP
need only examine the RC value to determine MTP-User and need not
examine the Routing Label.  This is what we want.  So, please place RC
in DATA so that it can be accomplished.

--brian

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

---

---

From: Lyndon Ong <[email-masked]>
Date: Thu, 23 Aug 2001 08:56:17 -0700 (PDT)

OK Folks,

Let's revisit the issues list for M3UA - please 
check through the list and put the issue number
in any comments, unless there is already an
existing thread on the issue:
 
> 1) Change Network Appearance semantics/format.      

It seems to me that the majority of views have
suggested that we go back to the definition of
NA from version 6, where it is "network context"
rather than "network entity".  Any comments against 
this?

> 2) Add Routing Context in Data & SSNM messages.     

We've gone around a couple of times on this,
right now we seem to have agreed on adding RC
as an optional parameter, the remaining issue
being whether this is in addition to NA or
replacing NA.

> 3) SSNM messages semantics at the SGP or SG level.  

Haven't seen too much on this.  Comments?

> 4) Format of Routing Label/SIO in DATA message.     

We don't seem to have reached any agreements
on this issue so far, although there has been
some discussion.

> 7) Change-over / Change-back support.            

Have not seen any discussion on this.  Shall we
close the issue?

> 9) Change Traffic Mode to optional in REG REQ, ASP

No discussion on this.  Can we regard this also as
closed?

> 10) User Part Unavailable support - STP-mode, SEP

Have seen (I think) some email against UPU support.
Any further comments?

> 11) IPSP cases supported or not.                    

Seems to be no strong interest in changing
the text.  Further comments?

> Add Tags/Lengths to parameters within Registration
> Result parameter?  

No comments so far.

> 13) Lining up of value assignments in UA Common

Can we go with John L.'s proposal for alignment?
Any comments against this approach?

> 14) Error response to DAUD for "Invalid" destination

Editor to propose text.

> Proposal from Maria-Cruz seems fine but not added

Editor to propose text.

> Alignment with SUA?   (see e-mail from Brian)

Probably needs to be done based on the
current discussion of RC in DATA and SNMM.

> wherever they are in common.

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 24 Aug 2001 09:26:55 -0700

> rather than "network entity".  Any comments against 

[John] Network context/NA is what I need.  The RC usage that Brian wants
doesn't directly work for existing SS7 nodes that are migrating to SS7 over
IP.  They could still use it, but they would have to changing their message
handling function (perhaps borrowed from MTP3) to use RC instead of RL.  I
don't plan on doing this.

> being whether this is in addition to NA or

[John] I thought I had a redefinition of NA/RC that was situation dependent.
I could use it as a NA, some could use it as a RC, and some could use it as
a combination; all dependent on the situation.  I think John L. and maybe
Ken were agreeing with this.

> Haven't seen too much on this.  Comments?

[John] It needs to be brought back to the SG level.  Having a partitioned
end-node would mean that statements are needed to ensure that the SG
informed each ASP (or ASP grouping - by AS?) since they seem to be
functioning independently.  I think the issue of an SG being partitioned is
a separate issue (no longer has a single management presence).  This is
where separate management procedures and messages are needed.

> on this issue so far, although there has been
 
[John] I would rather not fool around with the existing SS7 RL/SIO at this
point.  Changing it will mean that at least one system (maybe two) will have
"waste" processing time to reformat it into the form that the MTP-users or
SS7 network expects.  It would also mean that systems that want to do
routing on RC instead of RL will not be able to just pass the messages off
to the users without processing the routing information.

> Have seen (I think) some email against UPU support.

[John] What is currently in the spec. is wrong.  It is the local M3UA's job
to detect when an MTP-user is unavailable.  In this case, the local M3UA
must generate the DUPU to be returned to the node that sent the message that
encountered the condition.  It is the SG's job to convert the DUPU to a UPU
if it is destined for the SS7 network or pass it on if the destination is
another M3UA node.  The SG must also intercept UPUs from the SS7 network and
convert them into DUPU messages.  In the case of partitioned end-nodes,
these nodes should consider NOT generating the DUPU because it could shut
off traffic for the entire node, not just the affected partition.  It should
be made OPTIONAL for the generation of DUPU at SS7 over IP end-nodes.  It is
the acceptance of UPU/DUPU that is required.

> the text.  Further comments?
 
[John] Strongly support the IPSP and non-backhaul scenarios being contained
in M3UA.

> Any comments against this approach?

[John] Just get it over with quickly and pour cement on it!

> > Proposal from Maria-Cruz seems fine but not added

[John] Haven't seen the proposal but it sound interesting, at least the
multiple PC part.

> current discussion of RC in DATA and SNMM.

[John] This is part of issues 1) and 2) above.

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

---

---

From: Lyndon Ong <[email-masked]>
Date: Fri, 24 Aug 2001 13:24:30 -0700 (PDT)

I believe you and John are actually in agreement on
issue 1 to go back to the "network context"
definition.
If this is acceptable to everyone, we can close
issue 1 as well (given the current direction on
issue 2).

Cheers,

Lyndon
--- "Brian F. G. Bidulock" <[email-masked]>
wrote:
> John,
> 
> John Schantz wrote:                                 
>         (Fri, 24 Aug 2001 09:26:55)
> > 
> > 
> Adding RC to SNMM and DATA makes no requirement on
> an implementation
> to use it instead of RL.  The SG is welcome to use
> RL in the same
> fashion as it does today.  Because RC can be set to
> the same value
> as the current NA, you can use it directly as though
> it were NA in
> your restricted configurations.  Why cannot the NA
> definition go back
> to Lyndon's Network Context?  Perhaps we could even
> rename it as
> Network Context to avoid confusion.
> 
> Per Lyndon's suggestion, we can continue this
> discussion on the other
> thread "Network Appearance".
> 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 24 Aug 2001 15:49:09 -0500

Lyndon,

It is also related to Issue 4, as the NI bits are
already in the RL and may conflict with an NA defined
on the basis of Network Context.  Which network context
does the ASP pass to the MTP user in the MTP-TRANSFER
primitive?  NA or NI bits from RL?  I see a conflict
in "unpacking" Network Context (the NI bits) without
unpacking the rest of the label.

--brian

Lyndon Ong wrote:                                   (Fri, 24 Aug 2001 13:24:30)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: Lyndon Ong <[email-masked]>
Date: Fri, 24 Aug 2001 16:12:02 -0700 (PDT)

I guess I need some further information here -
does NA actually "unpack" the NI bits, or is
NA independent of this?  I thought NA was to
distinguish between networks that reuse the
numbering ranges in the RL, including NI.
Otherwise, wouldn't we just use NI?

Thanks,

Lyndon
wrote:
> > > > [John] Network context/NA is what I need.  The
> RC
> > > usage that Brian wants
> > > > doesn't directly work for existing SS7 nodes
> that
> > > are migrating to SS7 over
> > > > IP.  They could still use it, but they would
> have
> > > to changing their message
> > > > handling function (perhaps borrowed from MTP3)
> to
> > > use RC instead of RL.  I
> You are currently subscribed to sigtran as:
> [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 24 Aug 2001 20:00:41 -0500

Lyndon,

I believe that the argument presented was that NA (as Network Id) was
required to determine the format of the routing label.  For NA as
Network Context to be sufficient to determine the form of the Routing
Label NA would need to include SIO bits.

This is evident from the way that SIO bits are used in national networks
and provided in Section 2.2.1 of Q.704 an provided for in closed
national networks in Section 14.2.2 of Q.704.

NI bits and even the spare bits in the sub-service field of the SIO can
be used to provide 16 separate numbering spaces and Routing Label
formats.  For NA to uniquely identify a point code numbering space, it
would have to be unique for different sub-service field values in
European networks or other networks sufferring from point-code numbering
space exhaustion.

It is also clear from the Q.704 clause 14 that the form of the Routing
Label (and thus point code numbering space) can be different for
different SIO values.  This was (and maybe still is) true in European
networks which use TUP-N (national point code numbering) and TUP-E
(international point code number).

Those who would say that a Network Context determines either point code
numbering space or routing label format are probably restricting their
view to the North American scenario (where exceptions only rarely
occur).  Nevertheless, ASNI also supports the same definitions as found
in Q.704, and within a private SS7 network (e.g., wireless) there is
nothing stopping the use of all sub-service field bits and SI (i.e, the
entire SIO) for distinguishing both point code numbering spaces and
routing label formats in a network specific manner.

Rather than just unloading point code numbering space and routing lable
format into the NA and leaving the NI bits and SI bits in the RL, they
should be unpacked to avoid the case where there is a conflict.

There is no question that something in addition is required to the SIO
fields to distinguish between multiple networks where the SG has
attachment and where the SIO policy is different.  If Network Appearance
is just restricted to identifying a unique SIO coding policy then there
would be no conflict.  This would mean that this definition of NA means
that the NA parameter would only be required in DATA or SNMM if the
RK/RC/AS was defined as spanning multiple SIO coding policies.  It is
not possible to define an RK/RC/AS in this fashion, so NA would never be
required in DATA or SNMM.  That is, the RC in DATA and SNMM would always
be sufficient to determine the SIO policy in effect and the SIO bits
themselves would determine the form of the routing label and the
numbering space for point codes.  (This is why SIO is passed as an
argument to the MTP-TRANSFER primitive.)

Having NA only in REG REQ or static allocation of RCs (the only place
where it is needed, and first associated with a Routing Context) means
that its definition could be based on point code numbering space only.

Going back to Issue 4, because NA is never required in DATA, and because
SIO is passed as an argument in the MTP-TRANSFER primitive, there will
be no need for the ASP M3UA to distinguish the form of the RL *iff* it
is unpacked in the DATA message.  If it is packed, the ASP M3UA must be
provisioned with the the SIO policy for each Routing Context and the
forms of the Routing Label for each SIO value for it to determine how to
unpack the routing label before delivering the unpacked fields as
agruments to the MTP-TRANSFER primitive to the MTP-User.

Because the SG must know the SIO policy and the form of the routing
label to determine where the message is going and to which AS (RC) the
message needs to be routed, it is fully able at that point in time to
place these values into separate parameters in the DATA message which
the ASP M3UA can essentially just copy to the MTP-TRANSFER primitive
arguments without ever having to know the form of the label.  Any
implementation can do this.

Because conflicts in static provisioning information at SG and ASP
concerning SIO policies cannot occur in this case, unpacking the RL in
DATA both boosts interoperability and removes the final variant specific
information from the M3UA at the ASP. (Distinction between TTC and other
variants is no longer required.)

This approach can even accomodate (without modification at the ASP),
swapping IPv4 or IPv6 addresses or hostnames or URLs for OPC and DPC
permitting enhanced M3UA-User definition in extension draft down the
road without major modifications to the core M3UA protocol.  This is the
approach taken by SUA in rationalizing the GT of SCCP into an unpacked
form.  It is a superior approach from the view of interoperability,
extensibility, and efficient implementation.

SUA has none of these issues.  SUA places RC in all SNMM and data
where not implicit, NA only appeares in REG REQ (in Routing Key), in
REG REQ NA is defined as "point code numbering space", and the GT and
MTP RL information (DPC) is unpacked into a variant-neutral set of
parameters.

To summarize: M3UA must place RC in all SNMM and DATA where it is
not implicit, remove NA from all messages except REG REQ (in Routing
Key), in REG REQ NA is defined as "point code numbering space", and
unpack the routing label for a single DATA format and Payload.  Then
issues 1, 2 and 4 are resolved.  If one of these things is not done,
issues 1, 2 and 4 will all resurface.

--brian

Lyndon Ong wrote: (Fri, 24 Aug 2001 16:12:02)
>
> I guess I need some further information here - does NA
> actually "unpack" the NI bits, or is NA independent of this?
> I thought NA was to distinguish between networks that reuse
> the numbering ranges in the RL, including NI.  Otherwise,
> wouldn't we just use NI?
> 
> Thanks,
> 
> Lyndon

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Mon, 27 Aug 2001 07:23:17 -0700

In my view, NA != NI.  NI is a fairly useless parameter for what is needed
and many networks have different interpretations/uses for it.  It could be
set to "national" for all networks and only the messages crossing a network
boundary get marked as "international".  Some ITU SS7 networks set it to
"international" since they are using the ITU, i.e., they don't view their
national network as "national".  Lets keep NI a network specific entity, NA
must be used for network appearance/context/connect.

John

> -----Original Message-----
> From: Lyndon Ong [mailto:[email-masked]]
> Sent: Friday, August 24, 2001 6:12 PM
> To: sigtran
> Subject: Re: M3UA Issues List
> 
> 
> > [email-masked]

---

---

From: Lyndon Ong <[email-masked]>
Date: Mon, 27 Aug 2001 22:52:23 -0700

My last email doesn't seem to have gotten through (BAD mail server! BAD 
mail server!)
so resending:

John and Brian, thanks for the clarifying messages on the NA,
it seems to me pretty clear that it does not duplicate the contents
of the NI field but is outside of the Routing Label entirely...

We're pretty close to agreement I think on the first 4 issues:

1. NA to revert to the earlier definition of "network context"

2. RC to be added as an optional parameter to DATA and SNMM messages
(still some question as to whether an NA parameter would be included as
well.  I think if it is included, it would be for cases where the RC is not 
used
at the ASP, i.e., ASP processes the full routing label)

3. SNMM procedures to be at the SG level
(proposed extension of the ASPIA Ack to allow an SGP to withdraw support
for a routing context to allow finer granularity control)

4. Addition of payload format 3 with unpacked routing label contents

What do people say?  Can we agree in principle on these as
approaches and move closer to completing the document?

Thanks,

L. Ong

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Aug 2001 02:28:18 -0500

Lyndon,

Please see questions and comments below...

Lyndon Ong wrote: (Mon, 27 Aug 2001 22:52:23)
> John and Brian, thanks for the clarifying messages on the NA, it
> seems to me pretty clear that it does not duplicate the contents

I don't know how you could have possibly arrived at this
misconception, but, with no need for NA in DATA (RC is sufficient)
the matter is moot as even these misconceptions can be handled.

> 1. NA to revert to the earlier definition of "network context"

This proposal depends on your definition of "network context".  I
think that pointcode numbering space is clear, even network id (as
international or national network) might be clear.  However, what is
your definition of "network context"?  Could you please define
"network context"?  When and in what messages would NA be used under
this new definition?  Could you please clarify this approach?

> 2. RC to be added as an optional parameter to DATA and SNMM
> messages (still some question as to whether an NA parameter would
> be included as well.  I think if it is included, it would be for
> cases where the RC is not used at the ASP, i.e., ASP processes the
> full routing label)

This proposal is not the proposal being discussed or considered.
The proposal at hand is "replace NA with RC in SNMM and DATA".  It
is very unclear in your proposal when RC would be included in the
message or not, and when NA would be included in the message or not.
Could you please clarify?  In your proposal: Under what conditions
is RC required in DATA and SNMM?  Would RC be included in DATA and
SNMM where not implicit to the association in support of ASPTM
procedures?  If not, what procedures would be used in place of the
ASPTM procedures for ASP Active and ASP Inactive which require the
identification of traffic flows by RC for all DATA and SNMM
messages?  Under what conditions is NA required in DATA and SNMM?
Under what conditions is NA not required in DATA and SNMM?  When is
NA included in relation to when RC is included?  Will the ASP be
permitted to ignore one or the other?  What happens if both are
present in the message?  What does the ASP do (i.e what error
procedures are performed) if both are present and they conflict?
Could you please clarify this approach?

> 3. SNMM procedures to be at the SG level (proposed extension of
> the ASPIA Ack to allow an SGP to withdraw support for a routing
> context to allow finer granularity control)

Is this the same as the proposal has already been made on the "SGP
graceful shutdown" thread?  If so, The full proposal is provided
there for comment.

> 4. Addition of payload format 3 with unpacked routing label

This proposal has been discussed on the "DATA Payload" thread and
was left with a proposal by Kurt to replace the Payloads 1 and 2
with Payload 3.  The use of Data Payload in Kurts proposal is clear.
Is your proposal to add Payload 3 as optional along with Payload 1
and 2?  If so, could you please clarify as to when an SGP will use
which payload format?  Which payload formats can an ASP expect?
Does an ASP have to generate and accept all formats?  Does an SGP?
How does the ASP or SGP know when to generate which format?  Is
static provisioning required at both the SGP and the ASP to
determine which format to use?  What error procedures does an ASP or
SGP follow and how do they respond to those error procedures if
either is presented with an unsupported format?  Could you please
clarify this approach?

> approaches and move closer to completing the document?

Because these were not the approaches discussed or proposed, I think
that you need to clarify just what you mean by them before they can
even be commented on.  Please clarify these approaches.

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

---

---

From: [email-masked]
Date: Tue, 28 Aug 2001 10:37:20 -0400

Brian,

The ASP doesn't have to "populate the arguments of the MTP-TRANSFER primitive to the MTP-User". They were already populated by the MTP3 layer at the SG. The M3UA 
layer, together with the SCTP layer, is simply providing transport across 
the IP network to the already-composed MTP-TRANSFER primitive.

Barry Nagelberg
Software Engineer
RadiSys, Corp.

"Brian F. G. Bidulock" <[email-masked]>
08/17/01 05:07 PM
Please respond to sigtran

        To:     "sigtran" <[email-masked]>
        cc: 
        Subject:        Re: M3UA Issues List

Barry,

[email-masked] wrote:                (Fri, 17 Aug 2001 
15:45:34)

The MTP-TRANSFER primitive is standarized over all variants of MTP.
It is standardized and has not been changed from some 10 or so years.  How 
can
it's format be incorrect for some variant?  Please clarify.

--brian

---

---

From: "Schantz, John" <[email-masked]>
Date: Tue, 28 Aug 2001 08:07:13 -0700

Barry,
	The last I knew, M3UA does NOT transport primitives across the IP
network.  It transports SS7 messages in the DATA parameter of the M3UA
messages.

John

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, August 28, 2001 9:37 AM
> To: sigtran
> The ASP doesn't have to "populate the arguments of the 
> MTP-TRANSFER primitive to the MTP-User". They were already 
> populated by the MTP3 layer at the SG. The M3UA 
> > MTP3 data packets, including the routing label. M3UA just 
> forwards them 
> to 

---

---

From: "Schantz, John" <[email-masked]>
Date: Tue, 28 Aug 2001 09:29:37 -0700

Comments below

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, August 28, 2001 2:28 AM
> To: sigtran

Actually I am surprised that you have the misconception that NA is even
remotely related to NI.  If the NI had been sufficient, then the French
would not have introduced the SAP concept in the MTP and SCCP.  They needed
to be able to distinguish between multiple ITU networks, all saying NI is
"National".  Hence, the SAP concept (a locally supported concept at the SP)
is NA (supported between a set of ASs and SGs).
 
> this new definition?  Could you please clarify this approach?

I think you mean old definition.  When it is used is when the nodes (ASs and
SGs) are communicating with multiple networks.  The need is to maintain
separate PC sets for management and communication.

> Could you please clarify this approach?

NO, the proposal for "replace NA with RC in SNMM and DATA" was DEAD unless
RC could be made defined based on the need of the situation.  The proposal
that I think Ken supported was to allow NA and RC as option parameters.
Either or both would be used as needed and as agreed to between the nodes
involved (note network operator would have the final say here).

> graceful shutdown" thread?  If so, The full proposal is provided

I don't know what you are talking about.  This thread hasn't been active for
over a month.  Even "Al" agreed with my view that SNMM had to be at an node
(SG/AS) level and that if you needed finer control than that, you needed new
procedures and messages.

> either is presented with an unsupported format?  Could you please

I think we only need DATA 1 and 2.  If you have to have DATA 3 then you will
have to get agreement between the nodes for its use (network issue).  Its
very clear when DATA 1 and DATA 2 are used.

---

---

From: Lyndon Ong <[email-masked]>
Date: Tue, 28 Aug 2001 09:47:35 -0700 (PDT)

Well, this is what trial balloons are for, 
although I would appreciate if you refrained
from shooting at it with a bazooka.

> the matter is moot as even these misconceptions can

Fine, whatever.  I don't believe it duplicates NI, but
it's not a major point.

> This proposal depends on your definition of "network
> context".  

I was thinking more specifically of the definition 
from M3UA version 6, but if people have a preference
please say so.  

Where NA is used relates to the next issue.
 
> > messages 

> The proposal at hand is "replace NA with RC in SNMM
> and DATA".  

The specific wording in the issues list is:
"Add RC in Data message (delete NA as then
redundant?)."    

I believe that we have agreement on adding RC
but not agreement on deleting NA.  I have seen
at least one email on the list supporting keeping
NA in addition to RC, but certainly would be
interested in hearing more views on this.

> graceful shutdown" thread?  If so, The full proposal

A reference (message date?) would
be helpful.

> > 4. Addition of payload format 3 with unpacked
> routing label
> > contents
> 
blah blah blah

Fair questions.  How about if we try to address the
questions in some order, though:

-- is there any disagreement with adding a protocol
data format with unpacked contents?

-- if so, should this replace all other data formats
or should this be in addition to existing formats?

-- if in addition, do procedures or error codes need
to be added?

Comments from the group are solicited.

Cheers,

L. Ong

---

---

From: Kurt Kite <[email-masked]>
Date: Tue, 28 Aug 2001 12:13:16 -0500

Lyndon Ong wrote:

> [snip]

Here are my comments from the original thread:

I don't think that we should add another protocol data format. We
should agree on which one is better and use that one.

The second format was added to support Japanese MTP. Brian's proposal
is just different, i.e., it does not add any functionality to the protocol.
If Brian's proposal is added to the protocol I think that implementations
will support one or the other.

I think Brian's proposal has advantages over the current scheme, so I
would opt for that one.

Regards,
Kurt

> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Aug 2001 14:59:52 -0500

Barry,

The ASP needs to take it out of RL (peer PDU) form and place it
into primitive (arguments of MTP-TRANSFER) form.

--brian

[email-masked] wrote:                (Tue, 28 Aug 2001 10:37:20)
> Brian,
> 
> The ASP doesn't have to "populate the arguments of the MTP-TRANSFER
> primitive to the MTP-User". They were already populated by the MTP3 layer at
> the SG. The M3UA layer, together with the SCTP layer, is simply providing
> transport across the IP network to the already-composed MTP-TRANSFER
> primitive.
> 
> Barry Nagelberg
> Software Engineer
> RadiSys, Corp.

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Aug 2001 15:10:35 -0500

John,

John Schantz wrote: (Tue, 28 Aug 2001 09:29:37)

[snip]
> separate PC sets for management and communication.

Please define "network context".  What is the "old definition"?

> involved (note network operator would have the final say here).

Please answer the above questions for this proposal other than "replace
NA with RC".  When would RC be included, when would NA be included,
and when would either not be required, and what does one do if they
are allowed to conflict?

> (SG/AS) level and that if you needed finer control than that, you needed new

The proposal is for finer control other than SNMM.  It was never agreed
to let SNMM go back to SG level without some additional finer control.

> very clear when DATA 1 and DATA 2 are used.

DATA 3 replacing DATA 1 and 2 altogether would be even clearer on when
to use it.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Aug 2001 15:24:47 -0500

Lyndon,

Lyndon Ong wrote:                                          (Tue, 28 Aug 2001 09:47:35)
> > misconception, but, with no need for NA in DATA (RC is
> > sufficient) the matter is moot as even these misconceptions
> > can be handled.
> 
> Fine, whatever.  I don't believe it duplicates NI, but it's
> not a major point.
> 

Is the proposal that you are asking for comment on
to revert to the version 6 definition?

> The specific wording in the issues list is: "Add RC in Data
> message (delete NA as then redundant?)."    

The specific proposal that you asked for and was provided
by Gery was "replace NA with RC in SNMM and DATA".

> 
> I believe that we have agreement on adding RC but not
> agreement on deleting NA.  I have seen at least one email on
> the list supporting keeping NA in addition to RC, but
> certainly would be interested in hearing more views on this.

Do we have agreement that RC is to be included in SNMM and
DATA when not implicit?  If so, when would NA be included?
If it is included with RC, what does the ASP or SGP do
in the case of a conflict between NA and RC?  Because RC
is sufficient can an implementation ignore NA and not
provide it in any messages?  Please clarify what is being
proposed here in keeping NA.

> > Is this the same as the proposal has already been made on
> > the "SGP graceful shutdown" thread?  If so, The full
> > proposal is provided there for comment.
> 
> A reference (message date?) would be helpful.

 Date:  Wed, 22 Aug 2001 20:03:59 -0500
 Subject: Re: [M3UA / SUA] Gracefull shutdown of SGP

blah blah blah

This is already being discussed on another thread.

--brian

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

---

---

From: Ken Morneault <[email-masked]>
Date: Tue, 28 Aug 2001 20:55:00 -0400

Pls see below.

Ken

At 03:24 PM 8/28/01 -0500, you wrote:

<snip>

>proposed here in keeping NA.

NA would always be included, RC would be optional.  If
RC and NA were both in the message, the ASP or SGP would
use RC if RC was configured.  There would be no conflict
between RC and NA.  Because RC is sufficient, an implementation
can ignore NA/Routing Label if desired, but should put them in
the DATA message for those ASPs that do not configure 
an RC value. 

>You are currently subscribed to sigtran as: [email-masked]

---

---

From: Lyndon Ong <[email-masked]>
Date: Tue, 28 Aug 2001 17:37:54 -0700

Brian,

>to revert to the version 6 definition?

Yes, exactly.  What are your comments?

>proposed here in keeping NA.

I believe we have agreement on inclusion of RC as an optional
parameter in DATA and SNMM, when this is required by the ASP.  I do not yet see agreement on deleting RC, but your request is reasonable -folks requesting to keep NA should define when and how they would see it being used.

> Subject: Re: [M3UA / SUA] Gracefull shutdown of SGP

Thank you.

>> questions in some order, though:

Gotcha ;o)

I know this has been discussed on another thread, and initially
I suggested continuing those threads.  However, the threads seem to be linked together (e.g., NA definition and unpacked format).  

Since your preference seems to be the wholeistic approach
rather than step by step, let's consider only two options:
-- Protocol Data 1 and 2
-- Protocol Data 3 (unpacked)

So far, support for both options, unfortunately.

Cheers,

L. Ong

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Aug 2001 21:57:41 -0500

Lyndon,

Lyndon Ong wrote:                                          (Tue, 28 Aug 2001 17:37:54)
> Yes, exactly.  What are your comments?

I'm trying to dig out the version 6 definition.  Is the version 6
draft still available on the IETF server?

> parameter in DATA and SNMM, when this is required by the ASP.  I
> do not yet see agreement on deleting RC, but your request is
> reasonable -folks requesting to keep NA should define when and how
> they would see it being used.

That would certainly help.

> I know this has been discussed on another thread, and initially I
> suggested continuing those threads.  However, the threads seem to
> be linked together (e.g., NA definition and unpacked format).  
> 

Huh?  Who supported all three together?  I saw people saying keep
Data 3 out of there and people saying use only Data 3 but I didn't
see anyone supporting Data 1, 2 and 3 together.  Could you reference
the messages where you see this support for both options?

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Aug 2001 22:14:53 -0500

Ken,

Ken Morneault wrote: (Tue, 28 Aug 2001 20:55:00)
[snip]
> NA would always be included,

That is far from the current situation.  NA is only currently
required in DATA or SNMM where it is not implicit.  Are you
proposing that it become a mandatory parameter?

> RC would be optional.

The proposal for RC is that it is optional, but must be
included where not implicit.  It this what you mean by
optional?

> If RC and NA were both in the message, the ASP or SGP would
> use RC if RC was configured.

When are they both in the message?

> There would be no conflict between RC and NA.

If they are both in the message, because RC implies NA
there can be a conflict.  For example, what happens if the
NA value in the message does not correspond to the NA value
which was provided in the REG REQ to obtain the RC which is
also included?  What happens when an NA does not correspond
to the value which is provisioned against the AS indicate by
the RC?

> Because RC is sufficient, an implementation can ignore
> NA/Routing Label if desired, but should put them in the
> DATA message for those ASPs that do not configure an RC
> value. 

This sounds strange to me.  NA should only be required in the
messages when it is not implicit.  Where it is not implicit
to the association, there must be at least one RC per NA value
(because there are multiple AS on the association).  The ASP
needs to provision these values in support of placing them in
ASPAC or ASPIA.

In what situations is an ASP permitted to not configure an RC
value?

It appears to me that the draft states that RC must be configured
and agreed upon between SGP and ASP whenever it needs to be placed
in ASPTM messages.  Where RC is not required in ASPTM messages it
is implicit to an association.  So it appears that the only case
where the ASP is not required to configure an RC value is when it
is implicit to the association.  In this case NA is also implicit
to the kssociation.  Aren't you saying that NA is needs only be
placed in DATA message when it is not required (i.e, when NA is
implicit to the association)?

Also, didn't you say above that NA would be mandatory?

Please clarify.

--brian

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

---

---

From: Lyndon Ong <[email-masked]>
Date: Tue, 28 Aug 2001 21:18:23 -0700

Brian,

>draft still available on the IETF server?

Sorry, my fault.  I keep the old versions on my machine, should not expect
everyone to...  The definition can be found in M3UA version 5, which is at
ftp://standards.nortelnetworks.com/sigtran/docs/diego00/draft-ietf-sigtran-m 
3ua-05.txt

>the messages where you see this support for both options?

I meant that I've seen people supporting staying with Protocol Data 1 and 2
and supporting using only Data 3, not both at once.

Cheers,

L. Ong

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 Aug 2001 00:07:01 -0500

Lyndon,

Lyndon Ong wrote:                                   (Tue, 28 Aug 2001 21:18:23)
> ftp://standards.nortelnetworks.com/sigtran/docs/diego00/draft-ietf-sigtran-m 

This is the M3UAv5 definition:

    "Network Appearance - The Network Appearance identifies an SS7 network 
     context for the purposes of logically separating the signalling traffic 
     between the SG and the Application Server Processes over a common SCTP 
     Association.  An example is where an SG is logically partitioned to 
     appear as an element in four separate national SS7 networks.  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.  A physical SS7 route-set or link-set at an SG can 
     appear in only one network appearance. The Network Appearance is not 
     globally significant and requires coordination only between the SG and 
     the ASP. Therefore, in the case where an ASP is connected to more than 
     one SG, the same SS7 network context may be identified by different 
     Network Appearances depending over which SG a message is being 
     transmitted/received."

Now you have really confused me.  You said that NI has no relationship
to NA.  Yet, this definition says "A Network Appearance implicitly defines
the SS7 Point Code(s), NETWORK INDICATOR and MTP3 protocol type/variant/
version used in a specific SS7 NETWORK PARTITION." [caps mine].  There it
is in black and white.

So NA has implicit in it Network Indicator and yet NI is explicit in the
Routing Label.  What happens when the NI implied by the NA and the NI
explicit in the RL do not match?  For example, what happens if the NA
specifies international point code format protocol variant and version
but the NI bits are not set to 00?  What happens if the NA specifies
national (say ANSI) point code format variant and version, but the NI
bits are coded to 00?  Which should the receiver use?

Also, this definition requires that an SS7 routeset can not appear in
more than one NA, but it does not restrict NA from being given a different
value for each routeset (the M3UAv8 definition).

On Page 31, M3UAv5 says:

    "In a Data message, the Network Appearance implicitly defines the SS7 
     Point Code format used, the SS7 Network Indicator value, and the 
     MTP3/MTP3-User protocol type/variant/version used within the SS7 
     NETWORK PARTITION.  Where an SG operates in the context of a single 
     SS7 network, or individual SCTP associations are dedicated to each 
     SS7 network context, the Network Appearance parameter is not 
     required." [caps mine]

In both the definition and description of NA's use in DATA, the NA
value is described as identifying an SS7 NETWORK PARTITION.  I presume
that this is the regular English use of the word partition which would
tend to indicate a subset of a network.

Is there anything in the M3UAv5 definition which precludes the M3UAv8
interpretation?

> and supporting using only Data 3, not both at once.

Sorry, my mistake.

--brian

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

---

---

From: "Alf Heidermark (UAB)" <[email-masked]>
Date: Wed, 29 Aug 2001 08:24:42 +0200

Yes I can do it.

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: den 29 augusti 2001 07:07
To: sigtran
Subject: Re: M3UA Issues List

Lyndon,

On Page 31, M3UAv5 says:

Sorry, my mistake.

--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: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 Aug 2001 01:42:46 -0500

Alf,

What can you do?

--brian

Alf Heidermark (UAB) wrote:  (Wed, 29 Aug 2001 08:24:42)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 Aug 2001 03:31:07 -0500

Greg,

You might want to add MTP Restart to your issues list.

The current procedure has problems with regard to ASP in an moving
to the INACTIVE state and even moving to the ACTIVE state.  Only
ASPs in the ACTIVE state are told when MTP restart ends.  Only ASPs
in the INACTIVE state for already configured Application Servers
receive MTP restart begins.  ASPs in the INACTIVE state for
unspecified Application Servers and ASPs which move from the DOWN
state to the INACTIVE state after MTP restart begins never receive
the DUNA which signals MTP restart begins yet can have missed a
number of DUNAs and DRSTs.  They never receive MTP restart ends
either (because it is only signalled with ASPAC Ack), yet their
routing information is out of sync with the SG.  This is partly a
problem because the DUAN signalling MTP restart begins is sent to
INACTIVE concerned ASPs.  Why is the SG sending SNMM messages to
INACTIVE ASPs?

--brian

Greg Sidebottom wrote:                                (Fri, 17 Aug 2001 15:15:48)

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Wed, 29 Aug 2001 07:35:21 -0700

IYWPYHOOYA!  If you had some network experience, you would know that NI is
typically a constant.  There are very few exceptions when more than one is
defined.  China is an example where they have an old network with 14-bit
addresses and a new overlay network with 24-bit addresses.  If you have to
participate in both then I would define separate NAs since the format of the
message has changed and you need to know the network context of the
messages.

But the more interesting example is when you have multiple ITU networks and
each has the same NI, etc.  In this scenario you must have separate NAs for
each network because the ITU networks have to reuse the PC values.  Hence,
NA+PC uniquely identifies all node in all networks involved.

John

> Sent: Wednesday, August 29, 2001 12:07 AM
> To: sigtran

---

---

From: Lyndon Ong <[email-masked]>
Date: Wed, 29 Aug 2001 09:16:14 -0700 (PDT)

Hi Brian,

Hmm, you're right, the definition is a bit hard
to interpret.

The issue that led to the NA being defined was that
different networks could reuse the same codepoints
and mean different things, e.g., with the same point
code and NI values.  As a result, you needed
something beyond the routing label to tell you how 
to interpret the codepoints at the AS/ASP.

You could presumably need an NA even if you were
using a single AS to process all of the received
messages, just to distinguish between different
networks' use of routing label codepoints.  If you
are using multiple AS you could subsume the 
NA semantics within the RC (conceivably you might
still break up the AS such that a single AS is
processing messages for multiple NAs, but that
doesn't seem realistic.)

The difference between v6 and v7 definitions was
that NA in the v7 definition identifies an SS7
entity by itself, rather than just the context
(overused
word) for interpreting the routing label.  That
I think was the objection that was brought up
against the v7/v8 definition.

Cheers,

L. Ong

wrote:
> Lyndon,
> 
> Lyndon Ong wrote:                                  
> (Tue, 28 Aug 2001 21:18:23)
> > Brian,
> > 

---

---

From: [email-masked]
Date: Wed, 29 Aug 2001 12:50:36 -0400

Lyndon,

My objection was to the following sentence which was added to the Network 
Appearance definition in v7:

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

Barry Nagelberg
Software Engineer
RadiSys, Corp.

Lyndon Ong <[email-masked]>
08/29/01 12:16 PM
Please respond to sigtran

Hi Brian,

Cheers,

L. Ong

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 Aug 2001 15:27:15 -0500

John,

You are making the mistake of overgeneralizing here.

--brian

John Schantz wrote:                                          (Wed, 29 Aug 2001 07:35:21)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 Aug 2001 15:15:53 -0500

Lyndon,

Lyndon Ong wrote:   (Wed, 29 Aug 2001 09:16:14)
>
> Hi Brian,
> 
> Hmm, you're right, the definition is a bit hard to interpret.
> 
> The issue that led to the NA being defined was that different
> networks could reuse the same codepoints and mean different
> things, e.g., with the same point code and NI values.  As a
> result, you needed something beyond the routing label to tell you
> how to interpret the codepoints at the AS/ASP.
> 
> You could presumably need an NA even if you were using a single AS
> to process all of the received messages, just to distinguish
> between different networks' use of routing label codepoints.  If
> you are using multiple AS you could subsume the NA semantics
> within the RC (conceivably you might still break up the AS such
> that a single AS is processing messages for multiple NAs, but that
> doesn't seem realistic.)
> 
> The difference between v6 and v7 definitions was that NA in the v7
> definition identifies an SS7 entity by itself, rather than just
> the context (overused word) for interpreting the routing label.
> That I think was the objection that was brought up against the
> v7/v8 definition.

I'm with you.  Because one description or the other does not
change and restrictions on the assignment of NA values, the
definitions themselves and which version of the draft they
occur in is moot.

I believe that there are some who wanted to restrict NA to having
one and only one unique value per network whatever.  If that is
what these "change NA definition back" people want, then they are
going to have to say so.

If someone wants the NA definition changed at this point, I think
it is up to them to propose the definition that they would like it
changed to.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 Aug 2001 15:22:11 -0500

Barry,

There is no MUST in this sentence, it is just descriptive.  Who cares
about sentences which don't place a requirement on implementation?
If the sentence said "MUST," I would object to it just as strongly as
you.

Is all you are proposing, then, that this sentence be struck?

It that's it, I agree with Barry.  Strike the sentence.  Striking it
will have no impact on the choice of NA values whatsoever, they can
be assigned on a per point code basis if the implementation so requires
or so desires.

--brian

[email-masked] wrote:                (Wed, 29 Aug 2001 12:50:36)

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

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Fri, 31 Aug 2001 16:18:44 +0200

Brian,

I have not seen any reply to your issue, and I must say
I am also puzzled by this Restart procedure, especially
the use of ASPACK Ack to signal the end of the restart.
I understand that not sending an ASPAC ACK immediately 
makes sense, but using that message to signal the end
of the procedure seems very strange.
I believe that the beginning of the restart is signaled
by a DUNA sent to the ASPs with affected PC=SG PC.
Then why is the end of the restart not signaled with the
corresponding DAVA?
What could be done would be, at the end of the restart
procedure, broadcast all TFP/TFR received to each ASP
ACTIVE (DUNA/DRST), and finish with a DAVA for the SG PC.
Also, upon returning an ASP ACTIVE ACK, the SGP should always
send the DAVA/DRST for those destinations that it knows
are not fully available since, presumably, the AS does not
have this information.

Any comments?
Francois.

> Sent: Wednesday, August 29, 2001 10:31 AM
> To: sigtran
> [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 31 Aug 2001 13:51:33 -0500

MOUILLAUD,FRANCOIS,

> of the procedure seems very strange.

I'm not sure that not either delaying ASPAC Ack or sending SNMM
to ASPs for INACTIVE AS makes any sense either.

It is clearly the obligation of the ASP for performing audits as
necessary using the DAUD procedure.  Whenever an ASP becomes
ACTIVE is has the ability to audit, if required, the state of
any and all destinations.

An ASP going active for an AS in the middle of restart is no
different.  The ASP either has the pertinent information from
SNMM received for other AS for which it is active, or it is
advisable that the ASP audit the connection anyways.

> Then why is the end of the restart not signaled with the

My question as well.  I think end of restart should be signalled
with DAVA(*).

> ACTIVE (DUNA/DRST), and finish with a DAVA for the SG PC.

I agree.

> are not fully available since, presumably, the AS does not

I don't think that is necessary.  The ASP which has gone newly
active is already permitted to (and should) perform a DAUD
procedure if it does not have current information.

I would say that when SS7 network isolation is encountered at
the SG, the SG may send a DUNA(*) to all ASPs (which are active
for an AS to which the isolation applies) to signal MTP restart.

The SG then sends DUNA/DRST throughout the MTP restart procedure
to the same set of AS to which DUNA(*) was sent.  The SG sends
DAVA(*) to the same set of AS to signal MTP restart ends.

If the SG receives an ASPAC for an AS for which the SG is in MTP
restart, is returns ASPAC Ack as per normal procedures.  It is
the responsibility of the ASP newly active for the AS to either
obtain current routing information received for other active AS
in the ASP or to perform a DAUD procedure before starting
traffic as per normal ASPAC procedures.

When an SG is restarting an it receives a DAUD for an AS for
which the ASP is newly active, it may delay completely
responding to the DAUD until the MTP restart of the SG is
complete.

In this way DAUD handles ASP restart, whereas DUNA(*) and
DAVA(*) handle SG restart.

This procedure decouples restart from ASPTM and reassures that
no M3UA messages (DATA and SNMM) are sent to an ASP in the
INACTIVE state for an AS.

What do you think?

--brian

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

---