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

From: "J.Javier Pastor (ML/EEM)" <[email-masked]>
Date: Thu, 15 Jan 2004 10:39:47 +0100

It seems good to me.

Cheers // Javier.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Barry Nagelberg
> Sent: miércoles, 14 de enero de 2004 15:04
> To: SIGTRAN Mailing List
> Subject: RE: [Sigtran] M3UA: More redundant RKM error codes
> 
> 
> Javier,
> 
> Thanks. For the sake of clarity, I suggest the following changes:
> 
> <snip>
> 
> 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 3 scenarios to consider:
> 
> 1. The registration request is an exact duplicate of a registered RK by the sending ASP.
> 2. The registration request partially overlaps a registered RK in the SGP.
> 3. The ASP is requesting to modify a registered RK.
> 
> <snip>
> 
> Barry Nagelberg
> 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > 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,
> >
> > 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
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 15 Jan 2004 03:50:17 -0700

J.Javier,

Sure, just change to:

1. The registration request is an exact duplicate of a registered RK by the sending ASP.
2. The registration request partially overlaps a registered RK in the SGP for the sending ASP.
3. The ASP is requesting to modify a registered RK.

Thanks.

--brian

J.Javier Pastor (ML/EEM) wrote:                                                   (Thu, 15 Jan 2004 10:39:47)

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

---

From: "Barry Nagelberg" <[email-masked]>
Date: Thu, 15 Jan 2004 09:28:03 -0500

Javier,

Oops, sorry - some minor corrections:

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.

I agree with you and Kamesh (and apparently with everyone else except
Brian), that there SHOULD NOT be more than one RK match per AS. This is also
stated in section 1.4.2.2 of the RFC - Routing Key Limitations.

Barry Nagelberg

> From: J.Javier Pastor (ML/EEM) [mailto:[email-masked]]
> Sent: Thursday, January 15, 2004 4:40 AM
> To: 'Barry Nagelberg'; SIGTRAN Mailing List

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 15 Jan 2004 08:03:05 -0700

Barry,

Oh, so now you're going to send an error every time that an ASP
registers for an RK that another ASP has registered for?  Don't
be absurd.

--brian

Barry Nagelberg wrote:                                                               (Thu, 15 Jan 2004 09:28:03)

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

---

From: "Barry Nagelberg" <[email-masked]>
Date: Thu, 15 Jan 2004 10:11:55 -0500

Javier,

Brian is correct. I am wrong. Please use my original suggestion from
yesterday, January 14.

Barry Nagelberg

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, January 15, 2004 10:03 AM
> To: Barry Nagelberg
> Cc: SIGTRAN Mailing List
> Subject: Re: [Sigtran] M3UA: More redundant RKM error codes
>
>
> Barry,
>
> > > > >   |                       Local-RK-Identifier
>         |
> > > > >   \
>         \
> > > > >   /                              ...
>         /
> > > > >   \
>         \
> > > > >   |                       Local-RK-Identifier
>         |
> > > > >   \
>         \
> > > > >   /                              ...
>         /
> > > > >   \
>         \