Subject: [Sigtran] correct Error code

From: Dario Filjar <[email-masked]>
Date: Thu, 29 Mar 2007 01:18:52 -0700 (PDT)

Hi,
  what would be the correct error code for the following situation:
  ASP ACTIVE is received at SGP with RC that is statically configured at SGP, but this
  RC (AS) is not defined for particular ASP which has sent the ASP ACTIVE message.
  How SGP should respond?
  thanks in advance!
   
  Best regards, Dario

---------------------------------
Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A.

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

---

From: Aditya <[email-masked]>
Date: Thu, 29 Mar 2007 02:07:05 -0700 (PDT)

Hi Dario,
 The SGP should respond with Error "Invalid Routing Context" to the ASP as the RC in question is not defined/configured for the ASP in question.

Aditya

Dario Filjar <[email-masked]> wrote: Hi,
  what would be the correct error code for the following situation:
  ASP ACTIVE is received at SGP with RC that is statically configured at SGP, but this
  RC (AS) is not defined for particular ASP which has sent the ASP ACTIVE message.
  How SGP should respond?
  thanks in advance!
   
  Best regards, Dario

---------------------------------
Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A._______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---------------------------------------------------------------------------X----------------------------------------------------
 
Don't take life too seriously...
Nobody comes out alive anyway

---------------------------------
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Mar 2007 05:36:43 -0600

Aditya,

Well....  RFC 4666 says:

   The "Invalid Routing Context" error is sent if a message is received
   from a peer with an invalid (unconfigured) Routing Context value.
   For this error, the invalid Routing Context(s) MUST be included in
   the Error message.

In this case, the Routing Context value is configured.

Also, RFC 4666 says:

   - If the RC parameter is included in the ASP Active message and the
     corresponding RK has been previously defined (by either static
     configuration or dynamic registration), the peer node MUST respond
     with an ASP Active Ack message.  If for any local reason (e.g.,
     management lockout) the SGP responds to an ASP Active message with
     an Error message with reason "Refused Management Blocking".

So, in this case, the corresponding RK is configured by static configuration
and the SGP has two choices: respond with ASP Active Ack, or response with
ERR("Refused Management Blocking").  If the SGP does not wish to permit the
ASP to activate for the AS, the proper error code is "Refused Management
Blocking".

--brian

Aditya wrote:                                      (Thu, 29 Mar 2007 02:07:05)
> 
>    Hi Dario,
>    The SGP should respond with Error "Invalid Routing Context" to the ASP
>    as  the  RC  in  question  is  not  defined/configured  for the ASP in
>    question.
>    Aditya
>    Dario Filjar <[email-masked]> wrote:
> 
>    Hi,
> 
>        ______________________________________________________________
> 
>      [1]Food fight? Enjoy some healthy debate
>      in the [2]Yahoo! Answers Food & Drink
>      Q&A._______________________________________________
>      Sigtran mailing list
>      [email-masked]
>    ----------------------------------------------------------------------
>    -----X----------------------------------------------------
> 
>      _________________________________________________________________
> 
>    [3]Let  Yahoo!  FareChase  search  your  favorite travel sites to find
>    flight and hotel bargains.
> 
> References
> 
>    1. http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=396545367
>    2. http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=396545367
>    3. http://farechase.yahoo.com/promo-generic-14795097;_ylc=X3oDMTFtNW45amVpBF9TAzk3NDA3NTg5BF9zAzI3MTk0ODEEcG9zAzEEc2VjA21haWx0YWdsaW5lBHNsawNxMS0wNw--

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 29 Mar 2007 07:20:34 -0500

Dario,

"Invalid Routing Context" seems as a good choice. The RC is not defined for
that particular peer, i.e. ASP.

   Thanks,
   Tolga

-----Original Message-----
From: Dario Filjar [mailto:[email-masked]]
Sent: Thursday, March 29, 2007 3:19 AM
To: [email-masked]
Subject: [Sigtran] correct Error code

Hi,
what would be the correct error code for the following situation:
ASP ACTIVE is received at SGP with RC that is statically configured at SGP,
but this
RC (AS) is not defined for particular ASP which has sent the ASP ACTIVE
message.
How SGP should respond?
thanks in advance!

Best regards, Dario

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Mar 2007 06:37:42 -0600

Tolga,

But that conflicts with the MUST requirementin RFC 4666.

--brian

Tolga Asveren wrote:                                                                 (Thu, 29 Mar 2007 07:20:34)

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

---

