Subject: [AAA-WG]: DCC: Service-Context-Id AVP definition and related updates

From: "STURA Marco Consultant" <[email-masked]>
Date: Mon, 2 Aug 2004 15:43:01 +0200

Hi all,
 
the IESG commented a) to clean up the section 4.1 in order to give
useful guidelines for interoperability and 
b) to clarify the Service-Identifier meaning.
 
Since a) and b) are addressed by the Mark's amendments to my proposal
and by the Leena's proposal, that 
were accepted, it is time to update the draft accordingly. What is
needed is to define the Service-Context-Id AVP
and to update the Service-Identifier and Rating-Group AVPs.
 
Here is my proposal for the updates.
 
The Service-Context-Id AVP MUST be present in the CCR as per Mark's
proposed amendment in
http://www.merit.edu/mail.archives/aaa-wg/msg00802.html
Therefore the CCR command will be updated with this AVP as follow
 
<Credit-Control-Request> ::= < Diameter Header: xxx, REQ, PXY >
                                  < Session-Id >
                                  { Origin-Host }
                                  { Origin-Realm }
                                  { Destination-Realm }
                                  { Auth-Application-Id }
                                  { Service-Context-Id }
                                  { CC-Request-Type }
                                  { CC-Request-Number }
                                  [ Destination-Host ]
                                  [ User-Name ]
                                  [ CC-Sub-Session-Id ]
                                  ...........
 
Definition of the Service-Context-Id AVP.
 
8.xx  Service-Context-Id AVP
 
The Service-Context-Id AVP is of type UTF8String (AVP Code XXX - IANA
please fill in and remove this note - suggested value 458) and contains
a unique identifier of the Diameter Credit Control service specific
document that applies to the request (as defined in section 4.1.2). This
is an identifier allocated by the service provider, by the service
element manufacturer or by a standardization body and MUST uniquely
identify a given Diameter Credit Control service specific document. The
format of the service identifier is: 
 
"service-identifier" "@" "domain"
 
service-identifier = Token
The Token is an arbitrary string of characters and digits.
 
domain = represents the entity that allocated the service-identifier.
It can be ietf.org, 3gpp.org etc. if the identifier is allocated by a
standardization body, or it can be the FQDN of the service provider
(e.g. provider.example.com) or of the vendor (e.g. vendor.example.com)
if the identifier is allocated by a private entity.
 
This AVP SHOULD be placed as closed to the Diameter header as possible.
 
Service specific documents that are for private use only, i.e. to one
provider's own use, where no interoperability is deemed useful may
define private identifiers without need of coordination. However, when
interoperability is wanted, coordination of the identifiers via e.g.
publication of informational RFC is RECOMMENDED to make
Service-Context-Id globally available.
 
Updates to Service-Identifier and Rating-Group AVP
 
FROM
 
8.28            Service-Identifier AVP
 
The Service-Identifier AVP is of type UTF8String (AVP Code XXX - IANA
please fill in and remove this note - suggested value 439) and contains
a unique identifier of a service. This is an identifier allocated by the
service provider, by the service element manufacturer or by a
standardization body and MUST uniquely identify a given service. The
format of the service identifier is: 
 
"service-identifier" "@" "domain"
 
service-identifier = Token
The Token is an arbitrary string of characters and digits.
 
domain = represents the entity that allocated the service-identifier.
It can be ietf.org, 3gpp.org etc. if the identifier is allocated by a
standardization body, or it can be the FQDN of the service provider
(e.g. provider.example.com) or of the vendor (e.g. vendor.example.com)
if the identifier is allocated by a private entity.
 
Services that are for private use only, i.e. to one provider's own use,
where no interoperability is deemed useful may define private
identifiers without need of coordination. However, when interoperability
is wanted, coordination of the identifiers via e.g. publication of
informational RFC is RECOMMENDED to make Service-Identifier globally
available.
 
A usage example of this AVP for multiple services in one user session is
illustrated in Appendix A (Flow IX).
 
TO
 
8.28 Service-Identifier AVP
 
The Service-Identifier AVP is of type Unsigned32 (AVP Code XXX - IANA
please fill in and remove this note - suggested value 439) and contains
the identifier of a service. The specific service that the request
relates to is uniquely identified by the combination of
Service-Context-Identifier and Service-Identifier AVPs.
 
A usage example of this AVP is illustrated in Appendix A (Flow IX).
 
FROM
 
8.29            Rating-Group AVP
 
The Rating-Group AVP is of type Unsigned32 (AVP Code XXX - IANA please
fill in and remove this note - suggested value 432) and contains the
identifier of a rating group. All the services subject to the same
rating type are part of the same rating group. This is an identifier
allocated by the home service provider and MUST be unique within the
home service provider domain.
 
A usage example of this AVP is illustrated in Appendix A (Flow IX).
 
TO
 
8.29            Rating-Group AVP
 
The Rating-Group AVP is of type Unsigned32 (AVP Code XXX - IANA please
fill in and remove this note - suggested value 432) and contains the
identifier of a rating group. All the services subject to the same
rating type are part of the same rating group. The specific rating group
that the request relates to is uniquely identified by the combination of
Service-Context-Identifier and Rating-Group AVPs.
 
A usage example of this AVP is illustrated in Appendix A (Flow IX).
 
Moreover, there was an issue by Glen Zorn to include the
Service-Identifier in the CER/CEA
( http://www.merit.edu/mail.archives/aaa-wg/msg00727.html )
The Service-Identifier intended by Glen is now the Service-Context-Id,
therefore the draft 06 will reflect this.
 
Let me have your comments should you disagree on the above proposal.
 
Regards
Marco