Lwapp Mailing List: RE: [Seamoby] CARD and multiple ARs per AP?

[Mani, Mahalingam (Mahalingam) (mmani]

This discussion in SEAMOBY overlaps CAPWAP interest:

This many-many mapping variant of AP->AR is of additional interest to
CAPWAP which is about to get into the thick of varied AP->AR (it's
termed AC) architecture discussions - hopefully soon.

Is it in the interests of WiSPs to share a common AP infrastructure to
facilitate uniform roaming while having agreements to route appropriate
user traffic to relevant ACs? It does appear to make sense in dense
deployments of 11b/11g.

It seems like yet another case in point for policy enforcement in the AP
dataplane with policy decisions delivered by ACs from mgmt. plane.

-mani
> -----Original Message-----
> From: seamoby-admin [at] ietf.org [mailto:seamoby-admin [at] ietf.org] On 
> Behalf
Of
> Jon-Olov Vatn
> Sent: Tuesday, November 18, 2003 2:42 PM
> To: seamoby [at] ietf.org
> Subject: [Seamoby] CARD and multiple ARs per AP?
> 
> Hi!
> 
> I have a question regarding the CAR discovery protocol (CARD).
> 
> When I read the draft (draft-ietf-seamoby-card-protocol-04.txt) my
> understanding was that it allows an AR to have multiple APs attached,
> but not an AP to be attached to multiple ARs.
> I this the case? (Or did I just not read it carefully enough?)
> 
> If this is the case, is this imposed structural limitation made
> of some specific reason, e.g., for simplicity, or was it just
> unintentional? (I hope you forgive me for having missed any prior
> discussion on this matter.)
> 
> Background:
> -----------
> I could think of two situations where one would like to have multiple
> ARs per AP: if a WISP has two ARs for redundancy, or if several WISPs
> are sharing an access infrastructure (my own interest concerns the
> latter. This would lead to a many-to-many relationship between APs and
> ARs and a L2 ID would no longer uniquely point to an AR.
> 
> Perhaps I should explain what I mean with shared access
> infrastructures, since there are many ways to do it. If we consider
> 802.11 WLANs with 802.1X support, and a set of WISPs sharing an access
> infrastructure with briding APs (see the figure below) it is possible
> to use VLAN (or other tunneling techniques) between the APs and ARs to
> isolate the traffic for the different WISPs. The APs can map the
> traffic to/from the USER hosts to the WISP by adding/removing the
> appropriate VLAN tag.
> (For those interested I have written a paper which gives some more
> information about the architecture I anticipate): "A roaming
> architecture for IP based mobile telephony in WLAN environments",
> Stockholm Mobility Roundtable, 22-23 May 2003, Stockholm,
> Sweden. Available at
> http://www.it.kth.se/~vatn/research/roam-arch.pdf)
> 
>    WISP BACKBONE NETWORKS
>       ^           ^
>       |           |
>    +--+--+     +--+--+
>    |     |     |     |
>    |WISP1|     |WISP2|  ...
>    | AR1 |     | AR2 |
>    +--+--+     +--+--+
>       |           |                  Tunnels between each AP
>   ----+---+-------+--------+-------  and AR, e.g., using
>           |                |         VLAN tagging
>        +--+--+          +--+--+
>        |     |          |     |
>        | AP1 |          | AP2 | ...
>        |     |          |     |
>        +--+--+          +--+--+   APs act as 802.1X authenticators
>           |                |      Map traffic of each USER to the
>           o                o      VLAN associated with its WISP.
> 
>       o         o
>       |         |
>    +--+--+   +--+--+
>    |     |   |     |
>    |USER1|   |USER2|  .........
>    |     |   |     |
>    +-----+   +-----+
> 
> 
> Follow up question:
> -------------------
> Perhaps you disagree to the whole idea of supporting the case with
> multiple ARs per AP. Nevertheless, I have a follow-up question and it
> concerns the usage of the "Context-ID" if one could have more than one
> AR per AP.
> 
> The CARD draft uses the "Context-ID" field to map different
> sub-options to a specific AR. Together with the "MATCH Status-Code
> indication" the "Context-ID" can be used to avoid sending the CAR's
> address and capability information multiple times if two or more L2
> IDs resolve to the same AR.
> To enable for multiple ARs per AP I would suggest to use two context
> fields instead of the single "Context-ID" field. By this one could
> avoid sending one copy of each "L2 ID" sub-option for each attached
> AR. One of the two contexts fields would be common to the all ARs
> on the shared network ("LAN-context ID") and one is specific to the
> individual ARs ("AR-context ID"). The Address sub-option would contain
> both context ID fields, while "L2 ID" suboption would only contain
> "LAN-context ID" and the "Capability Container" suboption would only
> contain an "AR-context ID".
> Would this be a good thing?
> 
> The "LAN-context ID" could perhaps be based on a MAC-address of one of
> the attached ARs, using some election method similar to the "Root
> bridge election of the Spanning Tree algorithm" or the "Designated
> Router" election used by OSPF.
> 
> BW J-O
> 
> 
> ----------------------------------------------------------------------
> Jon-Olov Vatn                         Email:    vatn [at] it.kth.se
> Royal Institute of Technology         Address:  KTH-IMIT
> Dep. of Microelectronics and                    Isafjordsgatan 39
> Information Technology                                S-164 40 Kista
SWEDEN
> Telecommunication System Lab.         Fax:      +46 8 751 17 93
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Seamoby mailing list
> Seamoby [at] ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby