Subject: RE: [Sigtran] M3UA: More redundant RKM error codes

From: "J.Javier Pastor (ML/EEM)" <[email-masked]>
Date: Wed, 14 Jan 2004 12:36:54 +0100

Hi guys, 

Here we send the new text proposal to clarify this issue according your comments. 

Thanks // Javier.

3.6 Receiving REG for a RK already registered
                                                                      
3.6.1 Description of the problem

The RFC does not clearly specify what the SG should do when it receives a Registration Request for a Routing Key that has already been registered. There are two scenarios to consider: the registration request is a duplicate, it overlaps partially an already registered RK. Also there is a desire to include the possibility of modifying a registered  Routing Key.

3.6.2 Text changes to the document

---------
Old text: (Section 3.6.1)
---------

The format of the Routing Key parameter is as follows.

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                       Local-RK-Identifier                     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  Traffic Mode Type (optional)                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Destination Point Code                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  Network Appearance (optional)                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  Service Indicators (optional)                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Originating Point Code List (optional)           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                   Circuit Range List (optional)               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  \                                                               \
  /                              ...                              /
  \                                                               \
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Destination Point Code                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  Service Indicators (optional)                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Originating Point Code List (optional)           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                   Circuit Range List (optional)               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---------
New text: (Section 3.6.1)
---------

The format of the Routing Key parameter is as follows.

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                       Local-RK-Identifier                     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                   Routing Context (optional)                  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  Traffic Mode Type (optional)                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Destination Point Code                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  Network Appearance (optional)                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  Service Indicators (optional)                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Originating Point Code List (optional)           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                   Circuit Range List (optional)               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  \                                                               \
  /                              ...                              /
  \                                                               \
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Destination Point Code                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  Service Indicators (optional)                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Originating Point Code List (optional)           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                   Circuit Range List (optional)               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---------
Old text: (Section 3.6.2)
---------

Registration Status: 32-bit integer

  The Registration Result Status field indicates the success or the
  reason for failure of a registration request.
  Its values may be:

     0           Successfully Registered
     1           Error - Unknown
     2           Error - Invalid DPC
     3           Error - Invalid Network Appearance
     4           Error - Invalid Routing Key
     5           Error - Permission Denied
     6           Error - Cannot Support Unique Routing
     7           Error - Routing Key not Currently Provisioned
     8           Error - Insufficient Resources
     9           Error - Unsupported RK parameter Field
     10          Error - Unsupported/Invalid Traffic Handling Mode

---------
New text: (Section 3.6.2)
---------

Registration Status: 32-bit integer

  The Registration Result Status field indicates the success or the
  reason for failure of a registration request.
  Its values may be:
     0           Successfully Registered
     1           Error - Unknown
     2           Error - Invalid DPC
     3           Error - Invalid Network Appearance
     4           Error - Invalid Routing Key
     5           Error - Permission Denied
     6           Error - Cannot Support Unique Routing
     7           Error - Routing Key not Currently Provisioned
     8           Error - Insufficient Resources
     9           Error - Unsupported RK parameter Field
     10          Error - Unsupported/Invalid Traffic Handling Mode
     11          Error - Routing Key Change Refused
     12          Error - Routing Key Already Registered

--------- 
Old text: (Section 4.4.1) 
---------

If the SGP determines that a unique Routing Key cannot be created, the SGP returns a Registration Response message to the ASP, with a Registration Status of "Error - "Cannot Support Unique Routing"  An incoming signalling message received at an SGP should not match against more than one Routing Key.

-------- 
New text: (Section 4.4.1) 
---------

If the SGP determines that the requested RK partially, but not exactly, matches an existing RK, and that an incoming signalling message received at an SGP could possibly match both the requested and the existing RK, the SGP returns a Registration Response message to the ASP, with a Registration Status of "Error - "Cannot Support Unique Routing. An incoming signalling message received at an SGP should not match against more than one Routing Key.

If the SGP determines that the received RK was already registered, fully and exactly, either statically or dynamically, by the sending ASP, the SGP returns a Registration Response message to the ASP, containing a Registration Result "Error - Routing Key Already Registered ". This error applies whether the Routing Key is Active or Inactive. For this error code, RC field in Registration Response message MUST be populated with the actual value of RC in SGP corresponding to the specified RK in Registration Request message.

An ASP MAY modify an existing Routing Key by including a Routing Context parameter in the REG REQ.  If the SGP determines that the Routing Context applies to an existing Routing Key the SG MAY adjust the existing Routing Key to match the new information provided in the Routing Key parameter.  A Registration Response "ERR - Routing Key Change Refused" is returned if the SGP does not accept the modification of the Routing Key due to either it does not support the re-registration procedure or the specific RC does not exist. Otherwise if the change is accepted, a Registration Response "Successfully Registered" is returned.

