Subject: [Dime] Liaison Request from ITU-T

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 07 Feb 2007 21:32:11 +0100

--Resend since I am not sure whether my mail reached the mailing list.

Hi all,

the chairs have received a liaison document from the ITU-T with the 
title: "RFC 3588 - Requirement of Session State Machine for Diameter 
Server Initiated Session"

Thanks to Tina and Sudhir.

Here is the extracted text:

"
ITU-T study group 11 question 5 would like to acknowledge the 
versatility of the Diameter Protocol for its suitability over many 
interfaces in Next Generation Networks (NGN).  The group has decided to 
use the protocol (as one of the alternatives) for the Rs and Rw 
interfaces in the Resource and Admission Control Function (RACF) part of 
the NGN.  The latest drafts of the corresponding protocol specification 
documents for the Rs and Rw interfaces are Q.3301.1 and Q.rcp3.3 
(T05-NGN.GSI-DOC-0127) respectively. 

The Rw interface exists between Policy Decision Physical Entity (PD-PE) 
and the Policy Enforcement Physical Entity (PE-PE) where PD-PE acts as 
the diameter server and the PE-PE acts as the diameter client.  For the 
pull mode of operation, the PE-PE establishes a diameter session and the 
corresponding state machine is covered in section 8.1 of the RFC 3588.  
But for the push mode there is a requirement that the PD-PE, acting as a 
diameter server, initiates the session for which no state machine has 
been provided in the RFC.  The RFC, however, in the last paragraph of 
its section 8.8 indicates indirectly that there is possibility of the 
session initiation by the server.

ITU-T study group 11 question 5 would like to look for comments and 
enhancement of the diameter protocol to clearly specify the session 
state machine for the case of diameter server initiated session.
"

Please find the full document at the Wiki page: 
http://www.tschofenig.priv.at/twiki/bin/view/Dime/IetfDimeRoadMap

Ciao
Hannes

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 7 Feb 2007 16:01:19 -0500

I guess 8.8 is a generic section regarding the use of Session-Id AVP and the
statement  that sessions are usually initiated by clients (which implies
that they may be initiated by servers) does not necessarily hold for all
Diameter applications (that is the part about they may be initiated by
servers).

To me, it doesn't seem to be an oversight that there is no authorization
state machine defined for server initiated sessions. What would be the
semantics for that mode of operation? What would be the request sent from
server to client and for what purpose?

    Thanks,
    Tolga

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Wednesday, February 07, 2007 3:32 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Dime] Liaison Request from ITU-T
>
>

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 07 Feb 2007 18:45:53 -0500

Comments inline:
> The Rw interface exists between Policy Decision Physical Entity 
> (PD-PE) and the Policy Enforcement Physical Entity (PE-PE) where PD-PE 
> acts as the diameter server and the PE-PE acts as the diameter 
> client.  For the pull mode of operation, the PE-PE establishes a 
> diameter session and the corresponding state machine is covered in 
> section 8.1 of the RFC 3588.  But for the push mode there is a 
> requirement that the PD-PE, acting as a diameter server, initiates the 
> session for which no state machine has been provided in the RFC.  

I'm not familiar with the Rw architecture but would'nt it be possible 
for the PD-PE to initiate a 'client session' towards the PE-PE ...

regards,
victor

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Wed, 7 Feb 2007 19:21:56 -0600

Hi Tolga,

In the context of QoS/policy control application, there are two models
identified: Push and Pull mode (you can find details from the I-D
(http://www.ietf.org/internet-drafts/draft-sun-dime-diameter-resource-co
ntrol-requirements-00.txt) and some slides were presented in IETF 67
concerning the use case). 

The trend of policy control application in the industry is moving
towards an universal architecture to support both pull and push modes.
ITU-T has already defined it in its RACF Release 1. (ETSI TISPAN also
added similar requirement in its ongoing RACS Release 2 work; 3GPP also
intends to support both mobile networks and fixed networks within its
PCC framework, which will require a Push mode in addition to the current
Pull mode). 

