Subject: RE: RE: [Sigtran] M3UA: ASP to SGP communication

From: "TOLGA ASVEREN" <[email-masked]>
Date: Tue, 28 Jan 2003 10:42:30 +0200

Jolan,

> -----Original Message-----
> From: "Jolan Evans" <[email-masked]>
> Sent: Tuesday, January 28, 2003 10:17 AM
> To: "Sigtran" <[email-masked]>
> Cc: <[email-masked]>
> Subject: RE: [Sigtran] M3UA: ASP to SGP communication (Sent by
> [email-masked] on behalf of "Jolan Evans"
> <[email-masked]> )
>
>
> I would like to raise a few issues regarding your procedures below for
> ASP to SGP routing. I know this discussion took places a
> while ago, but
> it has taken me some time to come up to speed with the RFC as I have
> been busy on other things until recently.
>
> Please note that I have inserted "M3UA" into the subject line of the
> original email.
>
>
>
> 1. Nomenclature
> AsPc: Point code of an AS. In defining routing keys, the RFC uses DPC
> for this term as it takes the SG's frame of reference.
> RemotePc: Point code of an SS7 MTP entity with which an AS
> communicates
> via an SG, or directly in the case of IPSP-IPSP communication. In
> defining routing keys, the RFC uses OPC for this term as it takes the
> SG's frame of reference again.
>
>
>
> 2. Background Assumptions
> As per Brian's introduction, we assume that zero or more
> MTP-User's are
> bound to an MTP-SAP. The MTP-SAP exists in a particular MTP-Network,
> which has a particular MTP protocol variant. An SG is
> associated with a
> single MTP-Network. A RK is defined as in the RFC, but, for
> clarity, is
> independent of any SG and associated with a single MTP-Network. An
> SgRouteSet is uniquely defined by an RK, an SG and an MTP-SAP (the RK
> and SG must be both associated with the same MTP-Network) and also
> specifies the network appearance for the MTP-Network to be
> used with the
> SG and the RC of each SGP in the SG. Therefore, an SgRouteSet is
> implicitly associated with a single MTP-Network. An MTP-SAP is
> associated with zero or more SgRouteSet's and therefore an MTP-SAP is
> associated with zero or more RKs. In contrast, it appears that Brian
> assumes that an MTP-SAP can only be associated with one RK. Given this
> extension, we have the following requirement.
>
>
>
> 3. Routing Keys Requirements to Support Unique SS7 Destination Status
> Let RemotePcSet(Rk) be the set of RemotePc's reachable via the SG from
> the ASP where the RK is defined.
> Consider any two SgRouteSet's SgRsA and SgRsA which are
> associated with
> the same MTP-SAP.
> Let the routing key of SgRsA and SgRsB be RkA and RkB respectively.
> If the intersection of RemotePcSet(RkA) and RemotePcSet(RkB)
> is non-nil
> then the routing keys MUST be identical in every respect apart from
> their RemotePcSet.
> If this wasn't the case, an ASP could never indicate an
> MTP-RESUME to an
> MTP-USER because an MTP-RESUME can only specify a RemotePc
> and no other
> SS7 element. I assume here for simplicity that every MTP-User of a
> MTP-SAP must be given the same MTP status (i.e. different MTP-Users of
> the same MTP-SAP cannot be given different MTP-Status indications
> depending on what traffic they have requested).
>
> Here's a concrete example of why this is so. Consider an ASP with the
> following routing keys:
> RkA: MTP-Network=NetworkA, RemotePcSet={X}, AsPcSet={A}
> RkB: MTP-Network=NetworkA, RemotePcSet={X}, AsPcSet={B}
> RkC: MTP-Network=NetworkA, RemotePcSet={Y}, SiSet={M}
> RkD: MTP-Network=NetworkA, RemotePcSet={Y}, SiSet={N}
>
> Assume that RkA and RkB were both active in SgpA and SgpB respectively
> and are associated with the same MTP-SAP, but different SGs.
> Also assume
> that a DAVA has been received for RemotePc=X from SgpA after
> a DUNA from
> SgpB for the same RemotePc. We might consider generating an MTP-Resume
> to all the MTP-Users of the MTP-SAP for RemotePc X. However, if an
> MTP-User requests an MTP-Transfer with an AsPc of B then SgpB
> may not be
> able to transfer it as indicated by the DUNA it sent the ASP.
>
> The same explanation applies to RkC and RkD.
>
> In practice this requirement probably won't cause too many headaches
> because it is likely that there would be two different MTP-Users, one
> using only RkA/RkC and the other using only RkB/RkD. In this case, we
> can simply create two MTP-SAPs in the same MTP-Network and associate
> each routing key with a different MTP-SAP. Of course, this
> would require
> the M3UA implementation to support more than one MTP-SAP per
> MTP-Network, which would be extra work obviously.
[TOLGA] IMO there is no problem. It might be extra work but people are free
to support such a configuration or not.
>
>
>
> 4. ASP-SGP Routing should use SS7 Destination Availability/Restricted
> Status on a per-SGP rather than a per-SG basis.
>
> I believe your ASP-SGP procedures should be amended (I only amend the
> multiple SG case as the single SG case is a special case of
> the former)
> as follows:
>
> Change:
> "This routing information is updated by collecting DUNA/DAVA/DRST
> messages received from (any of the SGP in) the SG."
> To:
> "This routing information is updated by collecting DUNA/DAVA/DRST
> information on a per-(SGP,destination) basis. An SG is
> considered to be
> available and unrestricted for a particular destination if
> any SGP in it
> is available and unrestricted for that destination. Otherwise
> if this is
> not he case, then an SG is considered to be restricted for a
> particular
> destination if there is at least one SGP in the SG restricted for that
> destination. Otherwise if this is not the case, the SG is
> considered to
> be prohibited for that destination."
>
> The RFC is not particular clear on this point. In section 1.4.1 para 3
> it states that "MTP3 routeset, SPMC and remote AS/ASP states
> of each SGP
> SHOULD be coordinated across all the SGPs". However, this
> uses "SHOULD"
> which implies it is only recommended and it also doesn't specifically
> state that SS7 destination availability, restriction and congestion
> status ("SS7 destination status" for short) should be
> coordinated across
> all SGPs. I don't think that "MTP3 routeset" necessarily implies SS7
> destination status. Also, in section 1.3.2.5 1.4.2.5 it suggests in
> should be on a per-SGP basis. Section 4.5.2.2 uses the word "SG" but
> also uses the term "affected route(s)". Section 1.3.2.5 and section
> 1.4.2.5 suggest the word "route" refers to an SGP and not an
> SG. Hence,
> given the ambiguity of section 4.5.2.2 I think that route can be
> considered to refer to an SGP.
>
> A configuration where per-SGP SS7 destination status is
> necessary is as
> follows. Consider an SEP SG which has two SGP's acting as a redundant
> pair. Each SGP has it's own link set to a particular STP. While in
> section 1.4.1 para 3 it states that "Rerouting of traffic between the
> SGPs MAY also be supported", it uses "MAY" and hence this is optional.
> If one link set fails but not the other, one SGP will be able to reach
> the SS7 network but not the other if rerouting between SGPs is not
> supported or the rerouting link has also failed. Hence, it would be
> possible for one SGP to send a DUNA for a particular
> destination but not
> the other.
[TOLGA] Again I don´t see a problem. I only agree that "MAY" in the
sentence you refer was better changed to a "SHOULD". If somebody thinks
that creating a unique layer3 view among SGPs belonging to the same SG is
hard to implement/not necessary, then it is possible to have SGs consisting
of one SGP, without violating the protocol. In that case, SSNM will be
received separetly from each SGP, because they belong to different SGs.
>
>
> Your feedback would be appreciated.
>
> Jolan.
>
>
> --
> Jolan Evans
> Open Telecommunications
> [email-masked]
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian F. G. Bidulock
> Sent: Tuesday, 8 October 2002 17:47
> To: Srikanth Yandapalli
> Cc: [email-masked]
> Subject: Re: [Sigtran] ASP to SGP communication
>
> Srikanth,
>
> Srikanth Yandapalli wrote:               (Tue, 08 Oct 2002 12:03:52)
> >
> >    I am late entrant to this group.I am quite sure all this should
> have
> >    been discussed and I am sorry about this.
>
> Welcome.
>
> >
> >    In the context of a single ASP in communication with
> multiple SGPs,
> >    how should the routing of a MTP_DATA_REQ take place at the ASP?
>
> I assume you are talking about M3UA?  As we are dealing with 5 or more
> UAs
> now, in the future it would be helpful to add M3UA (or
> whichever) to the
> subject line.
>
> >
> >    approach 1:
> >
> >    We may find out the  RK and find out the SGP list that the RK is
> >    active on and choose one SGP for sending the message based
> >    on congestion level and also whether we have received any DRST
> >    message from any of the SGPs.
>
> This approach is applicable to multiple SGs, but not to multiple SGPs
> within a
> single SG.
>
> >    approach 2:
> >
> >    An SGP can also be viewed as providing route to a set of DPCs
> >    and the routing can be based on the DPC for the message alone.
> >    This approach is reduces the complexity but adds a situation
> >    where the RK may not be active on that association. And also is
> >    is mandatory to send RC on this association and if so what could
> >    the SGP make out of the RC?
>
> RC should be coordinated and the same across multiple SGPs
> within an SG.
>
> >
> >    Is there a preferred approach to this issue?
> >
>
> Typically, the logic can be something like this: (but there
> are several
> other
> schools of thought):
>
> Single SG case: (multiple SGs is more complicated)
>
>   MTP-TRANSFER request is issued by an MTP-User.  The
> MTP-User is bound
> to an
>   MTP-SAP.  The MTP-SAP is associated with an AS/RC/RK.
> There is a pool
> of
>   SGPs on an SG for which the AS/RC/RK is active.  The AS may have
> received
>   MTP-PAUSE/RESUME/STATUS indications from the SG and may choose to
> honor that
>   information or not.  If the ASP chooses not to honor this
> information
> it can
>   blindly send messages to the SGP and rely upon a DUNA/SCON response
> from the
>   SGP later.
>
>   Selection of an SGP within an SG is based on the traffic
> mode for the
> SGP.
>   This traffic mode is not managed by M3UA, however, M3UA provides for
>   distribution of traffic over SGP based on any of the
> methods described
> for
>   ASPs (active/standby, load-share, broadcast).  A typical method is
>   load-share based on SLS.  In this scheme, using the SLS in the
> MTP-TRANSFER
>   request, the ASP selects load-shares traffic over the available SGP.
>
> Multiple SG case:
>
>   In the more complicated multiple SG case, the ASP must
> first select an
> SG
>   before it selects an SGP within the SG.  The ASP must maintain some
>   additional routing information to be able to properly select an SG.
> This
>   routing information is updated by collecting DUNA/DAVA/DRST messages
>   received from (any of the SGP in) the SG.  To select the
> outgoing SG,
> the
>   ASP must examine the destination of the MTP-TRANSFER request.
>
>   (If the SG has no SGP active for the AS/RC/RK, all
> destinations can be
>   considered prohibited).
>
>   If the destination is available and unrestricted for
> several SGs, the
> ASP
>   should select an SG on a load-sharing basis (based on SLS) and then
> select
>   an active SGP within the SG on the basis of the traffic mode for the
> SG.
>
>   If some SG are restricted for the specified destination (based on
> received
>   DRST messages from the SG), the ASP should load-share across the
> available
>   unrestricted SGs.  If all SGs are restricted for a given
> destination,
> the
>   ASP should load-share across the available SGs and ignore the
> restricted
>   status.
>
>   If some SG are prohibited for the specified destination (based on
> received
>   DUNA messages from the SG), the ASP should load-share across the
> available
>   non-prohibited SGs.  If all SGs are prohibited for a given
> destination
> (or
>   no SGP is active for the AS/RC/RK in any SG), the ASP should respond
> to the
>   MTP-User with an MTP-PAUSE in accordance with the style of the
> MTP-User
>   interface (ITU-T and ANSI differ here).
>
> Properly selecting SGs requires that the ASP maintain the
> DUNA/DAVA/DRST
> information for each destination received from any SGP in an SG, on a
> per-SG
> basis.  This is the same as MTP Level 3 ROUTE status.  However, SCON
> information should only be maintained on a per-destination basis (and
> not
> per-SG).  This is the same as MTP Level 3 ROUTESET status.
>
> Note that, in general, it is a bad idea to consider congestion (SCON)
> when
> selecting an SG.  SCON does not necessarily indicate
> congestion at an SG
> or on
> a path to an SG, but indicates congestion at the affected
> destination or
> somewhere (perhaps distant) in the SS7 network.  SCON is
> ROUTESET-specific
> (applies to the destination), whereas DUNA/DAVA/DRST is ROUTE-specific
> (applies to the destination and path).  SCON should only be used to
> determine
> whether a message should be dropped completely and an MTP-STATUS
> returned to
> the MTP-User according to the style of the MTP-User interface
> (ITU-T and
> ANSI
> differ here again).
>
> So, to summarize:  on behalf of the AS/RC/RK/MTP-User, the ASP
> determines
> whether to send a message based on SCON received for the specified
> destination, then selects an SG based on DUNA/DAVA/DRST
> received for the
> specified destination and load-shares based on SLS across the eligible
> SGs.
> Once an SG is selected, an active SGP (active for the AS/RC/RK) is
> selected
> within the SG based on the traffic mode of the SG (active/standby,
> load-share,
> broadcast: but typically load-share on SLS).
>
> As I said, there are other schools of thought, but that is my
> understanding.
>
> --brian
>
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> Jolan,

