Subject: M3UA: Proposed Solutions to issues 1, 2, 4, 16

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 29 Aug 2001 11:40:02 +0200

Hi Lyndon, Brian and others, 

I've been following the list during the last days and finally, I feel the need to add my humble contribution to help in clarifying the issues in order to move forward: 

Issue #1
---------

The Network Appearance, is a reference or context to allow an SG to differenciate an SS7 node in a unique way. I can see an easy way of fixing the definition of Network Appearance to express this in a clear way. What about to change the first sentence to:

"The Network Appearance is a reference (tipically an integer) that together with an SPC uniquely identifies an SS7 node (Signaling Point Code) by indicating the specific SS7 network it belongs to."

Issue #2
---------

The RC purpose is to serve as a quick index to refer the different Routing Keys at both sides (ASP and SGP). The main application is when an ASP serves to more than one AS. In that case, the RC is the only way for an ASP to differenciate the AS it is serving for that specific message, and therefore, treat it as expected. If we want that the ASP doesn't peek at the message to find the RK and from there obtain the RC when it is serving more than one AS, then we need to have the OPTION to SEND the RC within the DATA msg. 

The NA is used to differenciate SS7 nodes having the same Signaling Point Code. This is possible when different networks operators assign their SPCs independently of each other and they want to share the same SG. When a message is sent from an ASP to a node in the SS7 network thru the SG, we need to indicate the SPC AND ente destination network identified by the NA in order to be able to routethe message to a specific node. In addition, when receiving a message at an ASP, we need tthe OPC AND the NA in order to determine the origin of the message.

RC is an index to a RK, and the routing key may not have the OPC and NA to determine the SS7 network where the SS7 node is. Therefore we need to use the NA for that purpose in the DATA msg.

Summarizing: 
 - RC has to be included so that an ASP can distinguish the AS it is serving
 - NA has to be kept to solve those cases when the SS7 identification can be repeated in more than one SS7 network

Both parameters have to be optional since the rest of the cases don't need this specific information.

Issue #4
---------

The main purpose of M3UA is to serve a TRANSPARENT transport thru the IP world of SS7 signaling.

There are three points that I would like to raise:
 1- Applications in the IP world are the standard SS7 applications and don't have to be changed to be adapted to the IP transport world. This is the the SIGTRAN philosophy
 2- It's almost imposible to foresee the possible evolution of MTP3 in the next years, so any kind of message format trying to cover it, will probably fail
 3- MTP3 has well defined mechanisms for modifying the RL, working on the basis of extension words, that will work perfectly when needed. M3UA has to be transparent to this.

Taking into account all these points I can see as an error to move towards Payload 3.

If we include Routing Label + SIO formatted in the same way as they are transmitted thru the physical line, we cooperate to the transparency of the M3UA. This is a vital point since the application is expecting the SAME format as it is used in MTP3 (it is the same application in both worlds). In other cases ASP will need to reformat RL again into Payload 1 or 2 to pass MSU to the MTP3 application at the ASP. 

If new MTP3 versions come up, these can be also transported in the same way Payload 1 and Payload 2 do it. It will be again the application, the one who will be re-designed to use this new kind of versions  and that will be valid either in SS7 and IP.

The Payload 3 includes, by all means, two formatting processes: one in the SGP to transform the RL into payload 3 and another one in the ASP to transform payload 3 in a proper format (payload 1 or 2) to allow the SS7 application to understand it. 

Summarizing:
 - Payload 1 and 2 provides a seamless interworking in application IP/SS7, and therefore, we should use those formats
 - Payload 3 in not interoperable with SS7 applications and in addition, it means more processing. We only see disadvantages in this option.

We don't accept removing payload 1 and 2.

Issue #16
----------

I agree to change the text. 
This point could be considered as closed since nobody seems to have problems with it.

BR // Javier.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, August 28, 2001 9:28 AM
> To: sigtran
> Subject: Re: M3UA Issues List
> 
> 
> Lyndon,
> 
> Please see questions and comments below...
> 
> Lyndon Ong wrote: (Mon, 27 Aug 2001 22:52:23)
> >
> > 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...
> 
> 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.
> 
> > 
> > We're pretty close to agreement I think on the first 4 issues:
> > 
> > 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
> > contents
> 
> 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?
> 
> > 
> > What do people say?  Can we agree in principle on these as
> > 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/
> 
> 
> ---
> 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: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 Aug 2001 07:42:32 -0500

Javier,

Please see comments below...

Javier Pastor-Balbas (ECE) wrote:                          (Wed, 29 Aug 2001 11:40:02)
> I've been following the list during the last days and finally, I feel the
> need to add my humble contribution to help in clarifying the issues in order
> to move forward: 
> 
> 
> Issue #1
> ---------
> 
> The Network Appearance, is a reference or context to allow an SG to
> differenciate an SS7 node in a unique way. I can see an easy way of fixing
> the definition of Network Appearance to express this in a clear way. What
> about to change the first sentence to:
> 
> "The Network Appearance is a reference (tipically an integer) that together
> with an SPC uniquely identifies an SS7 node (Signaling Point Code) by
> indicating the specific SS7 network it belongs to."

This does not restrict NA the way that I believe you intend.  If NA is
assigned as Network Id + SPMC Point Code it will uniquely identify the
specific SS7 network an SS7 node belongs to, but there will be multiple
values of NA for each SS7 network.  If you want to restrict NA to one
value for each SS7 network you are going to have to say so.

> Issue #2
> ---------
> 
> The RC purpose is to serve as a quick index to refer the different
> Routing Keys at both sides (ASP and SGP).

The purpose of RC is to identify traffic flows an as such can be
viewed as an index into an AS table.  There are cases (already
cited) where there is no routing key on the ASP side which can be
derived simply from the routing key on the SGP side.

> The main application is when an ASP serves to more than one AS.

This should have been your first clue that RC identifies the AS and
the unique traffic flow to and from that AS.

> In that case, the RC is the only way for an ASP to differenciate
> the AS it is serving for that specific message, and therefore,
> treat it as expected.

RC is not the only way to identify traffic to an from the AS, but is
the adopted way in the working group and the way used by ASPTM
procedures.

> If we want that the ASP doesn't peek at the message to find the RK
> and from there obtain the RC when it is serving more than one AS,
> then we need to have the OPTION to SEND the RC within the DATA
> msg. 

If SGP is to know from which AS the message is coming from so that
it can perform ASPTM procedures (determine if the ASP is indeed
active for that AS), then the RC must be in the message when not
implicit.

> 
> The NA is used to differenciate SS7 nodes having the same
> Signaling Point Code.

Not under the current (or v5 or the above) definition.  NA can be
used to distinguish network id/network attachment.

> This is possible when different networks operators assign their
> SPCs independently of each other and they want to share the same
> SG.

Please explain the above a little better.  What has multiple network
operators and a single SG have to do with the issue?

> When a message is sent from an ASP to a node in the SS7 network
> thru the SG, we need to indicate the SPC AND ente destination
> network identified by the NA in order to be able to routethe
> message to a specific node.

We don't need to specify NA, only RC: RC implies NA.

> In addition, when receiving a message at an ASP, we need tthe OPC
> AND the NA in order to determine the origin of the message.

We only need the RC and the ASP does not need to determine the
origin of the message, only the MTP-User needs to determine the
origin of the message.

> RC is an index to a RK,

RC can be viewed as an index into the AS table.

> and the routing key may not have the OPC and NA to determine the
> SS7 network where the SS7 node is.

RK's can neither span NA's nor span SPMCs.  In the current draft
they cannot even span DPCs.  Therefore, RC implies both the NA and
DPC of the routing key.  Where RC is provided, neither NA (nor DPC
in the current draft) is required.

> Therefore we need to use the NA for that purpose in the DATA msg.

That purpose is fully served by RC in the message.

>  - RC has to be included so that an ASP can distinguish the AS it is serving

   - RC has to be included so that an SGP or ASP can identify the AS
     to which the traffic belongs to perform ASPTM procedures.
     (Determine if the message is for an active or inactive AS).

>  - NA has to be kept to solve those cases when the SS7
>  identification can be repeated in more than one SS7 network

   - NA is implicit in RC and never has to be provided where RC is
     provided.

> don't need this specific information.

RC must be optional, and NA is no longer required where RC is
optional.

> the IP world of SS7 signaling.

The stated purpose of M3UA in the draft is to provide the services
of the MTP/MTP-User interface at the ASP.

>  1- Applications in the IP world are the standard SS7 applications
>     and don't have to be changed to be adapted to the IP transport
>     world. This is the the SIGTRAN philosophy

What is a "standard SS7 application?"

>  2- It's almost imposible to foresee the possible evolution of
>     MTP3 in the next years, so any kind of message format trying
>     to cover it, will probably fail

