Subject: RE: PAA-EP protocol requirements

From: <[email-masked]>
Date: Tue, 29 Oct 2002 14:01:09 -0600

>Three comments.
>
>First, it would be better for the requirement draft to include the
>definition of EP which is described in the usage scenarios draft.

Yes. We need to ensure that all PANA terminology is captured in the
requirements I-D.

>
>Second, I agree that push model (pusing information from PAA to EP)
>should be used for the communication between PAA and EP.  On the other
>hand, it might be good to have an explicit statement on optional usage
>of event notification in the push model in which EP MAY inform PAA
>when a new device is connnected to the network, which was discussed
>recently on the mailing list and no one seemed to have objected to
>it.

Why should the EP trigger a notification to the PAA? What would cause
the EP to send this trigger and what do you expect to happen as a
result of this trigger? Sorry if I missed the discussion. I do not
believe that this is required in the scope of PANA. 

>
>Third, the protocol used between PAA and EP should be able to detect
>inactive peer within an appropriate time period and delete the related
>states.  (Then what is the required time scale for detecting inactive
>peer?)

The protocol between the PAA and EP is simply expected to authorize
access for a PaC at the EP. I think additional complexity or
requirements are unwarranted for the PAA-EP protocol. PANA itself has
a requirement for detecting idle or inactive clients. This would imply
that the PAA would probably have some mechanism (ping?) to detect
inactive PaCs. I think what you are suggesting here is that the EP is
aware about the (in)activity of a PaC and should indicate the same to
the PAA. Is this really required. I guess it would optimize the
protocol since the PAA would not be required to poll the PaC itself to
determine if the PaC was still connected to the network.

>Regards,
>Yoshihiro Ohba

-Basavaraj

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 29 Oct 2002 15:27:01 -0500

> believe that this is required in the scope of PANA. 

I attached the related email discussions on this issue.

> determine if the PaC was still connected to the network.

There is some misunderstanding here.  
Please see my response to Alper.

Yoshihiro Ohba

Subject: Re: Separation of PAA and Access router (multi access router scenario)
From: Prakash J <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Mon, 30 Sep 2002 23:21:50 -0700

[email-masked] wrote:
> 
> >
> > Maybe the question is. Does the exactly same packet
> > message need to be sent to all ARs? Because even if
> > you multicast a message, some nodes might receive it
> > later, some nodes might not receive it, etc, etc.
> >
> > So you cannot guarantee total synchronicity, right?
> 
> Yes.
> 
> >
> > I think what you can guarantee is that all ARs will
> > receive the message within a time window. We can rely
> > on retransmissions to detect a downed AR.
> 
> I think this is sufficient for PANA. Is this acceptable
> to WG members?

How will an AR that went down and came back up, or an AR
that is being introduced in the network resync  with the PAA?
In general terms, is there a provision or some other mechanism
(from other working groups) for the EP to learn the policies currently 
in effect on that access network? 

- prakash

> > Reinaldo
> -BP

Subject: RE: Separation of PAA and Access router (multi access router scenario)
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Tue, 1 Oct 2002 10:00:47 -0500

> > > I think what you can guarantee is that all ARs will
> > > receive the message within a time window. We can rely
> > > on retransmissions to detect a downed AR.
> > 
> > I think this is sufficient for PANA. Is this acceptable
> > to WG members?
> 
> How will an AR that went down and came back up, or an AR
> that is being introduced in the network resync  with the PAA?
> In general terms, is there a provision or some other mechanism
> (from other working groups) for the EP to learn the policies 
> currently 
> in effect on that access network? 

Maintain some state in the PAA.

> - prakash

-Basavaraj

Subject: RE: Separation of PAA and Access router (multi access router scenario)
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Wed, 2 Oct 2002 10:37:53 -0500

The pull-approach to allowing access is one possible solution.
But every time the client changes the DR, the new AR has to 
poll the PAA. There may be an issue of delay as a result of
having to poll the PAA every time. 
So your approach works, but may not be the most optimal.

-Basavaraj

> > The intent is to find a solution via an existing protocol.
> > But when you have a one-to-many relationship (PAA-ARs),
> > do any of these protocols allow you to send the authorization
> > information to all ARs synchronously? Is it important to do
> > it so (synch?) or does the PAA send authorization messages to all
> > ARs in a sequential manner or maybe use the all routers multicast
> > address?
> 
> Hi everybody.
> 
> I was considering to solve this problem without sending the 
> authorization
> to all ARs by PAA.
> Can anybody take a look at and give the comments to  the 
> following scheme?
> Thanks.
> 
> fan zhao

> When PaC wants to access Internet, it has to do 
> authentication with PAA
> firstly.
> If the authentication succeeds, PAA will generate some lease, which
> regulates
> how long PaC can access  the Internet before re-authentication.
> 
> Then PaC sends the packets to Internet as usual way, the 
> packets will be
> intercepted
> by one of the EP(AR) depending on which AP is chosen as the 
> default router
> by PaC.
> 
> Then EP(AR) receiving such packet sends requests to PAA to 
> check if it is
> valid to let the packet
> pass through or not. PAA can send the lease or denial back to 
> EP(AR). So
> after that, EP(AR)
> can cache the lease locally to filter the following packets.
> 
> So if PaC dosen't do authentication with PAA at first, EP can 
> not let the
> packet go.
> Also this scheme doesn't require that PAA send authorization 
> to every AR.
> 
> 
> 

Subject: RE: Separation of PAA and Access router (multi access router scenario)
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Wed, 2 Oct 2002 13:26:40 -0500

> 
> I think we might need both actually. A general rule
> would be to push from the PAA to the EPs. However, 
> the protocol should also allow for a pull to allow 
> for the case of an EP crashing then coming up
> again. 

Agreed.

> Hesham

Subject: RE: Separation of PAA and Access router (multi access router scenario)
From: Reinaldo Penno <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Wed, 2 Oct 2002 11:47:13 -0700 (PDT)

agreed also.

--- [email-masked] wrote:
> > 
> > I think we might need both actually. A general
> rule
> > would be to push from the PAA to the EPs. However,
> 
> > the protocol should also allow for a pull to allow
> 
> > for the case of an EP crashing then coming up
> > again. 
> 
> Agreed.
> 
> > 
> > Hesham
> 

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com