Re: CARD and multiple ARs per AP?

19 November 2003 "Mani, Mahalingam (Mahalingam)" wrote:
> 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.

I can also imagine situations where the L2 infrastructure is owned by
a third party, such as an appartment building association, and made
available to multiple ISPs so that the individual customers do not
have to sign-up with the same ISP. (This case is similar to the
case with wired broadband access; the only difference would be that
we now have WLAN APs attached to the shared L2 infrastructure).

My wish would be that CARD would support architectures that make it
easier for customers to change ISPs. Limiting the architecure to
one AR per AP seems to prohibit some of the possibilities to
establish such access networks.

/J-O

> 
> 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: [email protected] [mailto:[email protected]] On Behalf
> Of
> > Jon-Olov Vatn
> > Sent: Tuesday, November 18, 2003 2:42 PM
> > To: [email protected]
> > 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:    [email protected]
> > 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
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/seamoby