The MTP primitive and even PDU interface has been remarkably stable
for 10 or more years.  There is no reason to believe that the same
stability will not be experienced for the next 10 years.

>  3- MTP3 has well defined mechanisms for modifying the RL, working
>     on the basis of extension words, that will work perfectly when
>     needed. M3UA has to be transparent to this.

M3UA can be transparent to RL by not including variant-specific
bit formats in messages.  M3UA's lack of transparency is exemplified
by the simple occurence of a Protocol Data 2.  If TTC decides to
use LI spare bits in Annex A, will we need a Protocol Data 4?
Protocol Data 2 for JQ.703 and Protocol Data 4 for JQ.703 Annex A?
You call this transparency?

> Taking into account all these points I can see as an error to move

With the points you make (not the false conclusions you draw) it
would be an error to not replace 1 and 2 with 3.

> 
> If we include Routing Label + SIO formatted in the same way as
> they are transmitted thru the physical line, we cooperate to the
> transparency of the M3UA.

That is how you lose transparency.  The fact that MP bits are in
a different location for TTC has demanded its own data format,
where as these bits are located in the SIO for ANSI.  How come you
need Payload Data 1 and Payload Data 2, whereas, Payload Data 3
can suffice on its own?  By the mere fact that 3 is one format
where 1 and 2 are several indicates the lack of transparency of
the 1 and 2 approach.

> This is a vital point since the application is expecting the SAME
> format as it is used in MTP3 (it is the same application in both
> worlds).

If the application is expecting anything, it is expecting the MTP
TRANSFER primitive with the RL broken out as arguments of the
primitive.  Some four or more commercial implementations of MTP
were cited in previous discussion on this matter as delivering
the RL contents as separate arguments of the MTP-TRANSFER primitive.
It is clear that MTP Users do not expect packed routing labels.
Therefore, the M3UA formatting should be the same as the
MTP-TRANSFER primitive provided to MTP-Users (broken out) so that
transparency can be provided.  That is Payload Data 3.

> In other cases ASP will need to reformat RL again into Payload 1
> or 2 to pass MSU to the MTP3 application at the ASP. 

This doesn't make sense.  The ASP will take the MTP-TRANSFER
primitve from the user with broken out parameters of the routing
label, place them easily (without regard to variant) in the
broken out fields of Protocol Data 3.  The ASP need not perform
any non-transparent, variant-specific packing of RLs as is the
case with the Protocol Data 1 and 2.

At the SG, the SGP receives the MTP-TRANSFER arguments broken out
in the same fashion that it receives them from the MTP-User.  The
SGP is always congisant of variant specifics and is fully aware of
how to pack these parameters into an RL: it always performs this
function for MTP-Users.

> 
> If new MTP3 versions come up, these can be also transported in the
> same way Payload 1 and Payload 2 do it.

But, gee, in the example above (JQ.703 Annex A) it looks like the
protocol will need a Payload 4.  So much for transparency.  Payload
3 can easily accomodate movement of specific fields within the bit
patterns of the message because the SG which knows those bit
patterns extracts them into the common parameter format of the MTP-
TRANSFER primitive.  So, on the contrary, Payload 3 will do it,
but Payload 1 and 2 will not.

> It will be again the application, the one who will be re-designed
> to use this new kind of versions  and that will be valid either in
> SS7 and IP.

For the example cited, neither the ASP nor the SS7 application need
be changed for JQ.703 Annex A with Payload 3, only the SGP (which
must be changed for the SS7 side anyway).  Payload 1 and 2 will need
Payload 4 added and changes made at the SGP and the ASP.  The SS7
application can still be buffered from these changes.  This is
because  Payload 1 and 2 force SS7 variant specifics on the ASP.
Payload 3 does not.  Payload 3 is transparent.  Payload 1 and 2 are
not.

> 
> The Payload 3 includes, by all means, two formatting processes:
> one in the SGP to transform the RL into payload 3 and another one
> in the ASP to transform payload 3 in a proper format (payload 1 or
> 2) to allow the SS7 application to understand it. 

SS7 applications do no use Payload 1 and 2.  SS7 application use
the MTP-TRANSFER primtive which is precisely the form of Payload 3.
Commercial MTP stacks to not deliver the routing label intact to
MTP-User as a normal course.  That would be incredibly foolish
programming to make the application so dependent on variant specific
bit-encoding.  RL contents are unpacked into a more usable machine
representation (e.g, C struct) which suits all variants.  It is
fascile: a simple, trivial, several line C struct.  You are way
off base here.