3.6.3 Solution description 

The two cases, RK overlap and RK duplication, have been differentiated and explained in detail. The latter will use a new specific Error Code as defined above. Also the possibility of modification to a Routing Key is included with the addition of a new parameter in the REG REQ message and the corresponding explanation in the procedures section.

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 14 Jan 2004 05:20:04 -0700

J.Javier,

J.Javier Pastor (ML/EEM) wrote:                                                   (Wed, 14 Jan 2004 12:36:54)

--snip--
> If the SGP determines that the requested RK partially, but not exactly,
> matches an existing RK, and that an incoming signalling message received at
> an SGP could possibly match both the requested and the existing RK, the SGP
> returns a Registration Response message to the ASP, with a Registration
> Status of "Error - "Cannot Support Unique Routing. An incoming signalling
> message received at an SGP should not match against more than one Routing
> Key.
> 
--snip--

I think you mean for a given ASP (Association) in the above.  Correct?

It should be mentioned that the "matching" of RKs is done only against other
RKs belonging to the same ASP (Association).

--brian

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

---

From: "Barry Nagelberg" <[email-masked]>
Date: Wed, 14 Jan 2004 08:46:52 -0500

Brian,

No, your suggestion is not correct. Routing keys are independent of ASPs or
associations. I think perhaps you are thinking of the routing context, which
may be unique for each ASP or association.

Barry Nagelberg

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Brian F. G. Bidulock
> Sent: Wednesday, January 14, 2004 7:20 AM
> To: J.Javier Pastor (ML/EEM)
> Cc: SIGTRAN Mailing List; Ken Morneault (E-mail)
> Subject: Re: [Sigtran] M3UA: More redundant RKM error codes
>
>
> J.Javier,
>

---

From: "Barry Nagelberg" <[email-masked]>
Date: Wed, 14 Jan 2004 09:03:47 -0500

Javier,

Thanks. For the sake of clarity, I suggest the following changes:

<snip>

The RFC does not clearly specify what the SG should do when it receives a
Registration Request for a Routing Key that has already been registered.
There are 3 scenarios to consider:

1. The registration request is an exact duplicate of a registered RK.
2. The registration request partially overlaps a registered RK.
3. The ASP is requesting to modify a registered RK.

<snip>

Barry Nagelberg

> J.Javier Pastor (ML/EEM)
> Sent: Wednesday, January 14, 2004 6:37 AM
> To: SIGTRAN Mailing List
> Cc: Ken Morneault (E-mail)
> Subject: RE: [Sigtran] M3UA: More redundant RKM error codes
>
>
> Hi guys,
>
> The RFC does not clearly specify what the SG should do when it
> receives a Registration Request for a Routing Key that has
> already been registered. There are two scenarios to consider: the
> registration request is a duplicate, it overlaps partially an
> already registered RK. Also there is a desire to include the
> possibility of modifying a registered  Routing Key.
>
> If the SGP determines that a unique Routing Key cannot be
> created, the SGP returns a Registration Response message to the
> ASP, with a Registration Status of "Error - "Cannot Support
> Unique Routing"  An incoming signalling message received at an
> SGP should not match against more than one Routing Key.
>
> --------
> If the SGP determines that the requested RK partially, but not
> exactly, matches an existing RK, and that an incoming signalling
> message received at an SGP could possibly match both the
> requested and the existing RK, the SGP returns a Registration
> Response message to the ASP, with a Registration Status of "Error
> - "Cannot Support Unique Routing. An incoming signalling message
> received at an SGP should not match against more than one Routing Key.
>
> If the SGP determines that the received RK was already
> registered, fully and exactly, either statically or dynamically,
> by the sending ASP, the SGP returns a Registration Response
> message to the ASP, containing a Registration Result "Error -
> Routing Key Already Registered ". This error applies whether the
> Routing Key is Active or Inactive. For this error code, RC field
> in Registration Response message MUST be populated with the
> actual value of RC in SGP corresponding to the specified RK in
> Registration Request message.
>
> An ASP MAY modify an existing Routing Key by including a Routing
> Context parameter in the REG REQ.  If the SGP determines that the
> Routing Context applies to an existing Routing Key the SG MAY
> adjust the existing Routing Key to match the new information
> provided in the Routing Key parameter.  A Registration Response
> "ERR - Routing Key Change Refused" is returned if the SGP does
> not accept the modification of the Routing Key due to either it
> does not support the re-registration procedure or the specific RC
> does not exist. Otherwise if the change is accepted, a
> Registration Response "Successfully Registered" is returned.
>
> The two cases, RK overlap and RK duplication, have been
> differentiated and explained in detail. The latter will use a new
> specific Error Code as defined above. Also the possibility of
> modification to a Routing Key is included with the addition of a
> new parameter in the REG REQ message and the corresponding
> explanation in the procedures section.
>