> -----Original Message-----
> From: "Jolan Evans" <[email-masked]>
> Sent: Tuesday, January 28, 2003 10:17 AM
> To: "Sigtran" <[email-masked]>
> Cc: <[email-masked]>
> Subject: RE: [Sigtran] M3UA: ASP to SGP communication (Sent by
> [email-masked] on behalf of "Jolan Evans"
> <[email-masked]> )
>
>
> I would like to raise a few issues regarding your procedures below for
> ASP to SGP routing. I know this discussion took places a
> while ago, but
> it has taken me some time to come up to speed with the RFC as I have
> been busy on other things until recently.
>
> Please note that I have inserted "M3UA" into the subject line of the
> original email.
>
>
>
> 1. Nomenclature
> AsPc: Point code of an AS. In defining routing keys, the RFC uses DPC
> for this term as it takes the SG's frame of reference.
> RemotePc: Point code of an SS7 MTP entity with which an AS
> communicates
> via an SG, or directly in the case of IPSP-IPSP communication. In
> defining routing keys, the RFC uses OPC for this term as it takes the
> SG's frame of reference again.
>
>
>
> 2. Background Assumptions
> As per Brian's introduction, we assume that zero or more
> MTP-User's are
> bound to an MTP-SAP. The MTP-SAP exists in a particular MTP-Network,
> which has a particular MTP protocol variant. An SG is
> associated with a
> single MTP-Network. A RK is defined as in the RFC, but, for
> clarity, is
> independent of any SG and associated with a single MTP-Network. An
> SgRouteSet is uniquely defined by an RK, an SG and an MTP-SAP (the RK
> and SG must be both associated with the same MTP-Network) and also
> specifies the network appearance for the MTP-Network to be
> used with the
> SG and the RC of each SGP in the SG. Therefore, an SgRouteSet is
> implicitly associated with a single MTP-Network. An MTP-SAP is
> associated with zero or more SgRouteSet's and therefore an MTP-SAP is
> associated with zero or more RKs. In contrast, it appears that Brian
> assumes that an MTP-SAP can only be associated with one RK. Given this
> extension, we have the following requirement.
>
>
>
> 3. Routing Keys Requirements to Support Unique SS7 Destination Status
> Let RemotePcSet(Rk) be the set of RemotePc's reachable via the SG from
> the ASP where the RK is defined.
> Consider any two SgRouteSet's SgRsA and SgRsA which are
> associated with
> the same MTP-SAP.
> Let the routing key of SgRsA and SgRsB be RkA and RkB respectively.
> If the intersection of RemotePcSet(RkA) and RemotePcSet(RkB)
> is non-nil
> then the routing keys MUST be identical in every respect apart from
> their RemotePcSet.
> If this wasn't the case, an ASP could never indicate an
> MTP-RESUME to an
> MTP-USER because an MTP-RESUME can only specify a RemotePc
> and no other
> SS7 element. I assume here for simplicity that every MTP-User of a
> MTP-SAP must be given the same MTP status (i.e. different MTP-Users of
> the same MTP-SAP cannot be given different MTP-Status indications
> depending on what traffic they have requested).
>
> Here's a concrete example of why this is so. Consider an ASP with the
> following routing keys:
> RkA: MTP-Network=NetworkA, RemotePcSet={X}, AsPcSet={A}
> RkB: MTP-Network=NetworkA, RemotePcSet={X}, AsPcSet={B}
> RkC: MTP-Network=NetworkA, RemotePcSet={Y}, SiSet={M}
> RkD: MTP-Network=NetworkA, RemotePcSet={Y}, SiSet={N}
>
> Assume that RkA and RkB were both active in SgpA and SgpB respectively
> and are associated with the same MTP-SAP, but different SGs.
> Also assume
> that a DAVA has been received for RemotePc=X from SgpA after
> a DUNA from
> SgpB for the same RemotePc. We might consider generating an MTP-Resume
> to all the MTP-Users of the MTP-SAP for RemotePc X. However, if an
> MTP-User requests an MTP-Transfer with an AsPc of B then SgpB
> may not be
> able to transfer it as indicated by the DUNA it sent the ASP.
>
> The same explanation applies to RkC and RkD.
>
> In practice this requirement probably won't cause too many headaches
> because it is likely that there would be two different MTP-Users, one
> using only RkA/RkC and the other using only RkB/RkD. In this case, we
> can simply create two MTP-SAPs in the same MTP-Network and associate
> each routing key with a different MTP-SAP. Of course, this
> would require
> the M3UA implementation to support more than one MTP-SAP per
> MTP-Network, which would be extra work obviously.
[TOLGA] IMO there is no problem. It might be extra work but people are free
to support such a configuration or not. In your example, most probably
there should be two different user part entities processing messages for
RkA and RkB respectively. Each of them will only primitives related with
them, i.e. primitives which are caused by messages arrived for the
corresponding RK.
(BTW your RkC and RkD are invalid because they don´t contain DPC field)
>
>
>
> 4. ASP-SGP Routing should use SS7 Destination Availability/Restricted
> Status on a per-SGP rather than a per-SG basis.
>
> I believe your ASP-SGP procedures should be amended (I only amend the
> multiple SG case as the single SG case is a special case of
> the former)
> as follows:
>
> Change:
> "This routing information is updated by collecting DUNA/DAVA/DRST
> messages received from (any of the SGP in) the SG."
> To:
> "This routing information is updated by collecting DUNA/DAVA/DRST
> information on a per-(SGP,destination) basis. An SG is
> considered to be
> available and unrestricted for a particular destination if
> any SGP in it
> is available and unrestricted for that destination. Otherwise
> if this is
> not he case, then an SG is considered to be restricted for a
> particular
> destination if there is at least one SGP in the SG restricted for that
> destination. Otherwise if this is not the case, the SG is
> considered to
> be prohibited for that destination."
>
> The RFC is not particular clear on this point. In section 1.4.1 para 3
> it states that "MTP3 routeset, SPMC and remote AS/ASP states
> of each SGP
> SHOULD be coordinated across all the SGPs". However, this
> uses "SHOULD"
> which implies it is only recommended and it also doesn't specifically
> state that SS7 destination availability, restriction and congestion
> status ("SS7 destination status" for short) should be
> coordinated across
> all SGPs. I don't think that "MTP3 routeset" necessarily implies SS7
> destination status. Also, in section 1.3.2.5 1.4.2.5 it suggests in
> should be on a per-SGP basis. Section 4.5.2.2 uses the word "SG" but
> also uses the term "affected route(s)". Section 1.3.2.5 and section
> 1.4.2.5 suggest the word "route" refers to an SGP and not an
> SG. Hence,
> given the ambiguity of section 4.5.2.2 I think that route can be
> considered to refer to an SGP.
>
> A configuration where per-SGP SS7 destination status is
> necessary is as
> follows. Consider an SEP SG which has two SGP's acting as a redundant
> pair. Each SGP has it's own link set to a particular STP. While in
> section 1.4.1 para 3 it states that "Rerouting of traffic between the
> SGPs MAY also be supported", it uses "MAY" and hence this is optional.
> If one link set fails but not the other, one SGP will be able to reach
> the SS7 network but not the other if rerouting between SGPs is not
> supported or the rerouting link has also failed. Hence, it would be
> possible for one SGP to send a DUNA for a particular
> destination but not
> the other.
[TOLGA] Again I don´t see a problem. I only agree that "MAY" in the
sentence you refer was better changed to a "SHOULD". If somebody thinks
that creating a unique layer3 view among SGPs belonging to the same SG is
hard to implement/not necessary, then it is possible to have SGs consisting
of one SGP, without violating the protocol. In that case, SSNM will be
received separetly from each SGP, because they belong to different SGs.
>
>
> Your feedback would be appreciated.
>
> Jolan.
>
>
> --
> Jolan Evans
> Open Telecommunications
> [email-masked]
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian F. G. Bidulock
> Sent: Tuesday, 8 October 2002 17:47
> To: Srikanth Yandapalli
> Cc: [email-masked]
> Subject: Re: [Sigtran] ASP to SGP communication
>
> Srikanth,
>
> Srikanth Yandapalli wrote:               (Tue, 08 Oct 2002 12:03:52)
> >
> >    I am late entrant to this group.I am quite sure all this should
> have
> >    been discussed and I am sorry about this.
>
> Welcome.
>
> >
> >    In the context of a single ASP in communication with
> multiple SGPs,
> >    how should the routing of a MTP_DATA_REQ take place at the ASP?
>
> I assume you are talking about M3UA?  As we are dealing with 5 or more
> UAs
> now, in the future it would be helpful to add M3UA (or
> whichever) to the
> subject line.
>
> >
> >    approach 1:
> >
> >    We may find out the  RK and find out the SGP list that the RK is
> >    active on and choose one SGP for sending the message based
> >    on congestion level and also whether we have received any DRST
> >    message from any of the SGPs.
>
> This approach is applicable to multiple SGs, but not to multiple SGPs
> within a
> single SG.
>
> >    approach 2:
> >
> >    An SGP can also be viewed as providing route to a set of DPCs
> >    and the routing can be based on the DPC for the message alone.
> >    This approach is reduces the complexity but adds a situation
> >    where the RK may not be active on that association. And also is
> >    is mandatory to send RC on this association and if so what could
> >    the SGP make out of the RC?
>
> RC should be coordinated and the same across multiple SGPs
> within an SG.
>
> >
> >    Is there a preferred approach to this issue?
> >
>
> Typically, the logic can be something like this: (but there
> are several
> other
> schools of thought):
>
> Single SG case: (multiple SGs is more complicated)
>
>   MTP-TRANSFER request is issued by an MTP-User.  The
> MTP-User is bound
> to an
>   MTP-SAP.  The MTP-SAP is associated with an AS/RC/RK.
> There is a pool
> of
>   SGPs on an SG for which the AS/RC/RK is active.  The AS may have
> received
>   MTP-PAUSE/RESUME/STATUS indications from the SG and may choose to
> honor that
>   information or not.  If the ASP chooses not to honor this
> information
> it can
>   blindly send messages to the SGP and rely upon a DUNA/SCON response
> from the
>   SGP later.
>
>   Selection of an SGP within an SG is based on the traffic
> mode for the
> SGP.
>   This traffic mode is not managed by M3UA, however, M3UA provides for
>   distribution of traffic over SGP based on any of the
> methods described
> for
>   ASPs (active/standby, load-share, broadcast).  A typical method is
>   load-share based on SLS.  In this scheme, using the SLS in the
> MTP-TRANSFER
>   request, the ASP selects load-shares traffic over the available SGP.
>
> Multiple SG case:
>
>   In the more complicated multiple SG case, the ASP must
> first select an
> SG
>   before it selects an SGP within the SG.  The ASP must maintain some
>   additional routing information to be able to properly select an SG.
> This
>   routing information is updated by collecting DUNA/DAVA/DRST messages
>   received from (any of the SGP in) the SG.  To select the
> outgoing SG,
> the
>   ASP must examine the destination of the MTP-TRANSFER request.
>
>   (If the SG has no SGP active for the AS/RC/RK, all
> destinations can be
>   considered prohibited).
>
>   If the destination is available and unrestricted for
> several SGs, the
> ASP
>   should select an SG on a load-sharing basis (based on SLS) and then
> select
>   an active SGP within the SG on the basis of the traffic mode for the
> SG.
>
>   If some SG are restricted for the specified destination (based on
> received
>   DRST messages from the SG), the ASP should load-share across the
> available
>   unrestricted SGs.  If all SGs are restricted for a given
> destination,
> the
>   ASP should load-share across the available SGs and ignore the
> restricted
>   status.
>
>   If some SG are prohibited for the specified destination (based on
> received
>   DUNA messages from the SG), the ASP should load-share across the
> available
>   non-prohibited SGs.  If all SGs are prohibited for a given
> destination
> (or
>   no SGP is active for the AS/RC/RK in any SG), the ASP should respond
> to the
>   MTP-User with an MTP-PAUSE in accordance with the style of the
> MTP-User
>   interface (ITU-T and ANSI differ here).
>
> Properly selecting SGs requires that the ASP maintain the
> DUNA/DAVA/DRST
> information for each destination received from any SGP in an SG, on a
> per-SG
> basis.  This is the same as MTP Level 3 ROUTE status.  However, SCON
> information should only be maintained on a per-destination basis (and
> not
> per-SG).  This is the same as MTP Level 3 ROUTESET status.
>
> Note that, in general, it is a bad idea to consider congestion (SCON)
> when
> selecting an SG.  SCON does not necessarily indicate
> congestion at an SG
> or on
> a path to an SG, but indicates congestion at the affected
> destination or
> somewhere (perhaps distant) in the SS7 network.  SCON is
> ROUTESET-specific
> (applies to the destination), whereas DUNA/DAVA/DRST is ROUTE-specific
> (applies to the destination and path).  SCON should only be used to
> determine
> whether a message should be dropped completely and an MTP-STATUS
> returned to
> the MTP-User according to the style of the MTP-User interface
> (ITU-T and
> ANSI
> differ here again).
>
> So, to summarize:  on behalf of the AS/RC/RK/MTP-User, the ASP
> determines
> whether to send a message based on SCON received for the specified
> destination, then selects an SG based on DUNA/DAVA/DRST
> received for the
> specified destination and load-shares based on SLS across the eligible
> SGs.
> Once an SG is selected, an active SGP (active for the AS/RC/RK) is
> selected
> within the SG based on the traffic mode of the SG (active/standby,
> load-share,
> broadcast: but typically load-share on SLS).
>
> As I said, there are other schools of thought, but that is my
> understanding.
>
> --brian
>
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> Jolan,

