Subject: [AAA-WG]: RE: Multiple service instances of the same service type

From: "Wang, Yile Enoch (Enoch)" <[email-masked]>
Date: Thu, 19 Aug 2004 22:50:28 -0400

Marco,
 
I am more from the angle of CDMA2000 data support.
 
Currently, IS-835C uses Radius to perform prepaid credit control and it allows multiple service instances of the same service option (e.g., value 60 stands for voice over IP) over one established PPP/credit control session.  Credit quotas are allocated and maintained for individual service instances.  Going forward, when we migrate to Diameter (IS-835E/F), MSCC is the best candidate for this type of multi-service credit control.  I am currently struggling at what AVP to use in order to identify MSCCs to their corresponding service instances.
 
Thanks,
 
Enoch
-----Original Message-----
From: STURA Marco Consultant [mailto:[email-masked]] 
Sent: Thursday, August 19, 2004 4:54 AM
To: Wang, Yile Enoch (Enoch)
Cc: [email-masked]
Subject: RE: Multiple service instances of the same service type

Enoch,
 
I'm not sure I understand the real use case behind your suggestion, but as a matter of fact the technical content of the draft is definitely frozen.
However, following the RFC 3588 principles and the recommendations in sect. 4.1 of the DCC, it is possible to extend the DCC by defining new AVPs
in the future.
 
Regards
Marco

-----Original Message-----
From: Wang, Yile Enoch (Enoch) [mailto:[email-masked]] 
Sent: Thursday, August 19, 2004 12:49 AM
To: STURA Marco Consultant
Cc: [email-masked]
Subject: Multiple service instances of the same service type
 
Marco and colleagues,
 
MSCC provides a mechanism that allows multiple (sub)services in one credit control session.  I noticed that Service-Identifier is included in MSCC to differentiate services.  To my understanding, the use of Service-Identifier is not intended to identify run-time service instances.  If there are multiple services instances of the same type (e.g., voice service) within one credit control session, and a separate credit pool shall be maintained for each of the instance, do we have a mechanism to associate MSCCs to their corresponding service instances?  If not, do we need to introduce a Service-Instance-Identifier in MSCC?
 
Thanks,
 
Enoch

---

From: <[email-masked]>
Date: Fri, 20 Aug 2004 09:53:46 +0300

Hi Yile,
 
Are the current 3GPP2 specs alligned with the proposed RADIUS Credit Control work being standardized?  There is some effort to align both RADIUS and Diameter in this aspect.
 
John
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Wang, Yile Enoch (Enoch)
Sent: 20 August, 2004 05:50
To: STURA Marco Consultant
Cc: [email-masked]
Subject: [AAA-WG]: RE: Multiple service instances of the same service type

Marco,

 
Thanks,
 
Enoch
-----Original Message-----
From: STURA Marco Consultant [mailto:[email-masked]] 
Sent: Thursday, August 19, 2004 4:54 AM
To: Wang, Yile Enoch (Enoch)
Cc: [email-masked]
Subject: RE: Multiple service instances of the same service type

Enoch,

Regards
Marco

-----Original Message-----
From: Wang, Yile Enoch (Enoch) [mailto:[email-masked]] 
Sent: Thursday, August 19, 2004 12:49 AM
To: STURA Marco Consultant
Cc: [email-masked]
Subject: Multiple service instances of the same service type
 
Marco and colleagues,

Thanks,
 
Enoch

---

From: "STURA Marco Consultant" <[email-masked]>
Date: Fri, 20 Aug 2004 09:59:44 +0200

Hi,
 
I have been checking the last RADIUS prepaid draft and it seems they use
the Service-Id to identify a service instance.
 
Enoch, why wouldn't you use the Service-Identifier? For instance you
could specify in your DCC service specific document that
Service-Identifiers from 60 to 69 are used when multiple service
instances of the VoIP service option are established. Where 60
is the first service instance established, 61 the second and so on until
69 (in this example 10 instances are possible).
 
The combination of the Service-Context-Id and the Service-Identifier
uniquely identify your VoIP service option.
 
Alternatively, for each of the service instances you could open a
separate CC-sub-session.
 
Just a thought. What do you think?
 
Regards
Marco
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, August 20, 2004 8:54 AM
To: [email-masked]; STURA Marco Consultant
Cc: [email-masked]
Subject: RE: [AAA-WG]: RE: Multiple service instances of the same
service type
 
Hi Yile,
 
Are the current 3GPP2 specs alligned with the proposed RADIUS Credit
Control work being standardized?  There is some effort to align both
RADIUS and Diameter in this aspect.
 
John
	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]]On
Behalf Of ext Wang, Yile Enoch (Enoch)
	Sent: 20 August, 2004 05:50
	To: STURA Marco Consultant
	Cc: [email-masked]
	Subject: [AAA-WG]: RE: Multiple service instances of the same