> 
> Summarizing:
>  - Payload 1 and 2 provides a seamless interworking in application
>    IP/SS7, and therefore, we should use those formats

   - Payload 1 and 2 pushes non-transparent SS7 variant-specifics
     into the ASP where none are necessary.

>  - Payload 3 in not interoperable with SS7 applications and in
>    addition, it means more processing. We only see disadvantages
>    in this option.

   - Payload 3 is the natural form of the MTP-TRANSFER primitive
     used by all MTP-Users, is completely transparent and requires
     no variant-specifics at the ASP, does not require the
     processing necessary by 1 and 2 to pack and unpack RLs at
     the ASP.  There are only advantages with this option.
> We don't accept removing payload 1 and 2.

We don't accept payload 1 and 2 either, particularly as you have
no argument.

> Issue #16

Barry disagreed to the change.  I'm sure some others did as well...

--brian

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

---

---

From: "Adams, Richard Anthony (Richard)" <[email-masked]>
Date: Wed, 29 Aug 2001 14:09:19 +0100

Javier Pastor-Balbas and Brian Bidulock wrote:

With kind regards,
Richard A. Adams,
[email-masked], tel : +44 1666 83 2503
fax: + 44 1666 83 2712
Lucent Tech.,
Swindon Road,
Malmesbury,
Wiltshire SN16 9NA.

> stability will not be experienced for the next 10 years.
[RAA] MTP3 in ITU-T is effectively in the "care and maintenance" state
(despite us extending the use of SIO in the latest Q.704 Implementors'
Guide). So, I agree with Brian, and apart from MTP3 decaying, I don't
anticipate any changes !  

---

---

From: "Schantz, John" <[email-masked]>
Date: Wed, 29 Aug 2001 08:06:41 -0700

You either totally missed Javier's points or you are just twisting them.

NI + PC does NOT uniquely identify signalling points.  NA + PC does and this
is what Javier said.

We have all heard the other stuff before, but Javiers view is close, if not
the same as mine and others.

> Sent: Wednesday, August 29, 2001 7:43 AM
> To: sigtran
> Subject: Re: M3UA: Proposed Solutions to issues 1, 2, 4, 16
> 
> 
> Javier,
> 
> You are currently subscribed to sigtran as: [email-masked]

---

---

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

John,

You are totalling missing the point: RC uniquely identifies signalling points.

--brian

John Schantz wrote:                                          (Wed, 29 Aug 2001 08:06:41)

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Wed, 29 Aug 2001 14:10:42 -0700

No you are.  I don't want a single value that uniquely identifies a
signalling point.  I want a value that I can use with the already assigned
PC to uniquely identify the signalling point.  I can also use this value to
identify all signalling points within a network.

I don't want a value that replicates PC assignments (the RC).  If I had only
RC, then I would not be able to easily identify all SPs within a network.

> Sent: Wednesday, August 29, 2001 3:26 PM
> To: sigtran

---

---

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

John,

John Schantz wrote:                                          (Wed, 29 Aug 2001 14:10:42)
> RC, then I would not be able to easily identify all SPs within a network.

The implementation cn use whatever data model it wants.  RC is sufficient
by protocol definition.  How the implementation organizes data is implementation
specific.

I suggest that you have more than RC in your data model, but more than RC is
not required in the protocol (DATA and SNMM).

--brian

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

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 30 Aug 2001 17:28:47 +0200

Hi everyone, 

Following are some of my responses and thoughts.

Issue #1
---------

Brian, from your response it seems to me that you could accept the definition we proposed:
"The Network Appearance is a reference (tipically an integer) that together with an SPC uniquely identifies an SS7 node (Signaling Point Code) by indicating the specific SS7 network it belongs to."

As you say, this definition does not restrict how the SG manages the NA. We can assign the same NA for all the SPC that belong to a specific network, or different ones within the same network. Since this fact does not affect to M3UA interoperability, it can be considered implementation dependant.

Issue #2
---------

A RC points to an IP destination (ie an AS). It is not intended to point to a destination in the SS7 network. It is used for the SG routing analysis with the purpose of finding out the right AS where the incoming SS7 message has to be sent. 
 
On the other hand NA points to the SS7 world. It can be used by the SG to discriminate amongst different SS7 nodes with the same SPC and NI. You have the option of including the SS7 node's SPC within the RK, but this is not compulsory and increases the management complexity. Referring to what you say about spanning NA's, as I've just said, an NA points to an SS7 network, and obviously, one AS can interworks with several nodes in the SS7 network. So that there is no need to restrict the number of NAs controlled by an AS. 

