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

[Singh Ajoy-ASINGH1 <[e-mail]>]

Hello Jon,
Sorry for late reply. 
Please see my inline reply.
Regards,
Ajoy 

-----Original Message-----
From: Jon-Olov Vatn [mailto:[e-mail]] 
Sent: Tuesday, November 18, 2003 4:42 PM
To: [e-mail]
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?)

AJOY-> This was not the intent. 

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.


AJOY-> 
We have simpler way to resolve this issue. We think it may be enough to include CAR IP address as one of the capabilities of the capability container sub-option. As long as the combination of the context-id and CAR IP  is unique, MN will be able to correctly decode the CARD reply and extract capabilities associated with various CAR(s) serving single AP. Please let us know if you see any problem with approach. This approach does not require any change of existing message format. 


BW J-O


----------------------------------------------------------------------
Jon-Olov Vatn                         Email:    [e-mail]
Royal Institute of Technology         Address:  KTH-IMIT
Dep. of Microelectronics and                    Isafjordsgatan 39
Information Technology                		S-164 40 Kista  SWEDEN
Telecommunication System Lab.         Fax:      [phone]






_______________________________________________
Seamoby mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/seamoby

_______________________________________________
Seamoby mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/seamoby