service type
	Marco,

	Currently, IS-835C uses Radius to perform prepaid credit control
and it allows multiple service instances of the same service option
(e.g., value 60 stands for voice over IP) over one established
PPP/credit control session.  Credit quotas are allocated and maintained
for individual service instances.  Going forward, when we migrate to
Diameter (IS-835E/F), MSCC is the best candidate for this type of
multi-service credit control.  I am currently struggling at what AVP to
use in order to identify MSCCs to their corresponding service instances.
	 
	Thanks,
	 
	Enoch
	-----Original Message-----
	From: STURA Marco Consultant
[mailto:[email-masked]] 
	Sent: Thursday, August 19, 2004 4:54 AM
	To: Wang, Yile Enoch (Enoch)
	Cc: [email-masked]
	Subject: RE: Multiple service instances of the same service type
	Enoch,
	 
	I'm not sure I understand the real use case behind your
suggestion, but as a matter of fact the technical content of the draft
is definitely frozen.
	However, following the RFC 3588 principles and the
recommendations in sect. 4.1 of the DCC, it is possible to extend the
DCC by defining new AVPs
	in the future.
	 
	Regards
	Marco

	-----Original Message-----
	From: Wang, Yile Enoch (Enoch) [mailto:[email-masked]] 
	Sent: Thursday, August 19, 2004 12:49 AM
	To: STURA Marco Consultant
	Cc: [email-masked]
	Subject: Multiple service instances of the same service type
	 
	Marco and colleagues,
	 
	MSCC provides a mechanism that allows multiple (sub)services in
one credit control session.  I noticed that Service-Identifier is
included in MSCC to differentiate services.  To my understanding, the
use of Service-Identifier is not intended to identify run-time service
instances.  If there are multiple services instances of the same type
(e.g., voice service) within one credit control session, and a separate
credit pool shall be maintained for each of the instance, do we have a
mechanism to associate MSCCs to their corresponding service instances?
If not, do we need to introduce a Service-Instance-Identifier in MSCC?
	 
	Thanks,
	 
	Enoch

---

From: "Wang, Yile Enoch (Enoch)" <[email-masked]>
Date: Fri, 20 Aug 2004 09:49:17 -0400

John,
 
3GPP2 has standardized Radius based credit control for data network in IS-835C/X.S0011.  There was discussion about introducing Diameter in IS-835E/F.  However, I have not seen any contribution or draft yet.
 
Thanks,
 
Enoch
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, August 20, 2004 2:54 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [AAA-WG]: RE: Multiple service instances of the same service type

Hi Yile,

John
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Wang, Yile Enoch (Enoch)
Sent: 20 August, 2004 05:50
To: STURA Marco Consultant
Cc: [email-masked]
Subject: [AAA-WG]: RE: Multiple service instances of the same service type

Marco,

 
Thanks,
 
Enoch
-----Original Message-----
From: STURA Marco Consultant [mailto:[email-masked]] 
Sent: Thursday, August 19, 2004 4:54 AM
To: Wang, Yile Enoch (Enoch)
Cc: [email-masked]
Subject: RE: Multiple service instances of the same service type

Enoch,

Regards
Marco

-----Original Message-----
From: Wang, Yile Enoch (Enoch) [mailto:[email-masked]] 
Sent: Thursday, August 19, 2004 12:49 AM
To: STURA Marco Consultant
Cc: [email-masked]
Subject: Multiple service instances of the same service type
 
Marco and colleagues,

Thanks,
 
Enoch

---

From: "Wang, Yile Enoch (Enoch)" <[email-masked]>
Date: Fri, 20 Aug 2004 11:03:41 -0400

Marco,
 
Are you talking about 3GPP2 Prepaid draft for IS-835D?  I checked the June version of draft but could not find Service-Id VSA.
 
The service reference Id that identifies a particular service instance is assigned by the RAN and passed to PDSN when R-P is established.  Its value is dynamic and entirely out of the control of core network.  Each service instance belongs to a certain service option (e.g., 60 or 61 are for Voice over IP).  For example, if I make a three-way voice call over my data session, two service instances, with reference ids 111 and 222, are established for service option 60.  Each of the call leg has its own credit quota.  When I tear down the data session, all ongoing service instances, including the two voice call legs are also terminated.  The problem I am facing here is to associate service instance, created at the RAN side, with the quota allocated by the core network.
 
My struggle here is the intended semantics of Service-Identifier.  Practically, we can just use it.  However, I want to use it in the right way that IETF purposed.  My study of the Credit Control Application convinced me that Service-Identifier is intended to identify a specific service (type).  When a suite of services share the same rate, then can be further aggregated in the same rating group.  Service-Identifier would be a key, if Rating-Group is absent, that determines the rate of a service.  Its values shall be statically pre-defined, therefore not suitable to identify service instances.
 
The reason that I am reluctant to use sub-session is that it forces individual CCR/CCA messages for each sub-session credit manipulation.  MSCC is more economy than sub-session.
 
Thanks,
 
Enoch
 
-----Original Message-----
From: STURA Marco Consultant [mailto:[email-masked]] 
Sent: Friday, August 20, 2004 4:00 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [AAA-WG]: RE: Multiple service instances of the same service type

Hi,
 
I have been checking the last RADIUS prepaid draft and it seems they use the Service-Id to identify a service instance.
 
Enoch, why wouldn't you use the Service-Identifier? For instance you could specify in your DCC service specific document that
Service-Identifiers from 60 to 69 are used when multiple service instances of the VoIP service option are established. Where 60
is the first service instance established, 61 the second and so on until 69 (in this example 10 instances are possible).
 
The combination of the Service-Context-Id and the Service-Identifier uniquely identify your VoIP service option.
 
Alternatively, for each of the service instances you could open a separate CC-sub-session.

Regards
Marco
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, August 20, 2004 8:54 AM
To: [email-masked]; STURA Marco Consultant
Cc: [email-masked]
Subject: RE: [AAA-WG]: RE: Multiple service instances of the same service type
 
Hi Yile,

John
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Wang, Yile Enoch (Enoch)
Sent: 20 August, 2004 05:50
To: STURA Marco Consultant
Cc: [email-masked]
Subject: [AAA-WG]: RE: Multiple service instances of the same service type
Marco,

 
Thanks,
 
Enoch
-----Original Message-----
From: STURA Marco Consultant [mailto:[email-masked]] 
Sent: Thursday, August 19, 2004 4:54 AM
To: Wang, Yile Enoch (Enoch)
Cc: [email-masked]
Subject: RE: Multiple service instances of the same service type
Enoch,

Regards
Marco

-----Original Message-----
From: Wang, Yile Enoch (Enoch) [mailto:[email-masked]] 
Sent: Thursday, August 19, 2004 12:49 AM
To: STURA Marco Consultant
Cc: [email-masked]
Subject: Multiple service instances of the same service type
 
Marco and colleagues,

Thanks,
 
Enoch

---

From: "STURA Marco Consultant" <[email-masked]>
Date: Fri, 20 Aug 2004 18:10:55 +0200

> Are you talking about 3GPP2 Prepaid draft for IS-835D?  I checked the
June version of draft but could not find Service-Id VSA.
 
No, I'm talking about this one
http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions
-05.txt.
 
Sub-Type (=10) : Sub-Type for Service ID 
   Length         : Length of Service ID 

   Service-Id:  
    
     Opaque string that uniquely describes a service instance for which 
     we want to apply prepaid metering to.  A Service-Id could be an IP 
     5-tuple (source address, source port, destination address, 
     destination port, protocol).  If Service-ID is present in the PPAQ 
     the PPAQ applies to that Service.  If a PPAQ does not contain a 
     Service-Id then the PPAQ applies to the Access Service. 
 
>The service reference Id that identifies a particular service instance
is assigned by the RAN and passed to PDSN when R-P is established.  Its
value is dynamic and >entirely out of the control of core network.  Each
service instance belongs to a certain service option (e.g., 60 or 61 are
for Voice over IP).  For example, if I make a three->way voice call over
my data session, two service instances, with reference ids 111 and 222,
are established for service option 60.  Each of the call leg has its own
credit >quota.  When I tear down the data session, all ongoing service
instances, including the two voice call legs are also terminated.  The
problem I am facing here is to >associate service instance, created at
the RAN side, with the quota allocated by the core network.
 
I'm not very familiar with how the service instances are assigned, thank
you for the clarification. 
But, couldn't the PDSN map the first instance (whatever is its RAN
generated reference) to the SI value of 61, the second instance
(whatever is its RAN reference) to the SI value of 62 and so on and
maintain the mapping for the duration of the service instance?
 
If the cost of the access is determined by the service option, it would
be possible to group Service-Identifiers 60 to 69 under a Rating-group.
Then the DCC-S could decide to authorize the whole rating-group (i.e.
all the service instances will draw from the same credit quota) or a
single service instance (i.e. one credit quota per each of the service
instances).
 
>My struggle here is the intended semantics of Service-Identifier.
Practically, we can just use it.  However, I want to use it in the right
way that IETF purposed.  My study >of the Credit Control Application
convinced me that Service-Identifier is intended to identify a specific
service (type).  When a suite of services share the same rate, then >can
be further aggregated in the same rating group.  Service-Identifier
would be a key, if Rating-Group is absent, that determines the rate of a
service.  Its values shall >be statically pre-defined, therefore not
suitable to identify service instances.
 