The main issue is that, according to 3GPP R7 Gx spec, in the Pull mode
the policy enforcement point (i.e. PE-FE in ITU-T) serves as a Diameter
client and the policy decision point (i.e. PD-FE in ITU-T) serve as a
Diameter server. 
Meanwhile, for the Push mode, the same PD-FE also needs to initiate
Diameter session towards the PE-FE. Theoretically, the PD-FE may serve
as a Diameter client in Push mode. However, it seems quite complicated
to maintain two types of relationships between a pair of Diameter
entities dynamically on a per call basis.  On the other hand, if a fixed
client-server relationship is employed between PE-FE and PD-FE, since
the Diameter client may be already embedded in the router for other
purpose (e.g. AAA), then no additional protocol stack and session state
maintenance are required in the router exclusively in order to support
the policy control. 

Hope this help. (also correspond to Victor's question in a separate
email).

In addition, I'd like to know how difficult to make Diameter server
initiate a new session. Or is it possible to define this kind of state
machine in a separate application if base protocol does not cover it.

Regards,
Dong

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]] 
Sent: Wednesday, February 07, 2007 4:01 PM
To: [email-masked]
Subject: RE: [Dime] Liaison Request from ITU-T

I guess 8.8 is a generic section regarding the use of Session-Id AVP and
the statement  that sessions are usually initiated by clients (which
implies that they may be initiated by servers) does not necessarily hold
for all Diameter applications (that is the part about they may be
initiated by servers).

To me, it doesn't seem to be an oversight that there is no authorization
state machine defined for server initiated sessions. What would be the
semantics for that mode of operation? What would be the request sent
from server to client and for what purpose?

    Thanks,
    Tolga

> interfaces in Next Generation Networks (NGN).  The group has decided 
> to use the protocol (as one of the alternatives) for the Rs and Rw 
> interfaces in the Resource and Admission Control Function (RACF) part 
> of the NGN.  The latest drafts of the corresponding protocol 
> specification documents for the Rs and Rw interfaces are Q.3301.1 and 
> Q.rcp3.3

> acts as the diameter server and the PE-PE acts as the diameter client.

> For the pull mode of operation, the PE-PE establishes a diameter 
> session and the corresponding state machine is covered in section 8.1
of the RFC 3588.
> But for the push mode there is a requirement that the PD-PE, acting as

> a diameter server, initiates the session for which no state machine 
> has been provided in the RFC.  The RFC, however, in the last paragraph

> of its section 8.8 indicates indirectly that there is possibility of 
> the session initiation by the server.
>

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 8 Feb 2007 08:26:52 -0500

Hi Dong,

[..snip..]
> machine in a separate application if base protocol does not cover it.
[TOLGA]That is exactly my point, if an application sees it necessary, they
can define that type of behavior with the corresponding state machine. What
I try to understand is, is there a need for a change in the base protocol
for that?

---

From: Victor Fajardo <[email-masked]>
Date: Sat, 10 Feb 2007 15:51:39 -0500

Hi Sudhir,
>
> But in case of push mode, the session establishment is required from 
> the PD-PE (which is already acting as diameter server).  This 
> particular scenario is not covered in 3GPP Gx architecture and is 
> introduced in ITU-T only.  Hence there is this requirements.  In this 
> case the PD-PE is not intended to be treated as diamter client because 
> that will make the PD-PE functionality very complex and subjective (to 
> the Push/Pull mode).  Since Push/Pull modes could be decided 
> dynamically, it would be very difficult for the PD-PE to act as both 
> server and client depending on the scenario.  

I guess there some clarification that is needed. My understanding is 
that you don't necessarily need to restrict your PD-PE server to use 
only diameter server sessions. Note that I'm separating the notion of 
diameter 'server sessions' from the PD-PE server functions. The idea 
that these two things are always fused together is what maybe causing 
the confusion. If you separate them there is no reason why your PD-PE 
server functions cannot also initiate a diameter 'client session'. This 
is the idea that Tolga is mentioning, if the PD-PE server needs to 
initiate a request then it can use the appropriate statemachine, i.e. 
client state machine.

best regards,
victor

---

From: [email-masked]
Date: Sat, 10 Feb 2007 19:30:18 +0530

In the Rw architecture (for the Diameter Option), we are using PD-PE as a 
diameter server already for the Pull Mode case.  This is in line with the 
3GPP Gx architecture (release 7).  But in this case the session is 
initiated by the PE-PE and there is no ambiguity as far as the diamter RFC 
is concerned. 

But in case of push mode, the session establishment is required from the 
PD-PE (which is already acting as diameter server).  This particular 
scenario is not covered in 3GPP Gx architecture and is introduced in ITU-T 
only.  Hence there is this requirements.  In this case the PD-PE is not 
intended to be treated as diamter client because that will make the PD-PE 
functionality very complex and subjective (to the Push/Pull mode).  Since 
Push/Pull modes could be decided dynamically, it would be very difficult 
for the PD-PE to act as both server and client depending on the scenario. 

