Subject: M3UA Issue 12 (was Re: M3UA Open Issue Update (Sept 18th))

From: Greg Sidebottom <[email-masked]>
Date: Thu, 20 Sep 2001 11:29:42 -0400

Greetings Rajiv,

Apologies for the delay - responses below ...

----- Original Message -----
From: "Duhoon, Rajiv" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Tuesday, September 18, 2001 7:03 PM
Subject: RE: M3UA Open Issue Update (Sept 18th)

> Hi Greg,
>
> Few days back I tried to initiate discussion on
> issue# 12 but couldn't see any response from
> anybody. I was seeking clarification on following
> issues.
>
> 1) Is there any limit to the max number of routing
>    keys that can be present in single REG REQ
>    message.

[Greg] There is no limit right now which I would agree could be a problem
for M3UA (SUA?) internal implementations.  At a practical level I have never
thought we would see REG REQ messages carrying dozens of RKs but it may be
useful to subscribe to a limit.  In the initial stages of M3UA we limited
DAUD and DUNA/DAVAs to contain only 16 Affected destinations so that we
could keep the message sizes down below the MTP3 maximum.  We probably
should do something similar for REG REQ (i.e. do the math to find the
maximum number of RKs to fit under 256 bytes (difficult) or perhaps just
give a byte limit for breaking into multiple REG REQs).  Do people agree?

> 2) Is there any limit to the max number of SI, SSN,
>    OPC, CIC Ranges that can be present in one single
>    routing key.

[Greg] No again.  As pointed out previously by others, there is a lot of
flexibility in the RK format but in practical terms most of the flexibility
is limited by real applications (i.e., not all of the combination make
sense) Also, using multiple ranges in an RK may risk having the SG rejecting
the RK if it cannot understand the request.  There is operational merit in
keeping the RK in the REG REQ as simple as possible.  I suspect that there
is no practical problem in not limiting the number of any sub-parameters in
an RK but who can say for sure.  But we could give a byte limit, working
backwards from a REG REQ message limit.  Views?

> 3) Can the "Status" Tag  be used for  "Registration
>    Status/ De-registration Status" in Routing key
>    registration/De-registration messages ?

[Greg] Not sure what you mean here.

>
> 4) Will the parameters (Local-RK- Identifier, Registration
>    Status, Routing Context) in  REG RSP / DEREG RSP be
>    present with their Tag Values ? If  yes then we
>    need to know the Tag value of "Registration Status/
>    De-Registration Status" Parameter.If not then can
>    the assumption be made that the sequence of the
>    parameters defined in the messages will be  used
>    to find out the correct parameters value.
>
> Thanks,
> Rajiv

[Greg] This is the essence of Issue 12.  I initially thought that
tags/lengths were not required as each status was a sequence of three
mandatory fixed length subparameters.  But for consistency we could change
to show the tags/lengths.  We need to decide on this one way or the other -
what do people prefer?

Thanks,

   Greg Sidebottom

   Canadians can help with the US tragedy:
http://www.redcross.ca/english/fundraising/

>
>
>
> -----Original Message-----
> From: Greg Sidebottom [mailto:[email-masked]]
> Sent: Tuesday, September 18, 2001 3:44 PM
> To: sigtran
> Subject: M3UA Open Issue Update (Sept 18th)
>
>
> Greetings,
>
> As promised, here is the latest status for the open issues.  Javier and I
> are shooting for an Issue 9 by the end of September.
>
>
> 1) Change Network Appearance semantics/format.           Status: Closed?
>
> 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?)?
>
>
> Propose as closed - new definition from Javier in an e-mail of Sept 13th
> seems to be accepted:
>
> "Network Appearance - The Network Appearance is a local reference
(typically
> an integer) that together with an SPC uniquely identifies an SS7 node by
> indicating the specific SS7 network it belongs to. It can be used to
> distinguish between signaling traffic associated with different networks
> being sent between the SG and the ASP over a common SCTP association. An
> example scenario is where an SG appears as an element in multiple separate
> national SS7 networks and the same SPC value may be reused in different
> networks."
>
>
> 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
>
>
> Agreed on adding RC as optional parameter for both Data and SSNM.  CPC in
> SSNM messages then not required.  Not agreed to remove optional NA.
> Proposal from Lyndon re guidelines for inclusion of NA and/or RC.  SPMC
> definition clarified - SPMC is in one specific NA.
>
>
> 3) SSNM messages semantics at the SGP or SG level.         Status: Closed?
>
> Options:  SSNM messages apply to each SGP (current) or SG-wide (previous).
> Or define an new SGP-level message set (extension draft?)
>
>
> Seems to be agreement to go back to SG semantics (per Lyndon).   Greg
> reviewing e-mail discussion and current text to evaluate changes.   Agreed
> to add ASPIA Ack procedure from SG to allow graceful withdrawal of SG
>
>
>
> 4) Format of Routing Label/SIO in DATA message.                Status:
Open
>
> Options: Add new Protocol Data 3 parameter or just have one choice with
all
> Routing Label/SIO elements parameterized.   Also an option from Barry for
an
> Data format without routing parameters - any support?
>
> Still open - current poll by Lyndon of group's views.
>
>
> 7) Change-over / Change-back support.                 Status: Open
>
> Need more discussion on list.  Possible technical solution from Brian
using
> Correlation ID but don't yet have agreement on need for this
functionality.
> Possible M3UA extension draft?  Issue also for SUA?
>
>
> 9) Change Traffic Mode to optional in REG REQ, ASP Active, ASP Active Ack
> Status: Closed?
>
> 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..
>
>
> Discussion on list supports Traffic mode to be optional in these message -
> but some recent e-mails from Gery, John L suggest that this may not be
> finalized.  Greg to take to list to finalize the exact agreement.
>
>
>
> 10) User Part Unavailable support - STP-mode, SEP Mode
> Status: Open
>
> Whether to support UPU at SG using STP model.   Also SEP model
>
> Some recent related discussion on SUA thread but need more discussion re
> M3UA.
>
>
> 11) IPSP cases supported or not.                     Status: Open
>
> Proposal from Maria-Cruz to incorporate IPSP into Examples.    Brian's
> comments to remove IPSP entirely.
>
> Javier and John L have been working together on a common proposal across
> M3UA and SUA  They are currently leaning toward the following:
>
>   - change to double-ASPAC procedure for IPSP cases, clarification text on
> the IPSP behaviour in the ASP-SG scenarios, include text reflecting the
> current list discusssion with Amish, then review IPSP examples from
> Maria-Cruz for changes.
>
>
> 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)
>
> No discussion on list.  Greg to send out e-mail to initiate discussion.
>
>
> 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?
>
> Agreed to align across ALs.  Greg to discuss with Ken M and John to ensure
> alignment.   Same for message tag value alignment for common AL messages
>
>
>
> 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.
>
> Agreed to add error code and procedures.  Greg to make text proposal to
> list.
>
>
> 15) Open up RK format to allow NA range, multiple DPCs etc
> Status: Agreed/Open
>
> Proposal from Maria-Cruz seems agreed but not added yet.  NA range is
ruled
> out in another thread.   Greg to review proposal and solicit final
agreement
> from list.
>
>
> 16) Routing Context Definition                             Status: Open
>
> Alignment with SUA?   (see e-mail from Brian)
>
> Javier studying and plans to make a proposal soon.
>
>
> 17) MTP Restart Procedures                                  Status Closed?
>
> Text proposal in e-mail from Francois looks agreed.  Brian brought up
> off-line a small issue with the mask parameter in SSNM messages - A mask
> value equal to the number of bits in the DPC indicates that the entire
> network appearance is affected, indicating network isolation to the ASP.
> This should be changed to "equal to or greater than the number of bits to
> allow an all "1s" mask.
>
>
>

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

