Looking at Wi-Fi and VLAN
Through the IPC Model
Leland Smith, Dan Cokely, Heather Bell, Lou
Chitkushev, John Day (Boston University)
• The topologist’s vision defect:
• can’t tell a coﬀee cup from a donut
• One look at WiFi and VLAN and one can see they looked remarkably similar.
• Both contain mulKple “layers” of the same rank over the same physical medium.
• MulKple VLANs over a single wired network
• MulKple WiFi networks in the same physical area share the same media
• WiFi especially has a PDU format that hints at 2 layers, e.g. the 4 addresses.
• Clearly creaKng a “logical Ethernet” over the physical
• Would a RINA characterizaKon of VLANs and WiFi:
• Be a signiﬁcant simpliﬁcaKon or improvement over the current approach
• Provide capabiliKes not currently available.
• Increased Commonality should improve manageability
• Understand the WiFi and VLAN standards
• Map them into the various aspects of the RINA model
• Create a Uniﬁed Model
• Conclusions and Future Work
Why So Many Addresses?
“Ethernet” btwn SRC/DEST
“Ethernet” btwn SRC/DEST
• In the general case, there may be forwarding across access points. So the first two addresses would be SNDR/RCVR
• and would change at every hop.
• Over the top is a logical Ethernet that is continuous with the Wired Ethernet connecting the last Access Point to the Router.
• So it has SRC (laptop) and DEST (the next hop, the Router). Hence 4 addresses are necessary in general.
• However, the most common configuration is a Laptop wirelessly associated with an Access Point connected to a Router/Cable
Modem. In this case, the SRC and SNDR addresses are the same, so only 3 addresses are necessary.
• (Note that in the general case, on the first hop Src and Sndr are the same; and on the last hop Rcvr and Dest are the same. So
the 3-address form could be used. In between all of the addresses are all different, so 4 are necessary.)
VLAN …and the 802.1 standards alphabet soup
• A layer-2 network parKKoned into mulKple disKnct broadcast
• Where domains are isolated from one another
• The domain is referred to as a Virtual Local Area Network (VLAN)
• ConﬁguraKon management – apply disKnct policies to diﬀerent
user groups on the network
• Traﬃc-ﬂow management – enforce QOS on a per VLAN basis
• Security – keep informaKon on a need to know basis; restrict
TPID – VLAN packet idenKﬁer
PCP (Priority Code Point) – frame priority eﬀort from 0 (best eﬀort) to 7 (highest priority)
DEI (Drop Eligible Indicator) – indicates whether frames are eligible to be dropped
VID (VLAN ID) – Unique idenKﬁer for the VLAN, up to 4k idenKﬁers (0x000 and 0xFFF are reserved)
PCP and DEI can be used in conjuncNon to determine QOS
Here a tag is introduced rather than using addresses to distinguish layers of the same rank.
Multiple addresses are not required because in a wired media is point-to-point so addresses are not needed.
802.1Q uses a single customer tag (C-TAG) to identify VLAN frames
802.1ad adds a service tag (S-TAG) before the C-TAG to perform “double-
tagging” or “VLAN stacking”
802.1ah adds an additional tag, B-TAG, along with a service identifier (I-
2.1 - Ethernet
2.1q - VLAN
2.1ah – MAC in MAC
2.1ad – Q in Q
This starts to get a bit
out of hand
Enrollment Allocation Data Transfer Layer Management Resource Management Network Management Security
1X : Port Based
work Access Control
1AR: Secure Device ID
1AB: link layer
802.1X: Port Based
Network Access Control
802.1AE: MAC Security
802.1Qah: MAC in MAC
802.1AQ: Shortest Path
802.1AD – Q in Q
802.1AH: MAC in MAC
802.1AJ: Two port MAC
802.1AS: Timing and
802.1BA: Audio /video
reservation protocol (SRP)
802.1AB: link layer discovery
802.1AD: SVLAN tags
802.1AK: Multiple VLAN
registration Protocol (MVRP)
802.1Qbe: Multiple Backbone
Service Instance Identifier
Registration Protocol (MIRP)
802.1Qbc: Provider Bridging
802.1Qbb: Priority based flow
transmission selection for
bandwidth sharing between
802.1Qbg: Edge virtual
802.1BR: Bridge Port
802.1OG: Secure Dat
802.1Qaw: DDCFM (D
Driven Connection Fa
… a uniﬁcaKon of WiFi and VLAN through the RINA model
The Uniﬁed Model: WiLAN
• There has to be disKnct “media DIFs” for wired and wireless.
• One or more “common” DIFs operaKng over the media DIFs.
• Reality: Wired Ethernet as a mulK-access media no longer exists.
• Hubs are obsolete.
• Hence Ethernet is point-to-point
• Without port-ids, tradiKonal Ethernet alone is an ill-formed layer.
• Compromises layer separaKon. With them, Ether-type can be eliminated.
• With LLC, it is a beier-formed layer, however, DL-SAPs combine port-id and CEP-id.
• MAC addresses are bad address pracKce and have become a major security problem.
• Experience has shown that as long as they are globally unique the temptaKon to use them for
purposes they were not intended is too great.
• Addresses should only large enough for the scope of the layer they are used in.
• 16 bits is plenty, 12 would do.
• Addresses should be assigned as part of enrollment when joining a layer
• The Wired Media DIF is point-to-point between a staKon or bridge and another
– Hence, this DIF does not need addresses, but does need CEP-ids and port-ids.
• OTOH, the wireless-media DIF needs both addresses and CEP-ids.
– Because mulKple wireless networks may exist in the same media space.
• This is the major diﬀerence.
Wired Media DIFs
Wireless Media DIF
Data Transfer Data Transfer Control Management
2.11n (8 bit delimiter in A-
PDU) OpKonal or other
op & Wait
aying & MulNplexing
2.11ac or other policy
2.11n (8-bit CRC carried
er to 802.11ac) or other
DCF (RTS,CTS, NAV)
● Beacon Frames
● Channel/power set
● Radio Resource AllocaKon
● PMD and PLCP
● Probe request/response
Wireless Policies Under IPC
The Big Difference Here is Contention for the Media,
which doesn’t exist in the Wireline case.
No point re-inventing the wheel
Joining a wireless network
• 0 DIF exists to control access to the medium
• In the case of wireless this is an open medium where any station
can listen as well as transmit
• Joining this DIF is not about authenticating as much as it is about
coordination with stations and access points to access the medium
• Using an adaptation of 802.11’s Open System Authentication we
can achieve a similar result
• Process: finding a network to join, syncing configuration,
• Potential contention with randomly created addresses
Wired Media DIF
Point to Point connecKon
• No need for addresses
• ConnecKon End Point IDs (CEP-ID)
• EFCP – no ACK
• Enrollment – not necessary (conﬁgured by management,
but could be added)
Wireline Frame Format
CRC (Cyclical Redundancy Check) - Frame protecKon - ensures frame was delivered without error
QOS (Quality of Service) - QOS cube deﬁning policy
DST CEP-ID (DesKnaKon ConnecKon End-point ID)
SRC CEP-ID (Source ConnecKon End-point ID)
PAYLD (Payload) - User data
Addresses - No address necessary; point-to-point connecKon
Lies above the media DIFs
• Requires addresses and CEP-ID
• Addresses are assigned when joining the layer
• Address length for DIF is based upon scope of the layer
• The two Common DIFs are examples of what would be Q-in-Q or Mac-in-Mac
The Rest of the
Network Bridged Subnet
Common DIF Frame Format
• Typical frame format, but this could be any RINA DIF, so ﬁeld sizes could vary
depending on the environment.
• Address ﬁeld varies on size of DIF
o e.g. upper layer DIF for a Comcast network may need 32-bit address
o while local storage area network may only require 12-bit address (not
connected to the world!)
Header overhead is reduced 55% for wireless and 25% for wired.
• Wireless 3*48 vs 4*16; Wired 2*48+12 vs 2*8 + 4*16
• This is a swag. We need to sharpen the pencil on it.
Removing the MAC addresses from the frame provides more protecKon and security.
taKons can belong to more than one VLAN. That is coming from the isolated scope
QoS can be enforced all the way to the media.
• It remains to work out complementary policies across a set of DIFs.
he media speciﬁcs are minimized, even the wired media DIF is more a degenerate DIF than a special case.
MAC-in-MAC and Q-in-Q can be eliminated. (They are inherent in the RINA model)
ag space problems are eliminated. Common DIFs can have any address length they need.
Having common DIFs simpliﬁes both network design and management. That means fewer and simpler protocols
ewer IPv4 and IPv6 problems because the addresses are seen just within their scope
iminate the need to for registraKon authoriKes for MAC addresses and Ethertypes,
QuesKonable whether one is necessary for device serial numbers.
What Would Be Standardized?
• Most of the arguments in a standards committee are over the “policies” to be included. In RINA, the policies are standardized but
• The Policies would be registered in a Policy Catalog or Store.
• Policies could be free or charged for, public or proprietary.
• The Protocols would be RINA standards: EFCP for data transfer and CDAP for Management
• Implementations exist and are being tested
• Standardize (or already are) the wireless media access contention resolution Protocols, generalizing 802.11 as the common
approach for wireless.
• Use the existing Physical Layer Standards.
• DIFs would be defined more as “profiles” or “proformas” rather than as standards
• Header format is selected from a set of concrete syntaxes, i.e. it is policy.
• The RIB (MIB) is mostly standardized, with break-outs for product specifics.
• Common RIB is crucial to effective management, and with common DIFs this is easy.
• Address length and assignment is associated with a specific layer configuration, so it is policy
• Security are policies for enrollment and SDU protection.
• Might standardize common CDAP sequences, such as for enrollment.
• Bottom Line: Not Much
What We Learned
• Simplicity is always the best way to solve even complex problems
• To solve any problem, consider the point of view of the organism view not the observer
• Similar to real life, network addresses should be locaKon dependent (and route independent)
• Addressing and naming is easier using connecKon-end point Ids (CEP-IDs)
• It is signiﬁcant to connect processes rather than machine interfaces
• CreaKng a secure container (the DIF) is stronger and simpler than applying security individually and
• Why do we have diﬀerent soluKons for one problem?
• Not necessarily that all current soluKons are the best soluKons
• The best way to test a theory is at the edges: the “corner cases”
• VLAN and Wiﬁ could be uniﬁed and recast in the IPC model used by RINA
• Good Correspondence between the IPC phases (Enrollment, AllocaKon, and Data Transfer) and Ethernet
• Instead of using diﬀerent layers with diﬀerent funcKons, a single layer with common funcKons and repeat it
• The RINA model greatly simpliﬁes operaKons, management, scalability, security, hardware, and soxware
• Need to Explore the Apparent ContradicKon in VLANs
o IPC Model says layers are ranges of resource allocaKon
o VLANs say they are logical separaKon
o Implies staKc resource allocaKon at the media
o IndicaKons that 802.1 sees this
• Harvest policies from 802 specs
• Very interested in SPB update approach
• Specify the two media DIFs
• Explore implementaKon possibiliKes.
• Simulate QoS policies and rouKng behavior
Parece que tem um bloqueador de anúncios ativo. Ao listar o SlideShare no seu bloqueador de anúncios, está a apoiar a nossa comunidade de criadores de conteúdo.
Atualizámos a nossa política de privacidade.
Atualizámos a nossa política de privacidade de modo a estarmos em conformidade com os regulamentos de privacidade em constante mutação a nível mundial e para lhe fornecer uma visão sobre as formas limitadas de utilização dos seus dados.
Pode ler os detalhes abaixo. Ao aceitar, está a concordar com a política de privacidade atualizada.