RE: stds-80220-requirements: 802.1q/p
I suspect you do not envision providing services in a clientless service
model. Sprint would not like to force such network architecture and
would not like to deploy such a model. Enabling 802.1Q/p tagging makes
the 802.20 product more flexible. Those who chose not to use it can
make that decision. I think if it were there most operators would use
it to partition signaling and management functions at the very least.
Your are right it is my view of future network architecture. The fact
that you envision doing this with ppp is fine this would not work for
Sprint ppp is added with a client on the PC this is not our vision.
Tagging will also help enable traffic classifier's like Allot's to view
traffic by sector. I am not asking for a hard requirement despite the
significant value added in my opinion. As to the p option it enables
layer 2 QoS. P is of less value. PPP also increases overhead.
David S. McGinniss
Sprint Broadband Wireless Group
Principal Engineer II
(630) 926-3184
david.s.mcginniss@mail.sprint.com
-----Original Message-----
From: Branislav Meandzija [mailto:bran@arraycomm.com]
Sent: Tuesday, November 18, 2003 19:04
To: Mcginniss, Dave S [GMG]; stds-80220-requirements@ieee.org
Subject: RE: stds-80220-requirements: 802.1q/p
David,
Just wanted to reiterate and further clarify the reasoning behind the
proposed deletion of "4.5.2 802.1Q/P tagging".
The essence of the argument why not to mandate 8021Q/P is that we have
decided a while ago to keep 802.20 network architecture agnostic. One of
the reasons for that decision was to speed up standard development while
broadening the applicability of the standard to multiple environments,
existing and emerging.
The IEEE 802.1Q standard defines the operation of VLAN Bridges that
permit the definition, operation and administration of Virtual LAN
topologies within a Bridged LAN infrastructure. The IEEE's 802.1Q
standard was developed to address the problem of how to break large
networks into smaller parts so broadcast and multicast traffic would not
grab more bandwidth than necessary.
The reasoning you gave below to why 802.1q/p should be required for
802.20 is "Tagging will support the L2 switching such that network
egress traffic can be switched by a L2 device to the appropriate L2
termination device for managing backbone traffic or distinguishing
traffic for wholesale partners in a wholesale environment." The way the
network agnostic argument applies here is that for example in a
traditional access network (e.g. DSL or 3GPP2) a PPP session (associated
with the Network Access Identifier - NAI, which is exchanged in the LCP
PPP phase) would be used to switch network egress traffic at the Network
Access Server (NAS) to the appropriate L2 termination device for
managing backbone traffic or distinguishing traffic for wholesale
partners in a wholesale environment. If we were to require 802.1q/p or
use it as an evaluation criteria in 802.20, solutions supporting the
more common PPP access networks would be prohibited or unnecessarily
disadvantaged, thus limiting the scope of 802.20. Given the multitude of
infrastructure equipment that support the PPP based network access
paradigm (e.g. NAS, AAA, etc), that would unnecessarily prevent 802.20
from also being deployable in readily available and economically viable
PPP network access architectures.
Similarly, 802.1p and its 8 level of priority mimics IP precedence level
and is extraneous in light of the DiffServ requirements we adopted.
Hope that this will now lay this issue finally to rest as agreed a long
time ago and allow us to focus our energy on the remaining open items.
Best regards,
Branislav
-----Original Message-----
From: owner-stds-80220-requirements@majordomo.ieee.org
[mailto:owner-stds-80220-requirements@majordomo.ieee.org]On Behalf Of
Mcginniss, Dave S [GMG]
Sent: Monday, November 17, 2003 8:08 AM
To: stds-80220-requirements@ieee.org
Subject: stds-80220-requirements: 802.1q/p
4.5.2 802.1Q/P tagging (open)
Editors Note: This section is proposed for deletion because this is tied
a specific network architecture.
Current text
[802.1Q tagging must be supported by the system (such that network
egress traffic can be switched by a L2 device to the appropriate L2
termination device for managing backbone traffic or distinguishing
traffic for wholesale partners in a wholesale environment).]
Proposed Text
802.1q tagging should be supported by the 802.20 system or some other
mechanism (i.e. policy routing). Tagging will support the L2 switching
such that network egress traffic can be switched by a L2 device to the
appropriate L2 termination device for managing backbone traffic or
distinguishing traffic for wholesale partners in a wholesale
environment. Tagging can also be used to facilitate a retail captive
portal service model. By tagging traffic from a mobile terminal that is
unknown (i.e. mobile terminal is un-provisioned) it can be switched at
L2 to a system enabling a self provisioning system model. By tagging
control and management traffic it to can be switched and separated as
close to the base station as possible. All of these can be accomplished
at a higher layer but are simpler to implement if 802.1Q tagging is
supported.
802.1p
The 802.1Q standard specifies that tags be appended to a MAC frame. The
VLAN tag carries VLAN information. The VLAN tag has two parts: The VLAN
ID (12-bit) and Prioritization (3-bit). The 802.1P implementation
defines the prioritization field. 802.1p defines a 32-bit tag header
that is inserted after a frame's normal destination and source address
header info. Switches, routers, servers, desktop systems, mobile
terminals, or base stations can set these priority bits. Switches and
routers can prioritize traffic based on these tags.
Rational
By driving these functions to layer 2 a provider can build a flatter
network supporting simple IP handoff over a larger 802.20 coverage area.
These functions can be supported in other ways at a higher layer but are
most efficiently handled at layer 2. The evaluation criteria group
should report support for tagging so that the 802.20 group can factor
support in the selection process.
David S. McGinniss
Sprint Broadband Wireless Group
Principal Engineer II
(630) 926-3184
david.s.mcginniss@mail.sprint.com