Regards,
Sudhir Mittal

Victor Fajardo <[email-masked]>
02/08/2007 05:15 AM
 
        To:     Hannes Tschofenig <[email-masked]>
        cc:     [email-masked], [email-masked]
        Subject:        Re: [Dime] Liaison Request from ITU-T
 Importance: Normal  Sender's OU: Reliance 

regards,
victor

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 12 Feb 2007 10:28:36 -0500

Hi Sudhir,
>
> This leads to a very complex product which supports the diamter client 
> as well as diameter server state machines for different dynamically 
> determined scenarios.  This kind of complex specification is not 
> acceptable to most of the members.  Hence there was this need of 
> diameter server initiated session.  If that happens then the PD-PE 
> needs to maintain the state machine only for the diamter server.

I'm not sure if its really that complex or maybe I'm just missing 
something. In push mode you use a client sessions and in the pull mode 
you use a server sessions. In either case, you still maintaining only 
one type of sessions and your not really incurring any additional 
processing cost nor adding complex decision making on when to use which 
mode. My main concern here is the attempt to change a fundamental server 
session behavior in 3588 to accommodate a behavior that seems to be 
easily solved.

best regards,
victor

---

From: [email-masked]
Date: Mon, 12 Feb 2007 16:16:28 +0530

Hi Victor,

The issue is not really with the PD-PE acting as a server or client. In 
fact we just need the information exchange between PD-PE and PE-PE using 
diameter protocol.  The issue is that we need to support both Pull mode 
and Push mode of the session initiation and the subsequent message flows 
need to be inline with the diameter RFC. 

In our stage 3 work, for pull mode, PE-PE sends AAR towards PD-PE for 
session inititation.  Subsequently, the PD-PE may inititate RAR towards 
PE-PE.  Thus the state machine followed at the PD-PE is that of Diameter 
Server.

For push mode, if we initiate a session from PD-PE (as suggested by you), 
then the PD-PE needs to inititate the AAR (or any other new message for 
server initiation) towards PE-PE.  Thus the PD-PE acts as a diameter 
client.  Due to this reason the PD-PE can not send the messages like RAR 
which are server initiated messages.  As a result we would need a Diamter 
Client State machine at PD-PE also.

This leads to a very complex product which supports the diamter client as 
well as diameter server state machines for different dynamically 
determined scenarios.  This kind of complex specification is not 
acceptable to most of the members.  Hence there was this need of diameter 
server initiated session.  If that happens then the PD-PE needs to 
maintain the state machine only for the diamter server.

Regards,
Sudhir Mittal

02/11/2007 02:21 AM
 
        To:     [email-masked]
        cc:     [email-masked], Hannes Tschofenig 
<[email-masked]>, Tina TSOU <[email-masked]>
        Subject:        Re: [Dime] Liaison Request from ITU-T
 Importance: Normal  Sender's OU: Reliance 

Hi Sudhir,

best regards,
victor

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 12 Feb 2007 18:08:27 -0500

Hi Sudhir,

I don't see the big difference between two state machines and a single state
machine with two parts each of them equal to one state machine of the first
model. Maybe I misunderstand the whole issue but what Victor suggested seems
very logical to me.

AFAICS, with two state machines one would have (I just will give a
simplified example from diameter client point of view):

If incoming AAA or RAR run client authorization state machine
If incoming AAR run server authorization state machine

client authorization state machine
{
  do whatever RFC3588 says in client authorization state machine
}

server authorization state machine
{
  do whatever RFC3588 says in server authorization state machine
}

With a single state machine one would have:
for every incoming message call the state machine

state machine
{
 if the message is AAA or RAR do whatever RFC3588 says in client section of
authorization state machine
 if the message is AAR do whatever RFC3588 says in server section of
authorization state machine
}

   Thanks,
   Tolga

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, February 12, 2007 5:46 AM
To: Victor Fajardo
Cc: [email-masked]
Subject: Re: [Dime] Liaison Request from ITU-T

Hi Victor,

The issue is not really with the PD-PE acting as a server or client. In fact
we just need the information exchange between PD-PE and PE-PE using diameter
protocol.  The issue is that we need to support both Pull mode and Push mode
of the session initiation and the subsequent message flows need to be inline
with the diameter RFC.