> -----Original Message-----
> From: "Jolan Evans" <[email-masked]>
> Sent: Tuesday, January 28, 2003 10:17 AM
> To: "Sigtran" <[email-masked]>
> Cc: <[email-masked]>
> Subject: RE: [Sigtran] M3UA: ASP to SGP communication (Sent by
> [email-masked] on behalf of "Jolan Evans"
> <[email-masked]> )
>
>
> I would like to raise a few issues regarding your procedures below for
> ASP to SGP routing. I know this discussion took places a
> while ago, but
> it has taken me some time to come up to speed with the RFC as I have
> been busy on other things until recently.
>
> Please note that I have inserted "M3UA" into the subject line of the
> original email.
>
>
>
> 1. Nomenclature
> AsPc: Point code of an AS. In defining routing keys, the RFC uses DPC
> for this term as it takes the SG's frame of reference.
> RemotePc: Point code of an SS7 MTP entity with which an AS
> communicates
> via an SG, or directly in the case of IPSP-IPSP communication. In
> defining routing keys, the RFC uses OPC for this term as it takes the
> SG's frame of reference again.
>
>
>
> 2. Background Assumptions
> As per Brian's introduction, we assume that zero or more
> MTP-User's are
> bound to an MTP-SAP. The MTP-SAP exists in a particular MTP-Network,
> which has a particular MTP protocol variant. An SG is
> associated with a
> single MTP-Network. A RK is defined as in the RFC, but, for
> clarity, is
> independent of any SG and associated with a single MTP-Network. An
> SgRouteSet is uniquely defined by an RK, an SG and an MTP-SAP (the RK
> and SG must be both associated with the same MTP-Network) and also
> specifies the network appearance for the MTP-Network to be
> used with the
> SG and the RC of each SGP in the SG. Therefore, an SgRouteSet is
> implicitly associated with a single MTP-Network. An MTP-SAP is
> associated with zero or more SgRouteSet's and therefore an MTP-SAP is
> associated with zero or more RKs. In contrast, it appears that Brian
> assumes that an MTP-SAP can only be associated with one RK. Given this
> extension, we have the following requirement.
>
>
>
> 3. Routing Keys Requirements to Support Unique SS7 Destination Status
> Let RemotePcSet(Rk) be the set of RemotePc's reachable via the SG from
> the ASP where the RK is defined.
> Consider any two SgRouteSet's SgRsA and SgRsA which are
> associated with
> the same MTP-SAP.
> Let the routing key of SgRsA and SgRsB be RkA and RkB respectively.
> If the intersection of RemotePcSet(RkA) and RemotePcSet(RkB)
> is non-nil
> then the routing keys MUST be identical in every respect apart from
> their RemotePcSet.
> If this wasn't the case, an ASP could never indicate an
> MTP-RESUME to an
> MTP-USER because an MTP-RESUME can only specify a RemotePc
> and no other
> SS7 element. I assume here for simplicity that every MTP-User of a
> MTP-SAP must be given the same MTP status (i.e. different MTP-Users of
> the same MTP-SAP cannot be given different MTP-Status indications
> depending on what traffic they have requested).
>
> Here's a concrete example of why this is so. Consider an ASP with the
> following routing keys:
> RkA: MTP-Network=NetworkA, RemotePcSet={X}, AsPcSet={A}
> RkB: MTP-Network=NetworkA, RemotePcSet={X}, AsPcSet={B}
> RkC: MTP-Network=NetworkA, RemotePcSet={Y}, SiSet={M}
> RkD: MTP-Network=NetworkA, RemotePcSet={Y}, SiSet={N}
>
> Assume that RkA and RkB were both active in SgpA and SgpB respectively
> and are associated with the same MTP-SAP, but different SGs.
> Also assume
> that a DAVA has been received for RemotePc=X from SgpA after
> a DUNA from
> SgpB for the same RemotePc. We might consider generating an MTP-Resume
> to all the MTP-Users of the MTP-SAP for RemotePc X. However, if an
> MTP-User requests an MTP-Transfer with an AsPc of B then SgpB
> may not be
> able to transfer it as indicated by the DUNA it sent the ASP.
>
> The same explanation applies to RkC and RkD.
>
> In practice this requirement probably won't cause too many headaches
> because it is likely that there would be two different MTP-Users, one
> using only RkA/RkC and the other using only RkB/RkD. In this case, we
> can simply create two MTP-SAPs in the same MTP-Network and associate
> each routing key with a different MTP-SAP. Of course, this
> would require
> the M3UA implementation to support more than one MTP-SAP per
> MTP-Network, which would be extra work obviously.
[TOLGA] IMO there is no problem. It might be extra work but people are free
to support such a configuration or not. In your example, most probably
there should be two different user part entities processing messages for
RkA and RkB respectively. Each of them will receive only primitives related
with them, i.e. primitives which are caused by messages arrived for the
corresponding RK.
(BTW your RkC and RkD are invalid because they don´t contain DPC field)
>
>
>
> 4. ASP-SGP Routing should use SS7 Destination Availability/Restricted
> Status on a per-SGP rather than a per-SG basis.
>
> I believe your ASP-SGP procedures should be amended (I only amend the
> multiple SG case as the single SG case is a special case of
> the former)
> as follows:
>
> Change:
> "This routing information is updated by collecting DUNA/DAVA/DRST
> messages received from (any of the SGP in) the SG."
> To:
> "This routing information is updated by collecting DUNA/DAVA/DRST
> information on a per-(SGP,destination) basis. An SG is
> considered to be
> available and unrestricted for a particular destination if
> any SGP in it
> is available and unrestricted for that destination. Otherwise
> if this is
> not he case, then an SG is considered to be restricted for a
> particular
> destination if there is at least one SGP in the SG restricted for that
> destination. Otherwise if this is not the case, the SG is
> considered to
> be prohibited for that destination."
>
> The RFC is not particular clear on this point. In section 1.4.1 para 3
> it states that "MTP3 routeset, SPMC and remote AS/ASP states
> of each SGP
> SHOULD be coordinated across all the SGPs". However, this
> uses "SHOULD"
> which implies it is only recommended and it also doesn't specifically
> state that SS7 destination availability, restriction and congestion
> status ("SS7 destination status" for short) should be
> coordinated across
> all SGPs. I don't think that "MTP3 routeset" necessarily implies SS7
> destination status. Also, in section 1.3.2.5 1.4.2.5 it suggests in
> should be on a per-SGP basis. Section 4.5.2.2 uses the word "SG" but
> also uses the term "affected route(s)". Section 1.3.2.5 and section
> 1.4.2.5 suggest the word "route" refers to an SGP and not an
> SG. Hence,
> given the ambiguity of section 4.5.2.2 I think that route can be
> considered to refer to an SGP.
>
> A configuration where per-SGP SS7 destination status is
> necessary is as
> follows. Consider an SEP SG which has two SGP's acting as a redundant
> pair. Each SGP has it's own link set to a particular STP. While in
> section 1.4.1 para 3 it states that "Rerouting of traffic between the
> SGPs MAY also be supported", it uses "MAY" and hence this is optional.
> If one link set fails but not the other, one SGP will be able to reach
> the SS7 network but not the other if rerouting between SGPs is not
> supported or the rerouting link has also failed. Hence, it would be
> possible for one SGP to send a DUNA for a particular
> destination but not
> the other.
[TOLGA] Personally again I don´t see a problem. I only agree that "MAY" in
the sentence you refer was better changed to a "SHOULD". If somebody thinks
that creating a unique layer3 view among SGPs belonging to the same SG is
hard to implement/not necessary, then it is possible to have SGs consisting
of one SGP, without violating the protocol. In that case, SSNM will be
received separetly from each SGP, because they belong to different SGs.
>
>
> Your feedback would be appreciated.
>
> Jolan.
>
>
> --
> Jolan Evans
> Open Telecommunications
> [email-masked]
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian F. G. Bidulock
> Sent: Tuesday, 8 October 2002 17:47
> To: Srikanth Yandapalli
> Cc: [email-masked]
> Subject: Re: [Sigtran] ASP to SGP communication
>
> Srikanth,
>
> Srikanth Yandapalli wrote:               (Tue, 08 Oct 2002 12:03:52)
> >
> >    I am late entrant to this group.I am quite sure all this should
> have
> >    been discussed and I am sorry about this.
>
> Welcome.
>
> >
> >    In the context of a single ASP in communication with
> multiple SGPs,
> >    how should the routing of a MTP_DATA_REQ take place at the ASP?
>
> I assume you are talking about M3UA?  As we are dealing with 5 or more
> UAs
> now, in the future it would be helpful to add M3UA (or
> whichever) to the
> subject line.
>
> >
> >    approach 1:
> >
> >    We may find out the  RK and find out the SGP list that the RK is
> >    active on and choose one SGP for sending the message based
> >    on congestion level and also whether we have received any DRST
> >    message from any of the SGPs.
>
> This approach is applicable to multiple SGs, but not to multiple SGPs
> within a
> single SG.
>
> >    approach 2:
> >
> >    An SGP can also be viewed as providing route to a set of DPCs
> >    and the routing can be based on the DPC for the message alone.
> >    This approach is reduces the complexity but adds a situation
> >    where the RK may not be active on that association. And also is
> >    is mandatory to send RC on this association and if so what could
> >    the SGP make out of the RC?
>
> RC should be coordinated and the same across multiple SGPs
> within an SG.
>
> >
> >    Is there a preferred approach to this issue?
> >
>
> Typically, the logic can be something like this: (but there
> are several
> other
> schools of thought):
>
> Single SG case: (multiple SGs is more complicated)
>
>   MTP-TRANSFER request is issued by an MTP-User.  The
> MTP-User is bound
> to an
>   MTP-SAP.  The MTP-SAP is associated with an AS/RC/RK.
> There is a pool
> of
>   SGPs on an SG for which the AS/RC/RK is active.  The AS may have
> received
>   MTP-PAUSE/RESUME/STATUS indications from the SG and may choose to
> honor that
>   information or not.  If the ASP chooses not to honor this
> information
> it can
>   blindly send messages to the SGP and rely upon a DUNA/SCON response
> from the
>   SGP later.
>
>   Selection of an SGP within an SG is based on the traffic
> mode for the
> SGP.
>   This traffic mode is not managed by M3UA, however, M3UA provides for
>   distribution of traffic over SGP based on any of the
> methods described
> for
>   ASPs (active/standby, load-share, broadcast).  A typical method is
>   load-share based on SLS.  In this scheme, using the SLS in the
> MTP-TRANSFER
>   request, the ASP selects load-shares traffic over the available SGP.
>
> Multiple SG case:
>
>   In the more complicated multiple SG case, the ASP must
> first select an
> SG
>   before it selects an SGP within the SG.  The ASP must maintain some
>   additional routing information to be able to properly select an SG.
> This
>   routing information is updated by collecting DUNA/DAVA/DRST messages
>   received from (any of the SGP in) the SG.  To select the
> outgoing SG,
> the
>   ASP must examine the destination of the MTP-TRANSFER request.
>
>   (If the SG has no SGP active for the AS/RC/RK, all
> destinations can be
>   considered prohibited).
>
>   If the destination is available and unrestricted for
> several SGs, the
> ASP
>   should select an SG on a load-sharing basis (based on SLS) and then
> select
>   an active SGP within the SG on the basis of the traffic mode for the
> SG.
>
>   If some SG are restricted for the specified destination (based on
> received
>   DRST messages from the SG), the ASP should load-share across the
> available
>   unrestricted SGs.  If all SGs are restricted for a given
> destination,
> the
>   ASP should load-share across the available SGs and ignore the
> restricted
>   status.
>
>   If some SG are prohibited for the specified destination (based on
> received
>   DUNA messages from the SG), the ASP should load-share across the
> available
>   non-prohibited SGs.  If all SGs are prohibited for a given
> destination
> (or
>   no SGP is active for the AS/RC/RK in any SG), the ASP should respond
> to the
>   MTP-User with an MTP-PAUSE in accordance with the style of the
> MTP-User
>   interface (ITU-T and ANSI differ here).
>
> Properly selecting SGs requires that the ASP maintain the
> DUNA/DAVA/DRST
> information for each destination received from any SGP in an SG, on a
> per-SG
> basis.  This is the same as MTP Level 3 ROUTE status.  However, SCON
> information should only be maintained on a per-destination basis (and
> not
> per-SG).  This is the same as MTP Level 3 ROUTESET status.
>
> Note that, in general, it is a bad idea to consider congestion (SCON)
> when
> selecting an SG.  SCON does not necessarily indicate
> congestion at an SG
> or on
> a path to an SG, but indicates congestion at the affected
> destination or
> somewhere (perhaps distant) in the SS7 network.  SCON is
> ROUTESET-specific
> (applies to the destination), whereas DUNA/DAVA/DRST is ROUTE-specific
> (applies to the destination and path).  SCON should only be used to
> determine
> whether a message should be dropped completely and an MTP-STATUS
> returned to
> the MTP-User according to the style of the MTP-User interface
> (ITU-T and
> ANSI
> differ here again).
>
> So, to summarize:  on behalf of the AS/RC/RK/MTP-User, the ASP
> determines
> whether to send a message based on SCON received for the specified
> destination, then selects an SG based on DUNA/DAVA/DRST
> received for the
> specified destination and load-shares based on SLS across the eligible
> SGs.
> Once an SG is selected, an active SGP (active for the AS/RC/RK) is
> selected
> within the SG based on the traffic mode of the SG (active/standby,
> load-share,
> broadcast: but typically load-share on SLS).
>
> As I said, there are other schools of thought, but that is my
> understanding.
>
> --brian
>
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> _______________________________________________
> 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: Wed, 29 Jan 2003 22:36:45 -0700

