Hybrid-MAC Model for CAPWAP
draft-shao-opsawg-capwap-hybridmac-00
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Chunju Shao , DENG Hui , Farooq Bari , Rong Zhang , Satoru Matsushima | ||
| Last updated | 2013-08-21 (Latest revision 2013-02-17) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
The CAPWAP protocol supports two modes of operation: Split and Local MAC (medium access control), which has been described in [RFC5415].There are many functions in IEEE 802l.11 MAC layer that have not yet been clearly defined whether they belong to either the AP (Access Point) or the AC (Access Controller)in the Split and Local modes. Because different vendors have their own definition of these two models, depending upon the vendor many MAC layer functions continue to be mapped differently to either the AP or AC. If there is no clear definition of split MAC and local MAC, then operators will not only need to perform vendor specific configurations in their network but will continue to experience difficulty in interoperating APs and ACs from different vendors.
Authors
Chunju Shao
DENG Hui
Farooq Bari
Rong Zhang
Satoru Matsushima
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)