Subject: M3UA v9: NA and RC in DATA and SNMM

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 11 Oct 2001 15:10:53 -0500

V9 has the text in section 3.3.1:

   In a DATA message, the Network Appearance implicitly defines the SS7 
   Point Code format used, the SS7 Network Indicator value, and the 
   MTP3 and possibly the MTP3-User protocol type/variant/version used 
   within the specific SS7 network.  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.  In other cases the parameter MUST be 
   included.

This MUST is not required for interoperability.  This should be
change to MAY as it is possible for implementations to always derive
NA from RC.  Only when wishing to interoperate with a crippled
implementation might a sending wish to include NA.  Thus MAY.

V9 also has the text in section 3.3.1 which says:

   The optional Routing Context parameter contains the Routing Context 
   value associated with the DATA message.   Where multiple Routing 
   Keys and Routing Contexts are used across a common association, the 
   Routing Context may identify to the receiver the traffic flow, 
   assisting in the internal distribution of Data messages.

The "may" here is completely insufficient from the discussions on
this issue.  It was clear from discussions that the RC MUST be included
in this circumstance for interoperability sake.  The received must
always be able to rely on the the RC value being present in this
circumstance as it has NO OTHER MEANS OF DETERMINING the traffic flow
associated with the message.

This text also needs to be changed in the SNMM sections.

I am rather suprised that this issue has been so poorly addressed in
the draft after all the discussion.

--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: "Schantz, John" <[email-masked]>
Date: Thu, 11 Oct 2001 14:01:50 -0700

I assume that you mean by a "crippled implementation" is one that is not
able to process the MTP parameters and hence must rely on the RC
instead.

I suggest that you stop using this phrase for a system that can process
the SS7 parameters, it is actually more descriptive of the RC based
system.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, October 11, 2001 3:11 PM
> To: sigtran
> Subject: M3UA v9: NA and RC in DATA and SNMM
> 
> 
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---

---

From: "Schantz, John" <[email-masked]>
Date: Thu, 11 Oct 2001 14:50:25 -0700

Then lets solve this instead of placing names on implementations.

The context of the paragraph was only talking about NA and the
information that it implies and when you need it.  I would assume that
it was talking about the cases where an RC (that implied NA) was not
present.  But by definition, RC does not imply NA.  It could potentially
imply NA by changing the definition.  But I could see implementations
using both NA and RC, I don't see why the two parameters can not work
together.

The (last) sentence could have easily been changed to the sentence below
to solve the concern:

The NA parameter MUST be included in the other cases unless the network
context is already implied by an RC parameter.

John

> Sent: Thursday, October 11, 2001 4:15 PM
> To: Schantz, John
> Cc: sigtran
> Subject: Re: M3UA v9: NA and RC in DATA and SNMM
> 
> 
> John,
> 
> It does not change the point that to perform ASPTM procedures 
> correctly
> an implementation MUST place RC in the DATA and SNMM messages when not
> implied by the association.  This was clear from our 
> discussions and has
> not been properly captured in the draft.
> 
> --brian
> 
> John Schantz wrote:                                          
> (Thu, 11 Oct 2001 14:01:50)
> > You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 11 Oct 2001 17:12:24 -0500

John,

Yes, RC implies NA.  And, no, NA is not required where RC is
present, and needs only be specified for those implementations
unable to derive NA from RC (simple lookup table).  Changing
the definition is not required, RC cannot span NA.

--brian

John Schantz wrote:                                          (Thu, 11 Oct 2001 14:50:25)
> context is already implied by an RC parameter.

But NA is alwasy implied by RC because RC cannot span NA.  So, this
sentence only says that NA is never required.  You need a statement
which says that NA can be included at the implementation's option
even though it is not required.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 11 Oct 2001 16:15:24 -0500

John,

It does not change the point that to perform ASPTM procedures correctly
an implementation MUST place RC in the DATA and SNMM messages when not
implied by the association.  This was clear from our discussions and has
not been properly captured in the draft.

--brian

John Schantz wrote:                                          (Thu, 11 Oct 2001 14:01:50)

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

---

---

From: Schmidt Andre <[email-masked]>
Date: Fri, 12 Oct 2001 10:33:18 +0200

Hello Brian,

What should happen, by receiving a DATA, if RC and NA are in conflict against itself? Is a plausibility check required on the receiving side? If "YES", how should the message be handled? Or is there a priority between these two optional parameters? Or is it not allowed (not visible in the draft) to send out both parameters together in a DATA-message? 

Best Regards 
           Andre