---

From: [email-masked]
Date: Wed, 26 Sep 2001 14:49:13 +0300

Hi Greg,

> [Greg] There is no limit right now which I would agree could 
> be a problem for M3UA (SUA?) internal implementations.  At a 
> practical level I have never thought we would see REG REQ 
> messages carrying dozens of RKs but it may be
> useful to subscribe to a limit.  In the initial stages of 
> M3UA we limited DAUD and DUNA/DAVAs to contain only 16 Affected 
> destinations so that we could keep the message sizes down below 
> the MTP3 maximum.  We probably should do something similar for 
> REG REQ (i.e. do the math to find the
> maximum number of RKs to fit under 256 bytes (difficult) or 
> perhaps just give a byte limit for breaking into multiple REG REQs).
> Do people agree?

I don't think that this is really an issue.  As the REG REQ
message is being carried over SCTP, SCTP will handle the 
fragmenting the message if it is over the MTU.  

John

---

---

From: Greg Sidebottom <[email-masked]>
Date: Wed, 26 Sep 2001 13:18:52 -0400

Hi John ...

----- Original Message -----
From: <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Wednesday, September 26, 2001 7:49 AM
Subject: RE: M3UA Issue 12 (was Re: M3UA Open Issue Update (Sept 18th))

> fragmenting the message if it is over the MTU.

I don't think that this issue is intended to limit the message size over
SCTP - as you say SCTP has the capability to handle long messages.  The
issue as I interpreted it was to provide an upper bound for RK processing
and buffer allocation at the receiver.

I note that nobody on the list supported the need or commented on a possible
limit.   If anyone feels this is important please speak up or I propose to
close this (part of the) issue without change.  As I mentioned it may not be
a practical problem.

Cheers,

    Greg

---

---

From: Greg Sidebottom <[email-masked]>
Date: Wed, 26 Sep 2001 15:34:38 -0400

resending - original presumably disappeared into the ether ...

----- Original Message -----
From: "Greg Sidebottom" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 26, 2001 1:18 PM
Subject: Re: M3UA Issue 12 (was Re: M3UA Open Issue Update (Sept 18th))

>[Greg]  I don't think that this issue is intended to limit the message size
over

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 26 Sep 2001 16:52:20 -0500

Greg,

I agree.  Close the issue that part of the issue: there is
no need for artificial limits.

--brian

Greg Sidebottom wrote:                                       (Wed, 26 Sep 2001 13:18:52)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: "Duhoon, Rajiv" <[email-masked]>
Date: Wed, 26 Sep 2001 18:07:24 -0700

Hi Greg,

I agree that at practical level there won't be any 
problems but I feel that we should atleast put limits 
on the sub-parameters (CIC ranges SSN and SI's)
of routing key otherwise as you have also mentioned
that at SGP it may become very difficult to validate all the
combination present in the routing key . This 
approach will definitely help simplifying things as
in case of Affected Point Codes, which definitely
were not as difficult to handle either.

Regarding the issue of defining Registration status/De-registration
Status Tag values, I feel that consistency should be maintained and
Tags values should be defined for these parameters as well.

Thanks,
Rajiv

----- Original Message -----
From: "Greg Sidebottom" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 26, 2001 1:18 PM
Subject: Re: M3UA Issue 12 (was Re: M3UA Open Issue Update (Sept 18th))

over
> close this (part of the) issue without change.  As I mentioned it may not
be

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

---