I don’t understand
your argument. Support of these 802 standards do exactly what you want
offer the flexibility to support an architecture other than PPP or MPLS.
I am not saying that it will be the only mechanism to do so. In
fact MPLS would in fact be preferred in current designs I have been
evaluating. If there is no support for these standards it precludes the
use for purpose I have offered as reasons for their usage. I just feel
support for these 802 standards should not be overlooked by
802.20.
-----Original
Message-----
From: Branislav
Meandzija [mailto:bran@arraycomm.com]
Sent: Tuesday, February 17, 2004 8:10
PM
To: Mcginniss, Dave S
[NTK]
Subject: RE:
stds-80220-requirements: 802.1q/p
The
current requirements document text reads:
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).
Which is even way
more in conflict with the "agnostic network architecture" argument
than even your proposal which I am appending below. I am sure you understand
our argument that using something like PPP (as we are) or MPLS would do the
job just as well. How can we put this one to rest without mandating a network
architecture solution? I understand Sprint really has decided
on 802.1q tagging, but that is something you guys can specify in an RFI
fro a particular deployment. Others prefer PPP based solutions. So, it would
really be unfair and unreasonable for the standard to eliminate
those.
-----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