At least these are the definitions that are included in the draft, and how people is mostly implementing it. The way you use RC to cover the cases where NA is needed is implementation dependant.  

NA is very useful to distinguish different networks. It does not create any interop problems and its adoption can simplify the implementation for certain scenarios. So that this should be kept as optional in the DATA msg.

Of course, we also support the inclusion of the RC as an optional parameter within the DATA msg.

Issue #16
---------
I'm sorry but, looking at the mail archives, I didn't find the mail you are referring to...

Do you have any special reasons to reject the SUA's RC definition?  

SUA's definition includes the purpose of the RC from a functionaloint of view and why this parameter should be included in the communication between an SGP and AS. All this important info is missing in the M3UA definition.

In addition, we should addopt the SUA's definition in order to align both drafts. It is more complete and clear.

BR // Javier.

> Sent: Wednesday, August 29, 2001 2:43 PM
> To: sigtran

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 30 Aug 2001 14:08:47 -0500

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Thu, 30 Aug 2001 17:28:47)
> As you say, this definition does not restrict how the SG manages the NA. We
> can assign the same NA for all the SPC that belong to a specific network, or
> different ones within the same network. Since this fact does not affect to
> M3UA interoperability, it can be considered implementation dependant.
> 

Janvier, I didn't ask for a change to defintition of NA.  I asked that
NA be assigned as ID + CPC to aid monitoring and administration of
values.  This issues is, I beleive, whether NA should revert back to 
previous definition.  If it doesn't need to, there is no issue.

> 
> Issue #2
> ---------
> 
> A RC points to an IP destination (ie an AS). It is not intended to point to
> a destination in the SS7 network. It is used for the SG routing analysis
> with the purpose of finding out the right AS where the incoming SS7 message
> has to be sent. 
>  
> On the other hand NA points to the SS7 world. It can be used by the SG to
> discriminate amongst different SS7 nodes with the same SPC and NI. You have
> the option of including the SS7 node's SPC within the RK, but this is not
> compulsory and increases the management complexity. Referring to what you
> say about spanning NA's, as I've just said, an NA points to an SS7 network,
> and obviously, one AS can interworks with several nodes in the SS7 network.
> So that there is no need to restrict the number of NAs controlled by an AS. 
> 
> At least these are the definitions that are included in the draft, and how
> people is mostly implementing it. The way you use RC to cover the cases
> where NA is needed is implementation dependant.  
> 
> NA is very useful to distinguish different networks. It does not create any
> interop problems and its adoption can simplify the implementation for
> certain scenarios. So that this should be kept as optional in the DATA msg.
> 

By separating traffic between SGP and ASP, RC is also implicitly separating
traffic between endpoints in the SS7 network.

The Routing Context definition from SUA that you want to use below says:
"The Routing Context also uniquely identifies an SS7 entity (point code)
 into an SS7 network, as present by the SG."

That includes even the definition of NA.

There is no need for NA except when RC is generated.  NA does not need to
be in SNMM or DATA.

> SUA's definition includes the purpose of the RC from a functionaloint of
> view and why this parameter should be included in the communication between
> an SGP and AS. All this important info is missing in the M3UA definition.
> 

I proposed we use SUA defintition of RC.  Barry thought it was too vague.

See thread "M3UAv8: Routing Context Defintion" and specifically the
note of Wed, 15 Aug 2001 15:32:44 -0400.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 30 Aug 2001 15:37:38 -0500

Lyndon,

Lyndon Ong wrote:                                          (Thu, 30 Aug 2001 13:10:53)
> > There is no need for NA except when RC is generated.
> 
> I mentioned this before, there is a corner case 
> where this might not be true - if you define a single
> AS to handle messages coming from multiple networks
> which use overlapping routing label codepoints,
> you might still need an NA to provide a context for
> the routing label, and RC being one-to-one
> with AS would not be sufficient.

The definition of Routing Key, Routing Context, and
Signalling Point Managment Cluster does not currently
permit the corner case which you describe.  RK can't
span SPMCs and SPMC can't span networks.  As such, an
AS cannot span networks either.

This is an appropriate restriction because it would
be quite difficult for an implementation to determine
the management view for an SPMC which exists in several
networks simultaneously.  I believe that even John S.
would agree that an SS7 entity which exists in several
networks must be viewed as separate signalling points
from the view of SS7 management.  Thus the restriction
that an AS cannot span SPMC.