From: Aditya <[email-masked]>
Date: Thu, 29 Mar 2007 05:53:59 -0700 (PDT)

Brian, 
 RFC 4666 mentions Invalid Routing Context to be sent if a message is received from a peer with an invalid(unconfigured) Routing Context value. Your analysis makes me think that only unconfigured RC is to be treated as Invalid. Isnt the RC invalid in the example mentioned below.
 
 I may be wrong but sending ERR management Locked message somehow does not inform the peer that there is something wrong at its end. IMHO, "Invalid Routing Context" seems like an appropriate message, since the RC is INVALID in this case. The RC being configured does not take away from the fact that it is invalid.
 
 Does RFC 4666 state anywhere that only unconfigured RC's are to be treated as Invalid? I mean, does it define Invalid RC in any sense.
 
 Aditya

"Brian F. G. Bidulock" <[email-masked]> wrote: Aditya,

Well....  RFC 4666 says:

Also, RFC 4666 says:

--brian

>    Dario Filjar  wrote:

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

 
---------------------------------
Expecting? Get great news right away with email Auto-Check.
Try the Yahoo! Mail Beta.

---

From: "Ankit Kumar Sharma" <[email-masked]>
Date: Thu, 29 Mar 2007 14:33:50 +0100

>      an Error message with reason "Refused Management Blocking".

I think RFC is talking about the case in which ASP active contains a VALID
RC value which is configured for the AS, whom this ASP wants to serve, at
peer.

> ASP to activate for the AS, the proper error code is "Refused Management

Error message with "Invalid routing context" ecode seems to be a better
option because it clearly shows the cause.

--brian
> >    ASP ACTIVE is received at SGP with RC that is statically configured
> at
> >    SGP, but this
> >
> >    RC  (AS)  is  not  defined  for  particular ASP which has sent the
> ASP
> >    ACTIVE message.
> >
> >    How SGP should respond?
> >
> >    thanks in advance!
> >
> >
> >
> >    Best regards, Dario
> >    1.
> http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=396545367
> >    2.
> http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=396545367
> >    3.
> http://farechase.yahoo.com/promo-generic-14795097;_ylc=X3oDMTFtNW45amVpBF9TAzk3NDA3NTg5BF9zAzI3MTk0ODEEcG9zAzEEc2VjA21haWx0YWdsaW5lBHNsawNxMS0wNw--
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Mar 2007 07:39:41 -0600

Aditya,

The RC is not invalid: the ASP is merely not permitted to activate for it.
In this case it is management blocked.  The peer should be welcome to
retry, because at some point in the future it might be permitted to activate
for the AS (e.g. the permission might have only been revoked temporarily).
Sending "Invalid Routing Context" would make the peer believe that the
corresponding RK is not provisioned (which it is) and might result in a
dynamic registration attempt (which is inappropriate).

Besides, if "Invalid Routing Context" is returned, it violates the MUST in

--brian

Aditya wrote:                                     (Thu, 29 Mar 2007 05:53:59)
> 
>    Brian,
>    RFC  4666  mentions Invalid Routing Context to be sent if a message is
>    received  from  a  peer  with an invalid(unconfigured) Routing Context
>    value. Your analysis makes me think that only unconfigured RC is to be
>    treated  as  Invalid.  Isnt  the  RC  invalid in the example mentioned
>    below.
>    I  may be wrong but sending ERR management Locked message somehow does
>    not  inform  the  peer that there is something wrong at its end. IMHO,
>    "Invalid Routing Context" seems like an appropriate message, since the
>    RC is INVALID in this case. The RC being configured does not take away
>    from the fact that it is invalid.
>    Does  RFC  4666  state  anywhere that only unconfigured RC's are to be
>    treated as Invalid? I mean, does it define Invalid RC in any sense.
>    Aditya

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Mar 2007 07:42:51 -0600

Ankit,

Ankit Kumar Sharma wrote:                          (Thu, 29 Mar 2007 14:33:50)

>    I  think  RFC is talking about the case in which ASP active contains a
>    VALID  RC value which is configured for the AS, whom this ASP wants to
>    serve, at peer.

The RC value is valid (there is a corresponding RK defined by static
configuration).

> 
>    Error  message  with  "Invalid  routing  context"  ecode seems to be a
>    better option because it clearly shows the cause.

But is forbidden by the RFC in this case.  Besides it is incorrect because
the RC is valid, (just not permitted).

--brian

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

---

From: Andrew Booth <[email-masked]>
Date: Thu, 29 Mar 2007 09:54:49 -0400

Hi,

