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