So, while you can conceive of a corner case, it is not
the case with M3UA.

> I thought originally that RC could subsume NA, but I'm
> wondering if this is always the case.

It is always the case because RC, through its 1:1
relationship to RK uniquely identifies an SPMC.  Thus
the last sentence in the SUA definition of RC (but,
SU doesn't use the term SPMC because there was no need
to included a long-winded definition of SPMC for this
single usage).

The Network Appearance is a characteristic of an SPMC.
Because RC uniquely identifies an SPMC (RK cannot span
them), it also uniquely identifies the Network Appearance
as a characteristic of the SPMC.

Because Network Appearance can always be obtained by
"using the RC as an index for a RK into the AS table",
there is no need for NA to be exchanged between SGP and
ASP in the protocol.  RC suffices.  Because RC has
registration procedures and is flexible in its coordination
between SG and ASP, it is completely neutral when exchanged
between SGP and ASP.

If NA is derived from RC at both SGP and ASP rather than
being exchanged, there will be no need (for statically
configured RCs) to coordinate NA values between SGP and
ASP.  Each can use their own internal values for NA and 
there will be none of the attendant nightmares of NA
administration.

RC can easily subsume NA as it already does so by definition.

> BTW, the SUA definition for RC implies a one-to-one
> relationship to entity within an (specific) SS7
> network, but again there is a multiple network case.

In SUA, the definition is intended to restrict the RK to
not span SPMC as well.  SUA does not define RK and the
v7 draft does not have a registration procedure (v8 will,
I believe) so the RK seems a little more vague.

Nevertheless, there are a whole host of reasons why RK
cannot be allowed to span SPMCs (and maybe even point
codes) in SUA.  (One of them also being single view
presentation of SS7 management at both MTP (N-PCSTATE)
and SCCP (N-STATE) levels).

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 30 Aug 2001 15:59:04 -0500

Lyndon,

I eagerly await any proposal.

Aside from the descriptive sentence that Barry objects
to in the v8 definition, I think the matter of NA
definition is pretty much a non-issue.

--brian

Lyndon Ong wrote:  (Thu, 30 Aug 2001 13:17:25)
> Ideally, folks who are concerned with the v8
> definition of NA (so Javier, John, Barry, any others)
> should make a common proposal and we can see if
> this is acceptable to people.
> 
> Brian, do you have an objection in principle to 
> this, or would you reserve opinion until you see
> a specific proposal?
> 
> Cheers,
> 
> L. Ong
> 

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Thu, 30 Aug 2001 14:21:40 -0700

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, August 30, 2001 3:38 PM
> To: sigtran

If this is the case you don't need RC either.  You are forgetting that the
AS and ASP life within M3UA.  The REAL applications that set above SCCP
could receive messages from different networks as Lyndon described.  NA
provides a means for a protocol stack to separate the traffic, PCs, and
their statuses or NA can be used to point to separate protocol stacks which
would then have separate traffic, PCs, and PC statuses.  Sitting on top of
the single/multiple stack is the REAL application.  It can direct which
network to send messages on via the NA.  For wireless roamers, this allows
the REAL application to work with all of the networks.  I have a REAL
application that does this.  RC and especially assigning different RCs to
each PC is an administrative nightmare that I am not willing to tackle.  I
already know what works, NA v5/v6 definition, and I know what has a high
probability of not working, RC. 

> that an AS cannot span SPMC.

Hence, the reason for NA so that the SS7 entities of the node can be keep
separate and they only merge at the REAL application level (far above M3UA,
AS, etc.)

> So, while you can conceive of a corner case, it is not

I think I already provided that it is a case for M3UA or at least a set of
M3UA stacks within a node.  If you are going to restrict this to a single
network, then NA and your RC goes away.  So what is your argument?
 
> to included a long-winded definition of SPMC for this

We don't need another THINK to uniquely identify the SPMC, the PC already
does that.  All we need is a value that can be added to the PC so that a
node can serve as more than one signalling point in multiple networks, this
is the NA!

> as a characteristic of the SPMC.

NA is not a characteristic of SPMC.  It is not an existing SS7 message
parameter!  NA was added as a local concept via MTP-SAP & SCCP-SAP.  We
don't need a routing index which is what RC is.

> between SG and ASP, it is completely neutral when exchanged