I think you got it right. But the value of the Service-Identifier is not
necessarily pre-defined, it can be dynamic if you have a mechanism in
your environment to do this.
How the Rating-Groups and Service-identifiers are provisioned/determined
is actually out of the scope of the DCC specification.
 
>The reason that I am reluctant to use sub-session is that it forces
individual CCR/CCA messages for each sub-session credit manipulation.
MSCC is more economy >than sub-session.
 
I understand.
 
I hope this help
Marco

---

From: "Wang, Yile Enoch (Enoch)" <[email-masked]>
Date: Fri, 20 Aug 2004 15:49:18 -0400

Marco,
 
I am trying hard to figure out the exact meaning of Service-Identifier in credit control application.  You confirmed my view through the discussion.  Thanks for the help!
 
Since Service-Identifier is not meant to reference run-time service instances, we can either hijack it (e.g., through a mapping mechanism as you suggested) or introduce a new AVP to further refine this overloaded AVP (as we did to Service-Context-Identifier). I am leaning toward the latter for the sake of clarity.  When IS-835 starts to introduce Diameter, we might propose to introduce a 3GPP2 AVP to carry the service instance identifier in order to address this issue.
 
I ran this issue through this board to 1) confirm that my understanding of Service-Identifier is correct, and 2) see if people would like to handle this generic issue at IETF level.
 
Thanks,
 
Enoch
-----Original Message-----
From: STURA Marco Consultant [mailto:[email-masked]] 
Sent: Friday, August 20, 2004 12:11 PM
To: Wang, Yile Enoch (Enoch)
Cc: [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: RE: Multiple service instances of the same service type

> Are you talking about 3GPP2 Prepaid draft for IS-835D?  I checked the June version of draft but could not find Service-Id VSA.
 
No, I'm talking about this one http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-05.txt <http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-05.txt> .

   Service-Id:  

>The service reference Id that identifies a particular service instance is assigned by the RAN and passed to PDSN when R-P is established.  Its value is dynamic and >entirely out of the control of core network.  Each service instance belongs to a certain service option (e.g., 60 or 61 are for Voice over IP).  For example, if I make a three->way voice call over my data session, two service instances, with reference ids 111 and 222, are established for service option 60.  Each of the call leg has its own credit >quota.  When I tear down the data session, all ongoing service instances, including the two voice call legs are also terminated.  The problem I am facing here is to >associate service instance, created at the RAN side, with the quota allocated by the core network.
 
I'm not very familiar with how the service instances are assigned, thank you for the clarification. 
But, couldn't the PDSN map the first instance (whatever is its RAN generated reference) to the SI value of 61, the second instance (whatever is its RAN reference) to the SI value of 62 and so on and maintain the mapping for the duration of the service instance?
 
If the cost of the access is determined by the service option, it would be possible to group Service-Identifiers 60 to 69 under a Rating-group. Then the DCC-S could decide to authorize the whole rating-group (i.e. all the service instances will draw from the same credit quota) or a single service instance (i.e. one credit quota per each of the service instances).
 
>My struggle here is the intended semantics of Service-Identifier.  Practically, we can just use it.  However, I want to use it in the right way that IETF purposed.  My study >of the Credit Control Application convinced me that Service-Identifier is intended to identify a specific service (type).  When a suite of services share the same rate, then >can be further aggregated in the same rating group.  Service-Identifier would be a key, if Rating-Group is absent, that determines the rate of a service.  Its values shall >be statically pre-defined, therefore not suitable to identify service instances.
 
I think you got it right. But the value of the Service-Identifier is not necessarily pre-defined, it can be dynamic if you have a mechanism in your environment to do this.
How the Rating-Groups and Service-identifiers are provisioned/determined is actually out of the scope of the DCC specification.
 
>The reason that I am reluctant to use sub-session is that it forces individual CCR/CCA messages for each sub-session credit manipulation.  MSCC is more economy >than sub-session.
 
I understand.
 
I hope this help
Marco

---

From: "STURA Marco Consultant" <[email-masked]>
Date: Mon, 23 Aug 2004 09:21:19 +0200

>Since Service-Identifier is not meant to reference run-time service
instances, we can either hijack it (e.g., through a mapping mechanism as
you suggested) or introduce >a new AVP to further refine this overloaded
AVP (as we did to Service-Context-Identifier). I am leaning toward the
latter for the sake of clarity.  When IS-835 starts to >introduce
Diameter, we might propose to introduce a 3GPP2 AVP to carry the service
instance identifier in order to address this issue.
 
Either one is feasible, I think. 
Perhaps introducing a 3GPP2 AVP to carry the service instance semantic
sounds like the best solution to your problem, you can define this AVP
in your standard DCC service specific document (identified by the
Service-Context-Id). This is absolutely feasible since the MSCC can be
extended
by means of *[AVP].
 
Regards
Marco