RE: stds-80220-requirements: 802.1q/p
Dave,
> Your are right it is my view of future network architecture.
There are several different equally viable views and that is exactly the reason
why the group decided 6 months ago to stay out of network architecture. The
802.20 PHY/MAC interface can then easily be incorporated into different types
of network architectures (including VLAN) but without prematurely betting the house
on a particular network technology and restricting the applicability of the
standard.
>I am not asking for a hard requirement despite the
> significant value added in my opinion.
I understand that. However, anything that is any type of a requirement here would
just open the pandora's box for all other types of network architecture requirements
that are equally viable in someone else's view and would only distract us from our
goal of evaluating different PHY/MAC proposals and standardizing PHY/MAC.
Branislav
> -----Original Message-----
> From: Branislav Meandzija [mailto:bran@arraycomm.com]
> Sent: Tuesday, November 18, 2003 19:04
> To: Mcginniss, Dave S [GMG]; stds-80220-requirements@ieee.org
> Subject: RE: stds-80220-requirements: 802.1q/p
>
>
> David,
>
> Just wanted to reiterate and further clarify the reasoning behind the
> proposed deletion of "4.5.2 802.1Q/P tagging".
>
> The essence of the argument why not to mandate 8021Q/P is that we have
> decided a while ago to keep 802.20 network architecture
> agnostic. One of
> the reasons for that decision was to speed up standard
> development while
> broadening the applicability of the standard to multiple environments,
> existing and emerging.
>
> The IEEE 802.1Q standard defines the operation of VLAN Bridges that
> permit the definition, operation and administration of Virtual LAN
> topologies within a Bridged LAN infrastructure. The IEEE's 802.1Q
> standard was developed to address the problem of how to break large
> networks into smaller parts so broadcast and multicast
> traffic would not
> grab more bandwidth than necessary.
>
> The reasoning you gave below to why 802.1q/p should be required for
> 802.20 is "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."
> The way the
> network agnostic argument applies here is that for example in a
> traditional access network (e.g. DSL or 3GPP2) a PPP session
> (associated
> with the Network Access Identifier - NAI, which is exchanged
> in the LCP
> PPP phase) would be used to switch network egress traffic at
> the Network
> Access Server (NAS) to the appropriate L2 termination device for
> managing backbone traffic or distinguishing traffic for wholesale
> partners in a wholesale environment. If we were to require 802.1q/p or
> use it as an evaluation criteria in 802.20, solutions supporting the
> more common PPP access networks would be prohibited or unnecessarily
> disadvantaged, thus limiting the scope of 802.20. Given the
> multitude of
> infrastructure equipment that support the PPP based network access
> paradigm (e.g. NAS, AAA, etc), that would unnecessarily prevent 802.20
> from also being deployable in readily available and
> economically viable
> PPP network access architectures.
>
> Similarly, 802.1p and its 8 level of priority mimics IP
> precedence level
> and is extraneous in light of the DiffServ requirements we adopted.
>
> Hope that this will now lay this issue finally to rest as
> agreed a long
> time ago and allow us to focus our energy on the remaining open items.
>
> Best regards,
>
> 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
>
>