Srini,

ksrinivas wrote:                                                                 (Thu, 30 Jan 2003 10:08:41)
> Tolga,
> 
> An ASP can be a part of different ASs. Similarly, Can a SGP be a part of
> different SGs?

Sure.  But from the viewpoint of an ASP, the SGP belongs to one SG.  If an
SGP were to perform the function for two SGs for the same AS, the ASP would
have to form two associations with the SGP: one for SG-A, the other for SG-B.
The SGP would also need some way of knowing (e.g. static port allocation)
for which SG the ASP was forming an association.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 Jan 2003 22:33:15 -0700

TOLGA,

TOLGA ASVEREN wrote:                                                                 (Tue, 28 Jan 2003 10:42:30)
> received separetly from each SGP, because they belong to different SGs.

SHOULD was changed to MAY because the RFC cannot force the internal
architecture of the SG.  I cited several examples where it was possible to
have SGP not transfer traffic between them (an SGP can simply drop
associations or send unsolicited ASPIA ACK when it is faced with routing
traffic to another SGP.)

I don't see any reason to change it back.

--brian

---

From: ksrinivas <[email-masked]>
Date: Thu, 30 Jan 2003 10:08:41 +0530

Tolga,

--Srini

---

From: ksrinivas <[email-masked]>
Date: Thu, 30 Jan 2003 12:29:11 +0530

