RE: correct Error code
"Tolga Asveren" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
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
> -----Original Message-----
> From: Samuel Dur D. Jeyaseelan [mailto:[email protected]]
> Sent: Thursday, March 29, 2007 3:33 PM
> To: [email protected]
> Subject: RE: [Sigtran] correct Error code
>
>
> 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. *******
>
> On Thu, 29 Mar 2007, Tolga Asveren wrote:
>
> > 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
> >
> >
> >
> > > -----Original Message-----
> > > From: Andrew Booth [mailto:[email protected]]
> > > Sent: Thursday, March 29, 2007 2:32 PM
> > > To: Tolga Asveren
> > > Cc: [email protected]
> > > Subject: Re: [Sigtran] correct Error code
> > >
> > >
> > > 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:
> > > > 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
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Andrew Booth [mailto:[email protected]]
> > > >> Sent: Thursday, March 29, 2007 8:55 AM
> > > >> To: Aditya; [email protected]
> > > >> Subject: Re: [Sigtran] correct Error code
> > > >>
> > > >>
> > > >> 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
> > > >>
> > > >> Brian F. G. Bidulock wrote:
> > > >>
> > > >>> 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
> > > >>
> > > >>> this passage:
> > > >>>
> > > >>>
> > > >>>
> > > >>>> - 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".
> > > >>>>
> > > >>>>
> > > >>> --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
> > > >>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >> _______________________________________________
> > > >> Sigtran mailing list
> > > >> [email protected]
> > > >> https://www1.ietf.org/mailman/listinfo/sigtran
> > > >>
> > > >
> > > >
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email protected]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > >
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
>
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran