Subject: [Capwap] Handover issue

From: Behcet Sarikaya <[email-masked]>
Date: Sat, 11 Mar 2006 15:07:15 -0600

Dear all,
  It seems that any WTP to AC (which is a Layer 3 entity) is within the 
scope and this involves the roaming related exchanges WTP and AC would have.
  The chairs asked me to invite people to spare some comments, so here 
are some points.
  The draft on CAPWAPHP:
http://www.ietf.org/internet-drafts/draft-sarikaya-capwap-capwaphp-01.txt
handles handovers in such a way that in most cases the handover is 
anchored at the AC. As you can see from the scenarios for local and 
split MAC WTPs, most of the exchanges involve WTP and AC. CAPWAPHP 
features include:
- designed to be integrated into CAPWAP protocol
- STA context transfers using RFC 4067 needed for local MAC WTPs
- L2 Update frames needed for DS
- ensures that STA is associated with a single WTP
the last two unnecessitates 802.11f which is now defunct.
  So, in short, the draft is in scope, but maybe I am biased?
 
  Kind regards,

--behcet

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Mani, Mahalingam (Mani)" <[email-masked]>
Date: Mon, 13 Mar 2006 14:40:25 -0700

Behcet,

CAPWAP does not decide how to roam but tells how the CAPWAP specifies
division of labor between WTP and AC in course of BSS transitions. Hence
section 11.2 is in scope.

The charter or agreed architectural objectives does not include context
transfers by CAPWAP between 'AP's - except: much of the context of
conventional AP is now already resident in AC and changes the scope of
an "inter-AP" transfer.

AC-AC context transfer also remains out of scope - though it is a worthy
problem as well for mobility considerations.

Your draft's overview section says
"For both Local and Split MAC WTPs, authentication is based on IEEE
   802.11i.  Full 802.11i authentication is carried for the first time
   association of the stations.  CAPWAPHP transfers AAA context to the
   neighbor Local MAC WTPs so that when the station reassociates with a
   neighbor WTP, only 4-way handshake of 802.11i authentication can be
   carried."

The relevance of this to the follow-up 802.11r and subsequent local-MAC
division of labor changes quite a bit. 802.11r optimizes intra-ESS
security transitions (and some related contexts) and is about to resolve
how to do so in the backend. It does not amount to plain context
transfer - but (security)context-derivation for the target and that too
not necessarily from deleted-mobile to added-mobile.

We have suggested pursuing discussions on the list as well to gauge WG
opinion if this draft shows up required functionality missing from what
is already provided.

If time permits (earlier agenda items do not eat up available time) - we
should be able to accommodate a short presentation at IETF65.

Regards,
-mani
-----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Friday, March 10, 2006 11:20 AM
To: [email-masked]
Subject: [Capwap] Handover issue

Dear all,
  I would like to raise this issue within the framework of the draft we 
submitted to CAPWAP. I already raised it with the chairs.
  The issue is whether roaming/ handover is within the scope of CAPWAP.
I checked with the latest protocol spec :
http://www.ietf.org/internet-drafts/draft-ietf-capwap-protocol-specifica
tion-00.txt
in Sec. 11.2 there is a discussion of roaming stations.
  If the roaming is out of scope, I suggest that all roaming references 
be removed from the spec and this issue be left to further work.
  If the roaming is in the scope then I'll appreciate comments on our
draft
http://www.ietf.org/internet-drafts/draft-sarikaya-capwap-capwaphp-01.tx
t
which presents a more comprehensive solution.
Regards,

--behcet

---

From: Michael Montemurro <[email-masked]>
Date: Thu, 16 Mar 2006 12:43:56 -0500

I've created a new feature request issue on the issues list. The issue
number is 79.

Cheers,

	Mike 

> From: Mani, Mahalingam (Mani) [mailto:[email-masked]] 
> Sent: March 13, 2006 4:40 PM
> To: Behcet Sarikaya; [email-masked]
> Subject: RE: [Capwap] Handover issue
> 
> Behcet,
> 
> CAPWAP does not decide how to roam but tells how the CAPWAP 
> specifies division of labor between WTP and AC in course of 
> BSS transitions. Hence section 11.2 is in scope.
> 
> The charter or agreed architectural objectives does not 
> include context transfers by CAPWAP between 'AP's - except: 
> much of the context of conventional AP is now already 
> resident in AC and changes the scope of an "inter-AP" transfer.
> 
> AC-AC context transfer also remains out of scope - though it 
> is a worthy problem as well for mobility considerations.
> 
> The relevance of this to the follow-up 802.11r and subsequent 
> local-MAC division of labor changes quite a bit. 802.11r 
> optimizes intra-ESS security transitions (and some related 
> contexts) and is about to resolve how to do so in the 
> backend. It does not amount to plain context transfer - but 
> (security)context-derivation for the target and that too not 
> necessarily from deleted-mobile to added-mobile.
> 
> We have suggested pursuing discussions on the list as well to 
> gauge WG opinion if this draft shows up required 
> functionality missing from what is already provided.
> 
> If time permits (earlier agenda items do not eat up available 
> time) - we should be able to accommodate a short presentation 
> at IETF65.
> 
> Regards,
> -mani
>   I would like to raise this issue within the framework of 
> the draft we submitted to CAPWAP. I already raised it with the chairs.
>   If the roaming is out of scope, I suggest that all roaming 
> references be removed from the spec and this issue be left to 
> further work.
>   If the roaming is in the scope then I'll appreciate 
> comments on our draft

---

From: Michael Montemurro <[email-masked]>
Date: Mon, 27 Mar 2006 10:37:42 -0500

I totally agree that we have way too much work to do to get the base CAPWAP
protocol published as an RFC, and we should consider AC-AC communications
should be out-of-scope for this submission.

Cheers,

	Mike

> From: Darren [mailto:[email-masked]] 
> Sent: March 24, 2006 12:13 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Capwap] Handover issue
> 
> At IETF65 I heard a couple of suggestions that a CAPWAP 
> roadmap document should be written.  Given the number of good 
> ideas and additional requirements popping up, it seems clear 
> there is going to be need for CAPWAP development for the next 
> several years.
> 
> In order to have a completed capwap version 1 protocol this 
> year, we need to finish a specification for only the most 
> basic features.
> 
> Extensions to the core capwap protocol version 1 can be 
> planned and debated as part of a roadmap document. I also 
> strongly believe that AC
> - AC communications is important, but it is out of scope for 
> version 1 of CAPWAP and it should be a roadmap item.
> 
> -Darren Loher
> 
> 
> On 3/23/06, Pat Calhoun (pacalhou) <[email-masked]> wrote:
> > Behcet, I believe that I claimed that 802.1X authentication 
> works for 
> > both local and split MAC. In both cases, the 802.11 MAC management 
> > packets, and 802.1X, need to be forwarded to the AC for centralized 
> > authentication.
> >
> > Moving across ACs is out of scope for CAPWAP.
> >
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit Cisco Systems
> >
> >
> >
> > > Sent: Monday, March 20, 2006 4:37 PM
> > > To: [email-masked]
> > > Subject: Re: [Capwap] Handover issue
> > >
> > > Dear all,
> > >   Before we forget, I wanted to wrap up the issues arising
> > > from today's
> > > presentation:
> > > - Puneet's question on roaming, STA roaming not WTP roaming
> > > is what we are trying to do
> > > - France Telecom colleague's question on the relationship
> > > with NEMO, NEMO and MIP try to provide the session
> > > continuity, i.e. try to keep the same IP address so that the
> > > sessions do not break after handover. This is not what
> > > CAPWAPHP is after. We are interested in roaming support that
> > > is needed to be included in the CAPWAP protocol.
> > > - Pat mentioned that he was concerned on our model for Local
> > > MAC roaming handling in CAPWAPHP.
> > > - Pat claimed that the Split MAC solution is already in
> > > CAPWAP protocol, however, of the two scenarios we have in
> > > CAPWAPHP only one of them is partially covered in CAPWAP.
> > >  - Pat asked on inter-AC roaming, here the roaming scenario
> > > is where STA moves from a WTP in one domain, e.g. Verizon to
> > > a WTP in another domain, e.g. T-Mobile.
> > >   Have I missed anything?
> > >
> > > Regards,
> > >
> > > --behcet

---

From: "Saravanan Govindan" <[email-masked]>
Date: Tue, 28 Mar 2006 08:59:57 +0800

Hi Darren,

I like the idea of having a separate roadmap document. There are a
number of features being introduced now that deserves greater review
after the base specifications are completed.

For the time being, the group can consider using a separate tracker that
lists these newly introduced features. This will help separate them from
the more pressing immediate bugs/features of the protocol.

Cheers,

Saravanan

-----Original Message-----
From: Darren [mailto:[email-masked]] 
Sent: Saturday, March 25, 2006 1:13 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Capwap] Handover issue

At IETF65 I heard a couple of suggestions that a CAPWAP roadmap
document should be written.  Given the number of good ideas and
additional requirements popping up, it seems clear there is going to
be need for CAPWAP development for the next several years.

In order to have a completed capwap version 1 protocol this year, we
need to finish a specification for only the most basic features.

Extensions to the core capwap protocol version 1 can be planned and
debated as part of a roadmap document. I also strongly believe that AC
- AC communications is important, but it is out of scope for version 1
of CAPWAP and it should be a roadmap item.

-Darren Loher

On 3/23/06, Pat Calhoun (pacalhou) <[email-masked]> wrote:
> Behcet, I believe that I claimed that 802.1X authentication works for