Brian,

      Can you please tell me, how a message received from the SS7 network is routed using such a SGP(having two
different associations) to the AS?.

--Srini.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 30 Jan 2003 00:01:08 -0700

Srini,

The association would be chosen on the basis of for which SG the
message from the SS7 network arrived.

--brian

ksrinivas wrote:                                                                 (Thu, 30 Jan 2003 12:29:11)

---

From: ksrinivas <[email-masked]>
Date: Thu, 30 Jan 2003 12:50:37 +0530

Brian,

    So, the M3UA at the SGP should be informed the SG which received this message.

--Srini

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 30 Jan 2003 03:18:27 -0700

Srini,

If they don't have different connectivity to the SS7 network, they can hardly
be viewed as separate and different SGs.

--brian

ksrinivas wrote:                                                                 (Thu, 30 Jan 2003 12:50:37)

---

From: ksrinivas <[email-masked]>
Date: Thu, 30 Jan 2003 16:25:33 +0530

Brian,

     Can you clear my basic doubt,

    How an SGP is selected when a message from the SS7 network is received at the SG?.

--Srini

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 30 Jan 2003 05:26:18 -0700

Srini,

IMO, SLS (or something used to derive SLS such as CIC) is the only rational
basis for SGP selection at an SG.

--brian

ksrinivas wrote:                                                                 (Thu, 30 Jan 2003 16:25:33)

