RE: stds-802-mobility: RE: stds-80220-requirements: 802.1q/p
Just a thought, but the "5 criteria" in the 802 P&P include
the requirement to be compatible with 802.1 Bridging standards (which
includes 802.1Q). So any discussion of whether support for 802.1Q/802.1D
is in or out is moot - it is a requirement that you all signed up for
when you got the 802.20 PAR.
Regards,
Tony
At 14:43 20/02/2004, Mcginniss, Dave S [NTK] wrote:
I
have no issue with modifying the text to include requirements of these
other standards based technologies as well. Because others are
above l2 I don’t think it can be more than a statement of recommendation
and should be treated separately for those above l2. MPLS is an
interesting one it can be used for l2 or l3 and its requirement would be
a great addition to the standard.
David S. McGinniss
Distinguished Member of Technical Staff
Sprint Broadband Wireless Technology Development Group
(630) 926-3184
david.s.mcginniss@mail.sprint.com
-----Original Message-----
From: Branislav Meandzija
[mailto:bran@arraycomm.com]
Sent: Thursday, February 19, 2004 7:16 PM
To: Park Vincent; Mcginniss, Dave S [NTK]
Cc: stds-802-mobility@ieee.org
Subject: RE: stds-802-mobility: RE: stds-80220-requirements:
802.1q/p
Hi Vince,
We agree that the first
choice is to not include the requirement. However, if for whatever reason
the requirement should be included, it should either be generic without
naming switching technologies or should name at least the technologies
listed.
Branislav
- -----Original Message-----
- From: Park Vincent
[mailto:Park@flarion.com]
- Sent: Thursday, February 19, 2004 2:36 PM
- To: Branislav Meandzija; Mcginniss, Dave S [NTK]
- Cc: stds-802-mobility@ieee.org
- Subject: RE: stds-802-mobility: RE: stds-80220-requirements:
802.1q/p
- Hi all,
-
- Sorry for the delayed
response...just getting caught up on some backlogged emails.
-
- I actually think this
requirement should NOT be included (primarily, because it restricts the
architecture as the editor's note suggests).
-
- There are presently many
alternative solutions to support wholesale/retail separation in IP
networks and alternative solutions will continue to emerge. Several
approaches do not require any L2 switching support. Additionally, most
approaches can be viewed as being accomplished solely with higher layer
mechanisms (i.e., using signaling and header fields of packets that are
effectively opaquely carried as link layer payload). In my opinion,
including a requirement for L2 switching and/or tagging (especially with
a specific list of approaches) is overly restrictive. I also think that
this type of requirement is inappropriate, given that the backhaul
technology is essentially out of scope. Depending on the choice of
backhaul technology "L2 switching" may make zero sense.
-
- -Vince
-
- Vincent D. Park
- park@flarion.com
- Flarion Technologies Inc.
- Bedminster One
- 135 Route 202/206 South
- Bedminster NJ 07921
- -----Original Message-----
- From: owner-stds-802-mobility@majordomo.ieee.org
[mailto:owner-stds-802-mobility@majordomo.ieee.org]
On Behalf Of Branislav Meandzija
- Sent: Wednesday, February 18, 2004 11:51 AM
- To: Mcginniss, Dave S [NTK]
- Cc: stds-802-mobility@ieee.org
- Subject: stds-802-mobility: RE: stds-80220-requirements:
802.1q/p
-
- I think we need to capture
what you are saying in the requirement itself as otherwise it will be too
easy to misinterpret. I am appending what I believe is you are saying.
That is acceptable to us.
-
- Branislav
- -----------------------------------
- PROPOSED NEW TEXT
-
- 4.5.2 Layer 2
Switching
-
- 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.
-
- David S. McGinniss
- Distinguished Member of Technical Staff
- Sprint Broadband Wireless Technology Development Group
- (630) 926-3184
david.s.mcginniss@mail.sprint.com
-
-
-
- -----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
-
- Hi Dave,
-
- The current requirements
document text reads:
- ----------
- 4.5.2
802.1Q tagging
- 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.
-
- Branislav
-
-
- -----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
-
-
-
Regards,
Tony