-----Ursprüngliche Nachricht-----
Von: Brian F. G. Bidulock [mailto:[email-masked]]
Gesendet: Donnerstag, 11. Oktober 2001 23:15
An: sigtran
Cc: [email-masked]
Betreff: Re: M3UA v9: NA and RC in DATA and SNMM

John,

--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: "Schantz, John" <[email-masked]>
Date: Fri, 12 Oct 2001 08:06:45 -0700

Audre,
	NA and RC can not conflict against each other and both CAN be
present in all messages.

Since NA is a network context (covering all point codes and their
traffic for a network) and RC is a routing context (a specific set of
traffic associated with single point code within a network), NA is the
first level of traffic separation.  RC is a secondary level separation
that separates traffic WITHIN a specific network context (NA).  Hence a
specific RC is just a specific traffic SUBSET within a network context
(NA).

Suppose you had an implementation that must handle traffic from an ANSI
network and an ITU network.  The implementation requires that individual
protocol stacks (ANSI and ITU) are used to only handle traffic from
their specific network "connections".  NA will separate the traffic into
ANSI and ITU traffic for the specific stacks.  If the node has multiple
RK per network "connection", then RCs are needed to separate the traffic
within a stack.

I think this is cleaner than letting RC handle both the network and
network-specific traffic separation.  I prefer to have separate
parameters to handle the network vs. internal network traffic
separation.

John

> From: Schmidt Andre [mailto:[email-masked]]
> Sent: Friday, October 12, 2001 3:33 AM
> To: sigtran
> Subject: AW: M3UA v9: NA and RC in DATA and SNMM
> 
> 
> Hello Brian,
> 
> What should happen, by receiving a DATA, if RC and NA are in 
> conflict against itself? Is a plausibility check required on 
> the receiving side? If "YES", how should the message be 
> handled? Or is there a priority between these two optional 
> parameters? Or is it not allowed (not visible in the draft) 
> to send out both parameters together in a DATA-message? 
> 
> Best Regards 
>            Andre
> 
> 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 12 Oct 2001 17:42:08 -0500

Andre,

Good question.  If RC only is provided, it provides both RC and NA
with no conflict.  When NA is also provided there can be a conflict.
However, that conflict would mean that the sender populated either
NA or RC in error.

