802.1q tagging,
PPP, or MPLS 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).
-----Original
Message-----
From:
Mcginniss, Dave S [NTK]
[mailto:david.s.mcginniss@mail.sprint.com]
Sent: Wednesday, February 18,
2004 6:30 AM
To: Branislav Meandzija
Cc:
stds-802-mobility@ieee.org
Subject: RE:
stds-80220-requirements: 802.1q/p
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