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