I don't need or want a routing index (RC).  All I need is a SINGLE value per
network so that I can separate the everything.  I don't need to reassign
every PC in all the networks with NEW PC (RC), isn't this extremely
redundant!!!
 
> I believe) so the RK seems a little more vague.

Have you ever thought that maybe SUA has it wrong.  If I had plans to
implement SUA don't you think I would be on their case.  I am hoping that
SUA will notice the error via this M3UA discussion and go back and fix their
spec.
 
> and SCCP (N-STATE) levels).

NA solves your problem but you just can't see it.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 30 Aug 2001 17:21:04 -0500

John,

Do you have proposal for when NA would be included in DATA and
SNMM given that RC is included where not implicit?

Please see additional comments below...

John Schantz wrote: (Thu, 30 Aug 2001 14:21:40)

[snip]
> probability of not working, RC. 

In one breath you way that you don't need RC, in another you
don't want to assign RC on the same basis as NA, and in the
last you say assigning RC is an administrative nightmare.

Please clarify.

> separate and they only merge at the REAL application level (far above M3UA,

I take it you agree that RC can be restricted to not span SPMC.

> network, then NA and your RC goes away.  So what is your argument?

The corner case described by Lyndon cannot logically occur under
the existing M3UA definitions.

> node can serve as more than one signalling point in multiple networks, this

It doesn't change the fact that NA does not need to be exchanged
between SGP and ASP in DATA and SNMM, because RC is both necessary
and sufficient.  NA does sometimes need to be exchanged in REG REQ.

> NA is not a characteristic of SPMC.

You stated above that NA was added to PC to identify SPMC:
I call it a characteristic but you can call it as you like.
Each SPMC has one NA value associated with it.

> It is not an existing SS7 message parameter!

NA is a function of the route upon which an SS7 message was
received and the NI bits in the message.  It has a firm basis
in the SS7 model.

> NA was added as a local concept via MTP-SAP & SCCP-SAP.  We

RC is more than a routing index: it identifies traffic flow
to an form an AS.  An AS in M3UA is associated with only one
MTP-SAP and in SUA, one SCCP-SAP.

> I don't need or want a routing index (RC).

I think that you have made this well known.  I'm sorry but
we cannot suspend the entire AS model and ASPTM procedures in
M3UA just so that you can go without an RC.  The draft even
required that RC values must either be statically provisioned
or provided in registration.  It was never the intent of M3UA
to permit an implementation to do without RC altogether.

> All I need is a SINGLE value per network so that I can
> separate the everything.  I don't need to reassign
> every PC in all the networks with NEW PC (RC), isn't this
> extremely redundant!!!

It is not necessary for you to assign a RC to each distant
point code.  It has been pointed out to you on several occasions
that you can assign RC values in the identical fashion to the
way you would assign NA values.

> > > network, but again there is a multiple network case.

You missed the point code in parentheses in the definition
when referring to SS7 entity.  The only reason for not saying
just point code was to permit alias point codes within the
same point code numbering space as the primary.

> SUA will notice the error via this M3UA discussion and go back and fix their

Aside from me raising consistency issues between SUA and M3UA,
there is no last call issue on SUA's use of RC.  You may not
intend to implement SUA, but there are certainly a good number
of people who have contributed issues to SUA last call and who
intend to implement.  You may still have an opportunity to raise
this as an issue for SUA if you feel so strongly about it.  But
as no objections have been raised either in the change to RC in
SUAv7 nor in last call, I think the concensus view will probably
be against you there.  But please feel free to raise the issue.

> NA solves your problem but you just can't see it.

RC solves your problem but you just can't see it.

--brian

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

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Fri, 31 Aug 2001 15:25:18 +0200

Hi, 

We fully support Lyndon's view, which also coincides with John's.

To technically support our possition we can only repeat previous explanations. If you have any specific argument contradicting what we claim, please, let us know:

"Referring to what you say about spanning NA's, as I've just said, an NA points to an SS7 network, and obviously, one AS can interworks with several nodes in the SS7 network. So that there is no need to restrict the number of NAs controlled by an AS." (from our previous mail)

The SPMCs are a set of ASs that serve to the same SPC in the IP network, NOT in the SS7 network. So there is no such SPMCs spanning.

BR // Javier.

> From: Schantz, John [mailto:[email-masked]]
> Sent: Thursday, August 30, 2001 11:22 PM
> To: sigtran
> Subject: RE: M3UA: Proposed Solutions to issues 1, 2, 4, 16
> 
> 
> 
> 

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Fri, 31 Aug 2001 16:11:33 +0200

Hi, comments inline.

> Sent: Thursday, August 30, 2001 9:09 PM
> To: sigtran

(snip)
>  into an SS7 network, as present by the SG."
(snip)

Yes, you are right. That sentence is wrong for M3UA. We can keep the rest of the SUA's definition to close issue #16.

BR //Javier.

---

---

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

Javier,

> the SUA's definition to close issue #16.

The sentence is right for M3UA as well.

Issue 16 is not closed.

--brian

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

---

---

From: Lyndon Ong <[email-masked]>
Date: Fri, 31 Aug 2001 17:39:59 -0700 (PDT)

Folks,

Basically it seems to me that there are two different
models for processing messages at the ASP.

Model 1 uses the RC alone to determine which AS
should get the message.  Since the RC/RK/AS
have a one-to-one relationship, RC by itself is
sufficient.

Model 2 uses the routing label information to
determine which AS gets the message.  This model
requires the NA to be sent (possibly by setting
RC=NA) to identify the context for the
routing label, in certain cases (multiple networks).

Can these models coexist?  This should be possible,
since RC and routing label can be included in
DATA and SNMM messages.  The main issue seems to be
whether RC incorporates NA or NA is sent as a 
separate parameter.

While I believe that RC can incorporate NA in
most cases, the two are semantically different, so
I can see an argument for keeping them separate,
and in Model 1 ignoring NA, in Model 2 ignoring
RC, i.e., not checking for consistency.

(Note: it is also possible that you may need NA
in the case where no Routing Keys are defined,
so there is no RC).

So: can we agree to have both NA and RC as optional
parameters in DATA and SNMM, and both sent whenever
their meaning is not implicit in the routing label?

(Note 2: it may be necessary to send a list of RCs
in an SNMM if it applies to multiple RCs, or have a
default interpretation that if no RC is sent, the
SNMM applies to all AS's within the receiving ASP.)

Let the flames begin...

Cheers,

L. Ong

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 31 Aug 2001 20:11:08 -0500

Lyndon,

> in the case where no Routing Keys are defined,

Where no routing keys are defined no messages will
flow by definition of RK and AS.  If there is no RK,
there is no AS.

I think you mean a Routing Key which is wildcarded in
all fields.  The definition of Routing Key does not
permit this.  A Routing Key cannot span SPMC.

> their meaning is not implicit in the routing label?

I do not agree to sending both  The reason for not
agreeing to both is that it would unnecessarily
require the administration and coordination of
assignment of both NA and RC between SG and ASP in
the case where RC is statically allocated.

If one says: "NA need only be sent when it is not
implied" ==> "NA need not be sent when RC is sent".

Where RC is statically allocated, NA does not need to
be agreed between SG and ASP.  As such, even though it
may not be implicit in the routing label, it does not
need to be provisioned just to place it in the message.
Because dynamic registration is optional, requiring
implementations and network operators to assign NA
values where they are not required is not acceptable.

> SNMM applies to all AS's within the receiving ASP.)

SUA N-PCSTATE SNMM which are identical to M3UA SNMM
in every other respect support a list of RCs.

> Let the flames begin...

No flames.  Keep this up and we might come to a 
resolution.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 31 Aug 2001 21:19:27 -0500

Hey Lyndon,

Here's an idea: restrict the definition of SG
to not permit a (logical) SG to span multiple SS7
networks.  Then SIO from RL is always sufficient
(as it is in SS7) to determine form and numbering
space of point codes in DATA, and SNMM never applies
to more than one network.

Then Network Appearance could be removed altogether.

Building on that: to overcome limitations imposed
in the above, permit the SGP to belong to more
than one SG and add an SG Identifier (when not
implicit) to DATA and SNMM messages.  Because the
ASP already needs to know which SGP belong to which
SGs, this does not cause an adminstrative problem.

Note that there is no conflict between SIO and this
SG Identifier.  There is also no conflict between
this SG Identifier and RC.  Assigning SGPs to SG is
already part of the configuration data required at
an ASP, so no additional administrative overhead is
imposed.

The SG identifier also identifies the network to
which the logical SG is attached and can be used
by implementations which refuse to use RC in the
same manner as they previously used NA.

With a short list of SG identifiers, a passive
monitoring box could even decipher messages.

Comments?

--brian

On Fri, 31 Aug 2001, Brian F. G. Bidulock wrote:

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

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

---