I agree with Brian.  The RC is not invalid, the SGP is just refusing the
ASP ACTIVE.  Hence "Refused Management Blocking" is appropriate.

As an aside, I think the text of the pertinent paragraph is missing
something.  The meaning is fairly clear, but it should probably read:

If for any local reason the SGP will not act on the ASP ACTIVE request
(e.g., management lockout) the SGP responds to an ASP Active message
with an Error message with reason "Refused Management Blocking".

Andrew

---

From: "Ankit Kumar Sharma" <[email-masked]>
Date: Thu, 29 Mar 2007 15:16:01 +0100

Brian,

> the RC is valid, (just not permitted).

I somewhat agree with you but I still feel that 'valid' and 'configured' are
two different things. If a RC is configured for an AS then it is not valid
for any xyz ASP(which has to serve different AS) to send ASP-ACTIVE with
this RC.
Purpose of any error code is to let the user correct the cause of error
quickly. If i go by your words i.e reply with ecode "..Blocking" then
originator of ASP-AC could think that his message is perfect but for some,
unknown, local reason peer is not allowing this ASP to become active.
Whereas, if we reply with "inv...context" ecode then originator could
quickly check on the RC value to make it's ASP Active.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Mar 2007 08:28:02 -0600

Ankit,

Ankit Kumar Sharma wrote:                   (Thu, 29 Mar 2007 15:16:01)
> 
>    I  somewhat  agree  with  you  but  I  still  feel  that  'valid'  and
>    'configured' are two different things. If a RC is configured for an AS
>    then  it is not valid for any xyz ASP(which has to serve different AS)
>    to send ASP-ACTIVE with this RC.

The paragraph with the "MUST" in it does not agree with you.  For the
supplied RC, if a "corresponding RK has been previously defined (by
either static configuration  or  dynamic  registration)" then you are
prohibited from sending ERR("Invalid Routing Context").  This means that
'valid' and 'configured' are the same thing.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 29 Mar 2007 10:28:33 -0500

If RC is configured statically per ASP on SGP, I wouldn't think it is wrong
to say that it is invalid for that particular ASP. The peers are ASPs and
SGPs in that relationship.

   Thanks,
   Tolga

> From: Andrew Booth [mailto:[email-masked]]
> Sent: Thursday, March 29, 2007 8:55 AM
> To: Aditya; [email-masked]
> Subject: Re: [Sigtran] correct Error code
>
>
> Hi,
>

---

From: Aditya <[email-masked]>
Date: Thu, 29 Mar 2007 12:04:56 -0700 (PDT)

Hi Brian,
Although, I agree with your analysis in principle, I still feel sending ERR message with cause "Management Locked" does not provide a true picture in all cases. It might work in the case you described, but what about a case where configuration of RC's mapping to AS is wrong by mistake.

The peer will never come to know that the configuration at its end is wrong and will be made to believe that somethings not right at the other end. 

An error message with cause "invalid Routing context" seems more appropriate then. 

Aditya

Tolga Asveren <[email-masked]> wrote: If RC is configured statically per ASP on SGP, I wouldn't think it is wrong
to say that it is invalid for that particular ASP. The peers are ASPs and
SGPs in that relationship.

   Thanks,
   Tolga

 

---------------------------------
We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list.

---

From: Andrew Booth <[email-masked]>
Date: Thu, 29 Mar 2007 15:32:25 -0400

Hi Tolga,

It's a subtle point about the definitions.  My personal views are
unchanged, but I think this argument is being addressed in the other
branch of this thread.

My intended contribution just that the RFC appears to have some text
missing in one of the critical passages, that could perhaps be addressed
if there is ever another rev of M3UA.

Andrew

Tolga Asveren wrote:
>>> The RC is not invalid: the ASP is merely not permitted to
>>>       
>> activate for it.
>>     
>>> retry, because at some point in the future it might be
>>>       
>> permitted to activate
>>     
>>> for the AS (e.g. the permission might have only been revoked
>>>       
>> temporarily).
>>     
>>> Besides, if "Invalid Routing Context" is returned, it violates
>>>       
>> the MUST in
>>     
>>> this passage:
>>>
>>>
>>>       
>>>>      - If the RC parameter is included in the ASP Active
>>>>         
>> message and the
>>     
>>> Aditya wrote:                                     (Thu, 29 Mar
>>>       
>> 2007 05:53:59)
>>     
>>>>    Brian,
>>>>    RFC  4666  mentions Invalid Routing Context to be sent if a
>>>>         
>> message is
>>     
>>>>    received  from  a  peer  with an invalid(unconfigured)
>>>>         
>> Routing Context
>>     
>>>>    value. Your analysis makes me think that only unconfigured
>>>>         
>> RC is to be
>>     
>>>>    treated  as  Invalid.  Isnt  the  RC  invalid in the
>>>>         
>> example mentioned
>>     
>>>>    below.
>>>>    I  may be wrong but sending ERR management Locked message
>>>>         
>> somehow does
>>     
>>>>    not  inform  the  peer that there is something wrong at its
>>>>         
>> end. IMHO,
>>     
>>>>    "Invalid Routing Context" seems like an appropriate
>>>>         
>> message, since the
>>     
>>>>    RC is INVALID in this case. The RC being configured does
>>>>         
>> not take away
>>     
>>>>    Does  RFC  4666  state  anywhere that only unconfigured
>>>>         
>> RC's are to be
>>

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 29 Mar 2007 14:41:56 -0500

Hi Andrew,

I don't think it is addressed :-). The point I tried to make was, if RC is
configured per ASP, considering RC values for other ASPs as the the "same"
RC doesn't sound correct. For example:

 +-------+   +-------+
 |  ASP1 |   |  ASP2 |
 +------++   ++------+
        |     |
        |     |
        |     |
        |     |
        |     |
       ++-----++
       |  SGP  |
       +-------+
     Configuration for ASP1:
       RC1: DPC=1-1-1, RC=1

     Configuration for ASP2:
       RC2: DPC=2-2-2  RC=1

RC1 and RC2 are using the same "RC" value but they are not referring to the
same RK. Basically, the concept of "RC being defined for some other ASP",
doesn't fit well to the ASP/SGP relationship IMHO, because I would expect RC
to be defined per ASP (at least from protocol semantics perspective,
otherwise how local configuration is entered to the system is something
obviously implementation dependent)

  Thanks,
  Tolga

> Sent: Thursday, March 29, 2007 2:32 PM
> To: Tolga Asveren
> Cc: [email-masked]

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Thu, 29 Mar 2007 15:32:49 -0500 (CDT)

according to your diagram, can u explain the one-to-one relationship
between RC and RK ?

--Samuel

  Alcatel USA, Inc.                  Internet: <userid>@ssd.usa.alcatel.com
  1000 Coit Road, Plano, Texas 75075
  ******* The opinions expressed are not those of Alcatel USA, Inc. *******

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 30 Mar 2007 08:11:33 -0500

Sure. RC is just an agreement on a "name" for a specific routing key between
a SGP and ASP. For messages coming from SS7 side, SGP still does the RK
analysis, selects a suitable ASP and uses the corresponding RC value for
that particular ASP/RK pair. I don't think protocol semantics require RC to
be unique among all peers. This doesn't create any ambiguity. For example
the use of "empty" name, i.e. not using a RC in messages if only a single RK
is used between ASP and SGP, gives a per ASP (or per SGP, depending on
whichever side one is looking from) meaning to "no RC". An SGP can send
messages with no RC to two different ASPs (given that traffic to each
particular ASP belongs to a single RK), referring to different AS.

One could go with the globally unique RC approach, there is nothing wrong
with it. For certain configurations, it could be quite inconvenient from
provisioning point of view though. Consider the following case:

 +--------+   +--------+
 |  ASP1  |   |  ASP2  |
 +------+-+   ++------++
        |      |      |
        |      |      |
       ++------++   +-+------+
       |   SG1  |   |   SG2  |
       +--------+   +--------+

For simplicity I draw SGs as single boxes, but they can consist of multiple
SGPs, similarly each ASP can have multiple replicas. Each ASP and SG in the
diagram is controlled by another organization, SGs by SS7 connectivity
providers and ASPs by operators of application servers/VoIP gateways. Now,
if each box interpretes RC to be unique among all peers it is conneced to,
RC namespace needs to be administrated by some entity. For example, ASP1 and
SG1 use RC=1 for RK:DPC=1-1-1. ASP2 can't use RC=1 for any of its RKs, even
not for the ones it defines only for SG2 (if it wants to keep RC unique
among all of its peers). This really would be  a mess from provisiong point
of view (imagine n number of ASPs and m number of SGs controlled by
different organizations)

  Thanks,
  Tolga

> From: Samuel Dur D. Jeyaseelan [mailto:[email-masked]]
> Sent: Thursday, March 29, 2007 3:33 PM
> To: [email-masked]
> Subject: RE: [Sigtran] correct Error code
>
>