---

From: ksrinivas <[email-masked]>
Date: Thu, 30 Jan 2003 18:09:16 +0530

Brian,

     I feel once the eligible list of SGPs to reach the AS are found, you answer applies. But my doubt is How to find the
eligible list of SGPs?.

--Srini

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 30 Jan 2003 06:01:18 -0700

Srini,

The eligible list of SGPs is all the SGPs belonging to the SG
that have connectivity to the AS and for which an ASP is in
the ASP-ACTIVE state for the AS.

--brian

ksrinivas wrote:                                                                 (Thu, 30 Jan 2003 18:09:16)

---

From: ksrinivas <[email-masked]>
Date: Thu, 30 Jan 2003 18:52:58 +0530

Brian,

  How the SGP connectivity to the AS is determined at the SG?. Do we have to have AS-SGPs list?. But in that case we need to look
at the complete routing key table at the SG before selecting the SGP from the AS(RK).

--Srini

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 30 Jan 2003 07:00:55 -0700

Srini,

If the AS corresponds to an MTP-SAP (MTP-User), all that the SGP need do is
find the MTP-User.  How an MTP Level 3 SS7 stack finds the MTP-User is a
matter for the MTP Level 3 SS7 stack.

--brian

ksrinivas wrote:                                                                 (Thu, 30 Jan 2003 18:52:58)