For push mode, if we initiate a session from PD-PE (as suggested by you),
then the PD-PE needs to inititate the AAR (or any other new message for
server initiation) towards PE-PE.  Thus the PD-PE acts as a diameter client.
Due to this reason the PD-PE can not send the messages like RAR which are
server initiated messages.  As a result we would need a Diamter Client State
machine at PD-PE also.

This leads to a very complex product which supports the diamter client as
well as diameter server state machines for different dynamically determined
scenarios.  This kind of complex specification is not acceptable to most of
the members.  Hence there was this need of diameter server initiated
session.  If that happens then the PD-PE needs to maintain the state machine
only for the diamter server.

Regards,
Sudhir Mittal

Hi Sudhir,

best regards,
victor

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Mon, 12 Feb 2007 17:44:51 -0600

I don't think you need two independent parts with a single state machine
if the Diameter server is allowed to initiate a new session in order to
support Push mode. In fact, all existing commands as defined in QoS
application (they are used to support pull mode at the moment) can be
reused for Push mode, the only addition is to define a pair of new
commands to initiate new session. In other words, the current state
machine in server side can be reused to support Push model with some
enhancement (add a pair of new commands and allow the server to initiate
new session in the state machine). 

I am not sure if the complexity of maintaining two state machines within
the same physical instance of PD-FE for Diameter client and server
respectively equals to a single state mechanism of Diameter server. 

In addition, since Diameter client may already exist in the network
element for some applications e.g. AAA. it makes sense to reuse existing
client for QoS enforcement in Push model from cost-effective, complexity
and performance perspective. 

Regards,
Dong 

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]] 
Sent: Monday, February 12, 2007 6:08 PM
To: [email-masked]; Victor Fajardo
Cc: [email-masked]
Subject: RE: [Dime] Liaison Request from ITU-T

Hi Sudhir,

I don't see the big difference between two state machines and a single
state machine with two parts each of them equal to one state machine of
the first model. Maybe I misunderstand the whole issue but what Victor
suggested seems very logical to me.

If incoming AAA or RAR run client authorization state machine If
incoming AAR run server authorization state machine

client authorization state machine
{
  do whatever RFC3588 says in client authorization state machine }

server authorization state machine
{
  do whatever RFC3588 says in server authorization state machine }

state machine
{
 if the message is AAA or RAR do whatever RFC3588 says in client section
of authorization state machine  if the message is AAR do whatever
RFC3588 says in server section of authorization state machine }

   Thanks,
   Tolga

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Monday, February 12, 2007 5:46 AM
To: Victor Fajardo
Cc: [email-masked]
Subject: Re: [Dime] Liaison Request from ITU-T

Hi Victor,

For push mode, if we initiate a session from PD-PE (as suggested by
you), then the PD-PE needs to inititate the AAR (or any other new
message for server initiation) towards PE-PE.  Thus the PD-PE acts as a
diameter client.
Due to this reason the PD-PE can not send the messages like RAR which
are server initiated messages.  As a result we would need a Diamter
Client State machine at PD-PE also.

This leads to a very complex product which supports the diamter client
as well as diameter server state machines for different dynamically
determined scenarios.  This kind of complex specification is not
acceptable to most of the members.  Hence there was this need of
diameter server initiated session.  If that happens then the PD-PE needs
to maintain the state machine only for the diamter server.

Regards,
Sudhir Mittal

Hi Sudhir,

best regards,
victor

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Mon, 12 Feb 2007 17:50:32 -0600

Just for clarification.
In the last sentence, the network element refers to policy enforcement
point (PE-FE), rather than the policy decision point (PD-FE). 
Thanks,

-----Original Message-----
From: Sun, Dong (Dong) [mailto:[email-masked]] 
Sent: Monday, February 12, 2007 6:45 PM
To: Tolga Asveren; [email-masked]; Victor Fajardo
Cc: [email-masked]
Subject: RE: [Dime] Liaison Request from ITU-T

Regards,
Dong 

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]]
Sent: Monday, February 12, 2007 6:08 PM
To: [email-masked]; Victor Fajardo
Cc: [email-masked]
Subject: RE: [Dime] Liaison Request from ITU-T

Hi Sudhir,