I would think that the receiver of such an incorrectly coded message
would reply with ERR("Invalid Network Appearance") or ERR("Invalid
Routing Context") or even both.

--brian

Schmidt Andre wrote:                                      (Fri, 12 Oct 2001 10:33:18)
> Hello Brian,
> 
> What should happen, by receiving a DATA, if RC and NA are in conflict
> against itself? Is a plausibility check required on the receiving side? If
> "YES", how should the message be handled? Or is there a priority between
> these two optional parameters? Or is it not allowed (not visible in the
> draft) to send out both parameters together in a DATA-message? 
> 
> Best Regards 
>            Andre
> 
> 
> > To unsubscribe send a blank email to [email-masked]
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> 
> ---
> To unsubscribe send a blank email to [email-masked]
> 
> 
> ---
> To unsubscribe send a blank email to [email-masked]

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

---

---

From: Amish Chana <[email-masked]>
Date: Sat, 13 Oct 2001 15:37:57 +0100

Hi John,

If you see NA as providing a first level of separation and RC as a secondary 
level then for such a concept would it not be appropriate to remove NA from 
the RK? This would help to avoid potential problems (e.g. Andre's question). 
Then one could have 2 RCs with the same value but each one would be unique 
within a network context (NA).

Cheers,
Amish

>parameters to handle the network vs. internal network traffic

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

---

---

From: Lyndon Ong <[email-masked]>
Date: Mon, 15 Oct 2001 11:45:19 -0700 (PDT)

Andre, Brian,

There could potentially be a conflict, however,
I think we should avoid mandating a check in 
the specification, since it appears that
implementations will be using one or the other,
and not both, so this does not automatically
cause an error in processing the message.

Cheers,

Lyndon

--- "Brian F. G. Bidulock" <[email-masked]>
wrote:
> > > >    In a DATA message, the Network Appearance
> implicitly 
> > > > defines the SS7 
> > > >    The optional Routing Context parameter
> contains the 
> > > > Routing Context 
> > > >    Keys and Routing Contexts are used across a
> common 
> > > > association, the 
> > > > this issue.  It was clear from discussions
> that the RC MUST 
> > > > be included
> You are currently subscribed to sigtran as:
> [email-masked]

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

---

---

From: Schmidt Andre <[email-masked]>
Date: Tue, 16 Oct 2001 10:54:36 +0200

Hello Lyndon,

Can you give me a guarantee, what no other vendor, connected to your system, will never generate such a message inadvertently?

Hello Lyndon, Brian, Amish

To make this case simple to handle and to reach a fast and reliable routing I agree with the requirement from Brian to declare the RC in a DATA message as mandatory. 
In addition I would delete the NA as optional parameter from a DATA-message, because I'm absolute in agreement with Brian about the statement that NA can always derive from RC.

With Best regards 

Andre

-----Ursprüngliche Nachricht-----
Von: Lyndon Ong [mailto:[email-masked]]
Gesendet: Montag, 15. Oktober 2001 20:45
An: sigtran
Betreff: Re: M3UA v9: NA and RC in DATA and SNMM

Andre, Brian,

Cheers,

Lyndon

wrote:
> [email-masked]
> [email-masked]
> [email-masked]
> [email-masked]

---

---

---

From: Amish Chana <[email-masked]>
Date: Tue, 16 Oct 2001 21:16:18 +0100

Andre,

>Can you give me a guarantee, what no other vendor, connected to your 
>system, will never generate such a message inadvertently?

Let those who would like the NA included answer this question.

>To make this case simple to handle and to reach a fast and reliable routing 
>I agree with the requirement from Brian to declare the RC in a DATA message 
>as mandatory.
>In addition I would delete the NA as optional parameter from a 
>DATA-message, because I'm absolute in agreement with Brian about the 
>statement that NA can always derive from RC.

Okay.

Amish

---

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 17 Oct 2001 09:11:27 -0700

Actually a different take on this:

There are other bits of information that are in the DATA
and/or SNMM message that might also conflict with the RC,
namely, point codes, SIOs, CICs, etc.  It is always up to
the SG to make sure that it is correctly using the Routing
Key, NA is not anything out of the ordinary in this respect.
I don't see that it merits any special consistency check.

Cheers,

Lyndon

-----Original Message-----
From: Amish Chana [mailto:[email-masked]]
Sent: Tuesday, October 16, 2001 1:16 PM
To: sigtran
Subject: Re: AW: M3UA v9: NA and RC in DATA and SNMM

Andre,

Okay.

Amish

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

---

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 17 Oct 2001 09:31:45 -0700

Folks,

Let's try and settle on some text that is acceptable to all.
I still believe that the greatest interoperability 
(not just with systems that rely on the RC) would be to
make both RC and NA mandatory, but I realize that a number of
folks are going to scream endlessly over that.  So, let's try the
direction of making NA a configurable option and RC required
(if not implicit) in DATA messages.  The text would be as follows:

Network Appearance: 32-bits (unsigned integer)

   The Network Appearance parameter identifies the SS7 network 
   context for the message, and implicitly identifies the SS7 
   Point Code format used, the SS7 Network Indicator value, and the 
   MTP3 and possibly the MTP3-User protocol type/variant/version used 
   within the specific SS7 network.  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.  In other cases the parameter may be
   configured to be present for the use of the receiver.

   The Network Appearance parameter value is of local significance 
   only, coordinated between the SGP and ASP. Therefore, in the case 
   where an ASP is connected to more than one SGP, the same SS7 network 
   context may be identified by different Network Appearance values 
   depending over which SGP a message is being transmitted/received.

   Where the optional Network Appearance parameter is present, it must 
   be the first parameter in the message as it defines the format of 
   the Protocol Data field.

Routing Context: 32-bits (unsigned integer)

   The Routing Context parameter contains the Routing Context 
   value associated with the DATA message.   Where a Routing Key
   has not been coordinated between the SGP and ASP, sending of
   Routing Context is not required.  Where multiple Routing 
   Keys and Routing Contexts are used across a common association, 
   Routing Context MUST be sent to identify the traffic flow, 
   assisting in the internal distribution of Data messages.

I would like to consider the SNMM messages in a separate message, as
there have been different considerations expressed about NA and RC
in SNMM messages.

Comments?

Thanks,

L. Ong

---

---

From: [email-masked]
Date: Wed, 17 Oct 2001 15:30:35 -0400

Lyndon,

This sounds good.

Barry Nagelberg

"Ong, Lyndon" <[email-masked]>
10/17/01 12:31 PM
Please respond to sigtran

        To:     "sigtran" <[email-masked]>
        cc: 
        Subject:        RE: AW: M3UA v9: NA and RC in DATA and SNMM

Folks,

Comments?

Thanks,

L. Ong

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Wed, 17 Oct 2001 13:39:20 -0700

I would like to make some changes to definitions below.  NA must be a
coordinated/configured value a node level (SG or AS) not at an SGP and
an ASP level.  You would NOT have a different value for each SGP-ASP
pairing as it is now implied.  In fact, I would strongly object to
having different values per SGP or ASP.  The idea is to have ONE value
(NA) to represent the network context shared between at least 2 nodes
(an SG and an AS).  A wise network would use the same value (NA) for all
nodes that are sharing the same network context.  This would help not
only an AS/ASP receiving traffic from multiple SGs/SGPs but it would
also help the SGs coordinate the traffic between multiple ASs and when
they are functioning like STPs and are supporting "C-links".

I have modified the text below.  John

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, October 17, 2001 2:31 PM
> To: sigtran
     protocol type/variant/version, the Point Code format, the SS7 
     Network Indicator value, and the MTP3-User protocol 
     type/variant/version used within the specific SS7 network context.
     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.  In the
     other cases, the parameter may be configured to be present in the 
     DATA and SNMM messages.
>    only, coordinated between an SG and AS.  Therefore, in the case 
>    where an AS is connected to more than one SG or an SG is
     connected to more than one AS, the same Network Appearance value
     MAY be configured at theses nodes to represent their shared SS7
     network context.
> 
>    When the optional Network Appearance parameter is present, it must 
>    Keys and Routing Contexts are used across a common association
     and is used to assist in the internal distribution of Data
messages, 
>    Routing Context MUST be sent to identify the traffic flow.
> 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Oct 2001 16:50:27 -0500

Lyndon,

Your wording is excellent.  You have obviously given it some
thought.  I agree to this text for the DATA message.

Lyndon Ong wrote:                        (Wed, 17 Oct 2001 09:31:45)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Oct 2001 17:10:06 -0500

John,

I could not find a place in the current version of the
draft that requires or even implies that the NA or RC
values have to be the same across SGPs in an SG.

Yet, because SNMM (marked with NA and RC) need only be
sent by one SGP in an SG, it appears that NA and RC
values must indeed be coordinated across all the SGPs
in an SG.  I just can't find in the draft where that
is stated explicitly.

Nevertheless, this is not something that needs to be
addressed in the description of fields for the DATA
message: it applies more to SNMM, yet needs to be
established  in another section and the requirement
clearly laid that SGP within an SG MUST have the same
value assignments for NA and RC.

Also, your proposed modification to the NA field goes
way to deep into the definition of NA.  This is amply
defined in the terminology section (the new definition
of NA).

Your proposed qualification to the RC requirement is
unacceptable, because it appears to permit an
implementation to not include RC where it is not
required for distribution, yet where is is still needed
for ASP Traffic Management.

Lyndon's wording is more than adequate.

See below...

John Schantz wrote:                         (Wed, 17 Oct 2001 13:39:20)
>      other cases, the parameter may be configured to be present in the 

Definitions should be kept in the definition section instead
of repeated wherever they appear in a message.

>      MAY be configured at theses nodes to represent their shared SS7

Assignment of NA and RC across SGP should be addressed elsewhere,
not in the DATA field description.

>      and is used to assist in the internal distribution of Data

RC is required for ASP Traffic Management regardless of whether it
is used for distribution at the ASP or not.

--brian

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

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 17 Oct 2001 17:43:29 -0500

Hi Brian,

Please see question below.

 Tolga

> Sent: Wednesday, October 17, 2001 6:10 PM
> To: sigtran
[TOLGA] Why do you think like this? Although I also think that with most of the cases NA and RC will have the same mapping among SGPs, I don't see the point, why this is mandatory. When one ASP receives SSNM, it knows from which SGP it has received it and can use its mapping table. I don't see something wrong with this approach but to have NA and RC mappings one per SG will allow easier configuration.
> [email-masked]
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Oct 2001 19:04:18 -0500

Tolga,

[snip]

> [TOLGA] Why do you think like this? Although I also think that with most of
> the cases NA and RC will have the same mapping among SGPs, I don't see the
> point, why this is mandatory. When one ASP receives SSNM, it knows from
> which SGP it has received it and can use its mapping table. I don't see
> something wrong with this approach but to have NA and RC mappings one per SG
> will allow easier configuration.

You are correct of course.  My confusion.  There is no need
to coordinate NA or RC across SGP except for convenience of
configuration.

So we don't even have to address that.  Good.

--brian

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

---

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 17 Oct 2001 17:40:44 -0700

Hmm, this was actually an inconsistency in the text in v9. Oops...

-----Original Message-----
From: Schantz, John [mailto:[email-masked]]
Sent: Wednesday, October 17, 2001 1:39 PM
To: sigtran
Subject: RE: AW: M3UA v9: NA and RC in DATA and SNMM

---

---