---

From: ksrinivas <[email-masked]>
Date: Thu, 30 Jan 2003 20:02:51 +0530

Brian,

   Yes, I agree with you. Finding the eligible list of SGPs is the matter for MTP Level 3 SS7 stack / NIF. But IMO maintaining the
complete routing keys at the SG itself will enable us to select the eligible SGPs better. Because based on the PC of AS(i.e., DPC)
alone or any other info of routing label alone, will not suffice to select the SGP to reach the AS. Is my assumption right?.

--Srini

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 30 Jan 2003 08:04:27 -0700

Srini,

SS7 MTP Level 3 finds the MTP-SAP quite nicely today using
the information from the RL.  The RL (NI/DPC/SI) is all that
is required to locate the AS.

--brian

ksrinivas wrote:                                                                 (Thu, 30 Jan 2003 20:02:51)

---

From: ksrinivas <[email-masked]>
Date: Thu, 30 Jan 2003 10:01:26 +0530

Tolga,

--Srini

---

From: ksrinivas <[email-masked]>
Date: Fri, 31 Jan 2003 09:27:14 +0530

Brian,

Can you please tell me with what the RL is compared/matched with, in finding the MTP-SAP.

--Srini

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 30 Jan 2003 22:31:22 -0700

Srini,

Normally NI (and the identity of the link upon which the message was received)
to identify the SS7 netowrk and routing, the DPC to identify the destination
for the message, and the SI value to determine the MTP User at the desination
signalling point.  That's about it.  Gateway screening might screen the source
address and some elements of the MTP-User data but will not affect routing.

--brian

ksrinivas wrote:                                                                 (Fri, 31 Jan 2003 09:27:14)

---

From: ksrinivas <[email-masked]>
Date: Fri, 31 Jan 2003 16:52:18 +0530

Brian,

   I don't think that you have replied to what I have requested. Can you make be more clear?.

--Srini