Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

From: "Bhandari, Jitin (Jitin)" <[email-masked]>
Date: Mon, 6 Nov 2006 10:34:18 -0500

I think that is true. Handling of ISUP messages as per ISUP standards (various depending upon ISUP variant) when CIC ranges face an outage (per AS) is a different issue at SG and probably does not require Sigtran attention given that this only exists between Signaling networks and SG. 

However, we need to bring back CIC ranges in Dynamic Registration message like the way we had in previous RFC and then implementation at Signaling Gateway use various ISUP recommendations (again variant dependant) to handle unavailability of certain ranges of CIC. 

So, my question would be that if we all agree that what should we do to get back CIC Ranges in Dynamic Registration messages?

Thanks,
-Jitin

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]] 
Sent: Thursday, November 02, 2006 4:06 PM
To: Haresign Lincoln; Bhandari, Jitin (Jitin); Barry Nagelberg; [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

IMO, things which effect SS7 side of the world do not need to be
standardized in SIGTRAN WG. I would say, for such issues, every SG can
decide itself what to do (and of course there are ISUP specifications).

Things which require coordination between SG and ASP need to be
standardization though.

   Thanks,
   Tolga

> -----Original Message-----
> From: Haresign Lincoln [mailto:[email-masked]]
> Sent: Thursday, November 02, 2006 4:02 PM
> To: Tolga Asveren; Bhandari, Jitin (Jitin); Barry Nagelberg;
> [email-masked]
> Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
>
>
> Tolga,
>
> I still don't understand how you are going to handle the case when you
> loose connectivity to an ASP handling a certain range of CICs.  Now you
> receive an IAM for that CIC.  What does the SG do?  Drop the message?
> This could be a fairly lengthy outage.  Or are you saying we leave it up
> to the SG and everybody does it differently?  What if the SG sends a
> BLO, then the ASP comes back, how does the ASP know the state of the
> CIC?
>
> I don't think you can just have every SG decide to do things
> differently.
>
> Regards,
> Lincoln
>
> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Thursday, November 02, 2006 3:54 PM
> To: Haresign Lincoln; Bhandari, Jitin (Jitin); Barry Nagelberg;
> [email-masked]
> Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
>
> Lincoln,
>
> IMHO it may be better to restrict what needs to be standardized to a
> simple set of rules -if possible at all- rather than a detailed analysis
> of each and every case. That strategy may or may not work.
>
>     Thanks,
>     Tolga
>
> > -----Original Message-----
> > From: Haresign Lincoln [mailto:[email-masked]]
> > Sent: Thursday, November 02, 2006 3:48 PM
> > To: Tolga Asveren; Bhandari, Jitin (Jitin); Barry Nagelberg;
> > [email-masked]
> > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> >
> >
> > Tolga,
> >
> > I believe there are all sorts of scenarios that are troublesome
> > relating to the group messages.  Don't you think we would need to
> > define all these in order for an SG to properly interop with an ASP?
> >
> > Regards,
> > Lincoln
> >
> > -----Original Message-----
> > From: Tolga Asveren [mailto:[email-masked]]
> > Sent: Thursday, November 02, 2006 3:30 PM
> > To: Bhandari, Jitin (Jitin); Haresign Lincoln; Barry Nagelberg;
> > [email-masked]
> > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> >
> > Jitin,
> >
> > Although I would think introducing CIC-ranges back to dynamic
> > registration may makes sense, I am not sure whether we need to define
> > implementation dependent functionality on SG, e.g ISUP proxy etc...
> >
> > As long as the issue can be handled locally in SG, IMHO there is no
> > need to define specific behavior in SIGTRAN WG. We maybe just need to
> > say whose responsibility is it to deal with the complexity, e.g.
> > answers messages for group messages need to be aggregated at SG.
> >
> >
> >    Thanks,
> >    Tolga
> >
> > > -----Original Message-----
> > > From: Bhandari, Jitin (Jitin) [mailto:[email-masked]]
> > > Sent: Thursday, November 02, 2006 3:14 PM
> > > To: 'Haresign Lincoln'; Barry Nagelberg; [email-masked]
> > > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> > >
> > >
> > > Lincoln,
> > >
> > > Your understanding is correct. We all understand and acknowledge
> > > limitations of previous Dynamic registration and issues associated
> > > with it. Not only the Dynamic Registration needs to be re-defined
> > > with
> >
> > > some basic modifications, along with almost a minor functionality
> > > (ISUP Proxy) need to be defined as a part of M3UA on SG for such
> > > scenarios.
> > >
> > > I can't stress enough for the need of such functionalities
> > > especially when we have elaborate network in real time domain with
> > > Multiple MGs (at-least 40) being controlled by one MGC and resources
>
> > > are shared all
> >
> > > across ASPs.
> > > If each MG is supporting large number of Trunk resources (e.g.
> > > say 60K CICs), we are talking large network provisioning in a real
> > > time network.
> > >
> > > Static registration is not a method for such networks. Flow through
> > > provisioning (Dynamic Registration) is required between MGC & SG.
> > >
> > > We have such distributed networks successfully deployed with similar
>
> > > modifications (ISUP Proxy) and enhancement (for dynamic registration
> > > procedure) for the same reason.
> > >
> > > We seriously think that its time that we should consider Dynamic
> > > registration procedure in this direction if we want a better
> > > inter-op world around us.
> > >
> > > Thanks,
> > > Jitin
> > >
> > >
> > > -----Original Message-----
> > > From: Haresign Lincoln [mailto:[email-masked]]
> > > Sent: Thursday, November 02, 2006 2:29 PM
> > > To: Barry Nagelberg; [email-masked]
> > > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> > >
> > > It certainly would be a nice feature.  But there are a large number
> > > of
> >
> > > ISUP scenarios that would need to be covered.  For example, if you
> > > loose all ASPs handing a certain CIC range, do you BLO?  Anyway, it
> > >From [email-masked] Mon Nov 06 10:38:35 2006
From: "Bhandari, Jitin (Jitin)" <[email-masked]>
To: "'Tolga Asveren'" <[email-masked]>, Haresign Lincoln
	<[email-masked]>,
	Barry Nagelberg <[email-masked]>, [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
Date: Mon, 6 Nov 2006 10:34:18 -0500 
Cc: 

I think that is true. Handling of ISUP messages as per ISUP standards (various depending upon ISUP variant) when CIC ranges face an outage (per AS) is a different issue at SG and probably does not require Sigtran attention given that this only exists between Signaling networks and SG. 

However, we need to bring back CIC ranges in Dynamic Registration message like the way we had in previous RFC and then implementation at Signaling Gateway use various ISUP recommendations (again variant dependant) to handle unavailability of certain ranges of CIC. 

So, my question would be that if we all agree that what should we do to get back CIC Ranges in Dynamic Registration messages?

Thanks,
-Jitin

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]] 
Sent: Thursday, November 02, 2006 4:06 PM
To: Haresign Lincoln; Bhandari, Jitin (Jitin); Barry Nagelberg; [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

IMO, things which effect SS7 side of the world do not need to be
standardized in SIGTRAN WG. I would say, for such issues, every SG can
decide itself what to do (and of course there are ISUP specifications).

Things which require coordination between SG and ASP need to be
standardization though.

   Thanks,
   Tolga

> -----Original Message-----
> From: Haresign Lincoln [mailto:[email-masked]]
> Sent: Thursday, November 02, 2006 4:02 PM
> To: Tolga Asveren; Bhandari, Jitin (Jitin); Barry Nagelberg;
> [email-masked]
> Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
>
>
> Tolga,
>
> I still don't understand how you are going to handle the case when you
> loose connectivity to an ASP handling a certain range of CICs.  Now you
> receive an IAM for that CIC.  What does the SG do?  Drop the message?
> This could be a fairly lengthy outage.  Or are you saying we leave it up
> to the SG and everybody does it differently?  What if the SG sends a
> BLO, then the ASP comes back, how does the ASP know the state of the
> CIC?
>
> I don't think you can just have every SG decide to do things
> differently.
>
> Regards,
> Lincoln
>
> -----Original Message- seems to me that this is almost too much for M3UA and almost
> > > requires a new extension specifically for ISUP.
> > >
> > > Regards,
> > > Lincoln
> > >
> > > -----Original Message-----
> > > From: Barry Nagelberg [mailto:[email-masked]]
> > > Sent: Wednesday, November 01, 2006 4:11 PM
> > > To: [email-masked]
> > > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> > >
> > > All,
> > >
> > > I agree with Jitlin - CIC range functionality should be put back
> > > into Dynamic Registration. After removing it to comply to the spec,
> > > we had to put it back in because one of our customers demanded it.
> > >
> > > In cases such as these, I suggest that try harder to listen to our
> > > customers - after all, they are the ones who are paying for SIGTRAN
> > > to
> >
> > > be actually implemented and deployed.
> > >
> > > Barry Nagelberg
> > > Adax, Inc.
> > >
> > > -----Original Message-----
> > > From: Bhandari, Jitin (Jitin) [mailto:[email-masked]]
> > > Sent: Wednesday, November 01, 2006 3:53 PM
> > > To: [email-masked]'
> > > Cc: [email-masked]'
> > > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> > >
> > >
> > > Brian,
> > >
> > > No where in the RFC-3332, I understand the interpretation of CIC
> > > ranges is limited to Load Distribution.
> > >
> > > When CIC ranges were a part of Routing Key, they can very well be
> > > used
> >
> > > for routing and be defined as a part of Routing key. Since,
> > > OPC-DPC-CIC values uniquely identify a resource on the ASP and can
> > > very well be treated is unique routing key from RFC definition.
> > >
> > > I very well understand when you talk about CIC & TID being just an
> > > element from Load Sharing perspective but for the same analogy if
> > > CIC & TID are for Load distribution, OPC can also be viewed as Load
> > > distribution method so as to have multiple ASPs (behind SG) handling
>
> > > parts of SS7 network. It is up-to anyone as how one vision Routing
> > > key
> >
> > > arbitration at SG for MGC. Limiting the Routing Key definition at
> > > RFC level is not fair especially when it was talked about in
> previous RFC.
> > >
> > > My point here is that by getting rid of such parameters at RFC
> > > level, we would face many inter-op issues with various vendors in
> > > the real work if one has to pick Dynamic Registration Path. We will
> > > only end up
> >
> > > with many drafts like this one modifying the Registration Request
> > > message for handling of SS7 traffic at SG. Inter-op in real world
> > > would be a serious issue with such procedures then.
> > >
> > > Also, as I mentioned in my previous email, CIC resources being
> > > dynamic
> >
> > > in nature at MGC, a flow through dynamic provisioning support (from
> > > MGC to SG) was provided by having such Keys in the dynamic
> > > registration procedure.
> > >
> > > By getting rid of such parameters at RFC level, we are just making
> > > Dynamic Registration procedure un-usable.
> > >
> > > -Jitin
> > >
> > >
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Wednesday, November 01, 2006 3:11 PM
> > > To: Bhandari, Jitin (Jitin)
> > > Cc: [email-masked]'
> > > Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message
> > >
> > > Jitin,
> > >
> > > CIC and TID were only applicable to load distribution and not
> > > routing and were therefore removed from the "routing" key.
> > >
> > > See
> > >
> > >
> > >
> http://www.ietf.org/internet-drafts/draft-bidulock-sigtran-loadsel-04.
> > > tx
> > > t
> > >
> > > for a equivalent mechanism for controlling load distribution based
> > > on CIC using a "load" key dynamically registered in the REG REQ.
> > >
> > > --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 l----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Thursday, November 02, 2006 3:54 PM
> To: Haresign Lincoln; Bhandari, Jitin (Jitin); Barry Nagelberg;
> [email-masked]
> Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
>
> Lincoln,
>
> IMHO it may be better to restrict what needs to be standardized to a
> simple set of rules -if possible at all- rather than a detailed analysis
> of each and every case. That strategy may or may not work.
>
>     Thanks,
>     Tolga
>
> > -----Original Message-----
> > From: Haresign Lincoln [mailto:[email-masked]]
> > Sent: Thursday, November 02, 2006 3:48 PM
> > To: Tolga Asveren; Bhandari, Jitin (Jitin); Barry Nagelberg;
> > [email-masked]
> > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> >
> >
> > Tolga,
> >
> > I believe there are all sorts of scenarios that are troublesome
> > relating to the group messages.  Don't you think we would need to
> > define all these in order for an SG to properly interop with an ASP?
> >
> > Regards,
> > Lincoln
> >
> > -----Original Message-----
> > From: Tolga Asveren [mailto:[email-masked]]
> > Sent: Thursday, November 02, 2006 3:30 PM
> > To: Bhandari, Jitin (Jitin); Haresign Lincoln; Barry Nagelberg;
> > [email-masked]
> > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> >
> > Jitin,
> >
> > Although I would think introducing CIC-ranges back to dynamic
> > registration may makes sense, I am not sure whether we need to define
> > implementation dependent functionality on SG, e.g ISUP proxy etc...
> >
> > As long as the issue can be handled locally in SG, IMHO there is no
> > need to define specific behavior in SIGTRAN WG. We maybe just need to
> > say whose responsibility is it to deal with the complexity, e.g.
> > answers messages for group messages need to be aggregated at SG.
> >
> >
> >    Thanks,
> >    Tolga
> >
> > > -----Original Message-----
> > > From: Bhandari, Jitin (Jitin) [mailto:[email-masked]]
> > > Sent: Thursday, November 02, 2006 3:14 PM
> > > To: 'Haresign Lincoln'; Barry Nagelberg; [email-masked]
> > > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> > >
> > >
> > > Lincoln,
> > >
> > > Your understanding is correct. We all understand and acknowledge
> > > limitations of previous Dynamic registration and issues associated
> > > with it. Not only the Dynamic Registration needs to be re-defined
> > > with
> >
> > > some basic modifications, along with almost a minor functionality
> > > (ISUP Proxy) need to be defined as a part of M3UA on SG for such
> > > scenarios.
> > >
> > > I can't stress enough for the need of such functionalities
> > > especially when we have elaborate network in real time domain with
> > > Multiple MGs (at-least 40) being controlled by one MGC and resources
>
> > > are shared all
> >
> > > across ASPs.
> > > If each MG is supporting large number of Trunk resources (e.g.
> > > say 60K CICs), we are talking large network provisioning in a real
> > > time network.
> > >
> > > Static registration is not a method for such networks. Flow through
> > > provisioning (Dynamic Registration) is required between MGC & SG.
> > >
> > > We have such distributed networks successfully deployed with similar
>
> > > modifications (ISUP Proxy) and enhancement (for dynamic registration
> > > procedure) for the same reason.
> > >
> > > We seriously think that its time that we should consider Dynamic
> > > registration procedure in this direction if we want a better
> > > inter-op world around us.
> > >
> > > Thanks,
> > > Jitin
> > >
> > >
> > > -----Original Message-----
> > > From: Haresign Lincoln [mailto:[email-masked]]
> > > Sent: Thursday, November 02, 2006 2:29 PM
> > > To: Barry Nagelberg; [email-masked]
> > > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> > >
> > > It certainly would be a nice feature.  But there are a large number
> > > of
> >
> > > ISUP scenarios that would need to be covered.  For example, if you
> > > loose all ASPs handing a certain CIC range, do you BLO?  Anyway, it
> > >ist
> > > [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

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Mon, 6 Nov 2006 10:37:29 -0500

Jitin,

I don't believe anybody answered my question.  How can you have CIC
management at the SG if you are not going to say how to handle CIC
outages towards the network.

This is no different than what we are doing for SSNs in an SUA SG or
User parts (or point codes) in an M3UA SG.  

Regards,
Lincoln

-----Original Message-----
From: Bhandari, Jitin (Jitin) [mailto:[email-masked]] 
Sent: Monday, November 06, 2006 10:34 AM
To: 'Tolga Asveren'; Haresign Lincoln; Barry Nagelberg; [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

I think that is true. Handling of ISUP messages as per ISUP standards
(various depending upon ISUP variant) when CIC ranges face an outage
(per AS) is a different issue at SG and probably does not require
Sigtran attention given that this only exists between Signaling networks
and SG. 

However, we need to bring back CIC ranges in Dynamic Registration
message like the way we had in previous RFC and then implementation at
Signaling Gateway use various ISUP recommendations (again variant
dependant) to handle unavailability of certain ranges of CIC. 

So, my question would be that if we all agree that what should we do to
get back CIC Ranges in Dynamic Registration messages?

Thanks,
-Jitin

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]]
Sent: Thursday,  seems to me that this is almost too much for M3UA and almost
> > > Sigtran mailing lNovember 02, 2006 4:06 PM

Lincoln,

   Thanks,
   Tolga

> loose connectivity to an ASP handling a certain range of CICs.  Now 
> you receive an IAM for that CIC.  What does the SG do?  Drop the
message?
> This could be a fairly lengthy outage.  Or are you saying we leave it 
> up to the SG and everybody does it differently?  What if the SG sends 
> a BLO, then the ASP comes back, how does the ASP know the state of the

> simple set of rules -if possible at all- rather than a detailed 
> analysis of each and every case. That strategy may or may not work.
>
>     Thanks,
>     Tolga
>
> > registration may makes sense, I am not sure whether we need to 
> > define implementation dependent functionality on SG, e.g ISUP proxy
etc...
> > need to define specific behavior in SIGTRAN WG. We maybe just need 
> > to say whose responsibility is it to deal with the complexity, e.g.

> > > I can't stress enough for the need of such functionalities=2ist
> > > [email-masked]

---

From: "Haresign Lincoln" <[email-masked]>
Date: Mon, 6 Nov 2006 10:37:29 -0500

Jitin,

Regards,
Lincoln

-----Original Message-----
From: Bhandari, Jitin (Jitin) [mailto:[email-masked]] 
Sent: Monday, November 06, 2006 10:34 AM
To: 'Tolga Asveren'; Haresign Lincoln; Barry Nagelberg; [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Thanks,
-Jitin

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]]
Sent: Thursday, 0

> > > time network.
> > >
> > > Static registration is not a method for such networks. Flow 
> > > through provisioning (Dynamic Registration) is required between
MGC & SG.
> > > It certainly would be a nice feature.  But there are a large 
> > > number of
> >

> > > loose all ASPs handing a certain CIC range, do you BLO?  Anyway, 
> > > it seems to me that this is almost too much for M3UA and almost 
> > > into Dynamic Registration. After removing it to comply to the 
> > > spec, we had to put it back in because one of our customers
demanded it.

> > > customers - after all, they are the ones who are paying for 
> > > SIGTRAN to
> >

> > > CIC & TID are for Load distribution, OPC can also be viewed as 
> > > Load distribution method so as to have multiple ASPs (behind SG) 
> > > handling
>

> > > the real work if one has to pick Dynamic Registration Path. We 
> > > will only end up
> >
> > > would be a serioNovember 02, 2006 4:06 PM

Lincoln,

   Thanks,
   Tolga

message?

etc...

> > > I can't stress enough for the need of such functionalities=2us issue with such procedures then.
> > >
> > > in nature at MGC, a flow through dynamic provisioning support 
> > > (from MGC to SG) was provided by having such Keys in the dynamic 
> > > registration procedure.
> > >

0

> > > time network.
> > >
> > > Static registration is not a method for such networks. Flow 
> > > through provisioning (Dynamic Registration) is required between
MGC & SG.
> > > It certainly would be a nice feature.  But there are a large 
> > > number of
> >

> > > loose all ASPs handing a certain CIC range, do you BLO?  Anyway, 
> > > it seems to me that this is almost too much for M3UA and almost 
> > > into Dynamic Registration. After removing it to comply to the 
> > > spec, we had to put it back in because one of our customers
demanded it.

> > > customers - after all, they are the ones who are paying for 
> > > SIGTRAN to
> >

> > > CIC & TID are for Load distribution, OPC can also be viewed as 
> > > Load distribution method so as to have multiple ASPs (behind SG) 
> > > handling
>

> > > the real work if one has to pick Dynamic Registration Path. We 
> > > will only end up
> >
> > > in nature at MGC, a flow through dynamic provisioning support 
> > > (from MGC to SG) was provided by having such Keys in the dynamic 
> > > registration procedure.
> > >