state machine
{

   Thanks,
   Tolga

-----Original Message-----

Hi Victor,

Regards,
Sudhir Mittal

Hi Sudhir,

best regards,
victor

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 12 Feb 2007 22:02:36 -0500

Hi,
> respectively equals to a single state mechanism of Diameter server. 

 From a modular design point it maybe better to maintain separate state 
machines as opposed to a monolithic do it all server state machine ...

> and performance perspective. 

Does this mean the conclusion is to fall in line with the way 3588 
current defines server session fsm's ?

regards,
victor

---

From: Rajith R <[email-masked]>
Date: Tue, 13 Feb 2007 10:05:41 +0530

Hi
	I also agree with Sun's suggestion to extend the server state
machine with 2 more messages (one such example is the QIR in the latest QoS
draft).
	If we decide to use Tolga/Victor's suggestion of having a server
state machine at the PE-PE, I think it is not appropriate of a PE-PE to send
RAR or ASR. 
	However, in this case, wemay have to update the client state machine
also (to handle the new request).

Rajith   

>From: Victor Fajardo [mailto:[email-masked]] 
>Sent: Tuesday, February 13, 2007 8:33 AM
>To: Sun, Dong (Dong)
>Cc: [email-masked]; [email-masked]
>> I don't think you need two independent parts with a single state 
>> machine if the Diameter server is allowed to initiate a new 
>session in 
>> order to support Push mode. In fact, all existing commands 
>as defined 
>> in QoS application (they are used to support pull mode at 
>the moment) 
>> can be reused for Push mode, the only addition is to define 
>a pair of 
>> new commands to initiate new session. In other words, the current 
>> state machine in server side can be reused to support Push 
>model with 
>> some enhancement (add a pair of new commands and allow the server to 
>> initiate new session in the state machine).
>>
>> I am not sure if the complexity of maintaining two state machines 
>> within the same physical instance of PD-FE for Diameter client and 
>> server respectively equals to a single state mechanism of 
>Diameter server.
>>   
>
> From a modular design point it maybe better to maintain 
>separate state machines as opposed to a monolithic do it all 
>server state machine ...
>
>> element for some applications e.g. AAA. it makes sense to reuse 
>> existing client for QoS enforcement in Push model from 
>cost-effective, 
>> complexity and performance perspective.
>>   
>
>Does this mean the conclusion is to fall in line with the way 
>3588 current defines server session fsm's ?
>
>regards,
>victor
>
>

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 13 Feb 2007 10:20:04 -0500

Hi Rajith,
> state machine at the PE-PE, I think it is not appropriate of a PE-PE to send

I'm not sure about the functionality you had in mind but you don't have 
to send a re-auth if you don't need to. As far as ASR is concerned, its 
a sessions maintenance message so I don't think it affects your PE-PE 
functionality too much. Also, it really depends on your application 
policy on whether ASR is sent or you just expect and STR. In such a case 
your not restricted to using it.

> also (to handle the new request).
If we consider Tolga's suggestion, its easy to achieve symmetric 
conversation between the two entities without changing 3588. One 
advantage is that the type of sessions you use in your push and pull 
modes are mirrored opposites and present in both PE-PE and PD-PE so 
reuse comes easily. Another advantage is your modes are segregated so it 
makes it easy to add/change/delete functionality to one mode without 
affecting the other.

regards,
victor

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Tue, 13 Feb 2007 09:27:18 -0600

Hi Victor,
For clarification:

> existing client for QoS enforcement in Push model from cost-effective,

Does this mean the conclusion is to fall in line with the way 3588
current defines server session fsm's ?
--------
[Dong] what I mean is that the network element (e.g. router, BRAS,
GGSN/PDSN etc) should serve as Diameter client for all applications
since majority of applications such as AAA, QoS application for Pull
model will use the NE as Diameter client. Therefore, it makes sense to
use this Diameter client (in NE) for Push model QoS application as well,
rather than adding a new Diameter Server in the NE only for Push model
QoS application.  

The current client and server fsm need to be enhanced (to allow the
server to initiate a new session) for this purpose.
------------

regards,
victor

---

From: Rajith R <[email-masked]>
Date: Wed, 14 Feb 2007 10:17:24 +0530

Hi Victor
	Whether push/pull mode, the PD-PE always takes policy decisions and
PE-PE is always the enforcement point (as directed by the policy information
received from PD-PE). The State machines should also be inline with this
behaviour. I dont think the client Auth. FSM is suited to an entity who
takes policy decisions and applies at a PE-PE. For eg: PD-PE may have to
send a RAR. The cline FSM does not provide for this, I think.

Regards

Rajith

>Sent: Tuesday, February 13, 2007 8:50 PM
>To: [email-masked]
>Cc: 'Sun, Dong (Dong)'; [email-masked]; [email-masked]
>> 	I also agree with Sun's suggestion to extend the server 
>state machine 
>> with 2 more messages (one such example is the QIR in the latest QoS 
>> draft).
>> state machine at the PE-PE, I think it is not appropriate of a PE-PE 
>> to send RAR or ASR.
>>   
>
>I'm not sure about the functionality you had in mind but you 
>don't have to send a re-auth if you don't need to. As far as 
>ASR is concerned, its a sessions maintenance message so I 
>don't think it affects your PE-PE functionality too much. 
>Also, it really depends on your application policy on whether 
>ASR is sent or you just expect and STR. In such a case your 
>not restricted to using it.
>
>If we consider Tolga's suggestion, its easy to achieve 
>symmetric conversation between the two entities without 
>changing 3588. One advantage is that the type of sessions you 
>use in your push and pull modes are mirrored opposites and 
>present in both PE-PE and PD-PE so reuse comes easily. Another 
>advantage is your modes are segregated so it makes it easy to 
>add/change/delete functionality to one mode without affecting 
>the other.
>
>regards,
>victor
>

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 14 Feb 2007 09:57:02 -0500

Hi Rajith,
> send a RAR. The cline FSM does not provide for this, I think.

One should considered that the diameter client and server fsm is used by 
many other applications the way are are designed. Again, I think it 
would be in-appropriate to change that existing expected behavior just 
to accommodate a PD-PE requirement which seems easy to solve with the 
existing fsm design. My two cents on this issue.

regards,
victor

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 15 Feb 2007 08:28:02 -0500

Comments inline:
>  
> 1. For push mode, PD-PE acts as diameter client PE-PE as diameter 
> server.  PD-PE sends message to the PE-PE for the session inititation.
>
> 2. In this case, since PD-PE is a diamter client, it will not send RAR 
> and ASR messages.  The functionality of RAR and ASR messages needs to 
> be fulfilled by some new messages.

In this case, the PD-PE can use STR in place of ASR. If you have been 
using RAR in the pull mode then you probably already have an existing 
message used for authorization. If you do you can re-use that.

hope this helps,
victor

---

From: [email-masked]
Date: Thu, 15 Feb 2007 12:17:55 +0530

Hi Victor,

When you say that the PD-PE requirement is easy to solve within the 
existing FSM design, are you recommending the following?

{
1. For push mode, PD-PE acts as diameter client PE-PE as diameter server. 
PD-PE sends message to the PE-PE for the session inititation.

2. In this case, since PD-PE is a diamter client, it will not send RAR and 
ASR messages.  The functionality of RAR and ASR messages needs to be 
fulfilled by some new messages.

3. For pull mode PE-PE acts as diameter client and PD-PE as diamter 
server.  PE-PE sends message to the PD-PE for the session inititation.

4. In this case PD-PE will be able to send RAR and ASR messages for the 
corresponding functionalities.

5. Thus PD-PE acts either a diameter client or server depending upon the 
scenario.
}

Please tell if you have any other solution in mind.

Regards,
Sudhir Mittal

02/14/2007 08:27 PM
 
        To:     [email-masked]
        cc:     "'Sun, Dong (Dong)'" <[email-masked]>, 
[email-masked], [email-masked]
        Subject:        Re: [Dime] Liaison Request from ITU-T
 Importance: Normal  Sender's OU: Reliance 

Hi Rajith,

regards,
victor

---

From: Rajith R <[email-masked]>
Date: Mon, 19 Feb 2007 12:03:30 +0530

If you look at the stateful client & server FSMs in RFC 3588, the behaviour
of ASR and STR are different. ASR provides for client NOT to consent, in
which case the server will resend the ASR. However, I cannot find a similar
provision for STR. 

>Sent: Thursday, February 15, 2007 6:58 PM
>Cc: [email-masked]; 'Sun, Dong (Dong)'; [email-masked]
>In this case, the PD-PE can use STR in place of ASR. If you 
>have been using RAR in the pull mode then you probably already 
>have an existing message used for authorization. If you do you 
>can re-use that.
>
>hope this helps,
>victor
>