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