-----Original
Message-----
From: Klerer Mark
[mailto:M.Klerer@flarion.com]
Sent:
Monday, August
04, 2003
5:09
PM
To: Marianna Goldhammer;
Chickinsky, Alan; Stds-80220-Requirements (E-mail)
Subject: RE:
stds-80220-requirements: Higher Layer Services, Reference Mod
el
Alan, et
al
I agree
with the quote Mariana brought from the 5 Criteria template.
When we developed
the 5 Criteria we discussed
such concerns and in the compatibility section we have the
following statement:
Compatibility
will be addressed during development of the
standard
and any variance that may be required will be
clearly identified
and justified. (
802.20 -
PD-03
)
We fully
anticipated that some items that make sense in a pure LAN
environment may not be appropriate in an access
network.
Regards,
Mark
-----Original
Message-----
From: Marianna Goldhammer [mailto:marianna.goldhammer@alvarion.com]
Sent:
Monday,
August 04, 2003
9:43
AM
To:
Chickinsky, Alan; Stds-80220-Requirements (E-mail)
Subject:
RE: stds-80220-requirements: Higher Layer Services, Reference
Mod el
Alan,
ALL,
This
discussion comes back to the "Reference Model". I
hope
that
everybody realized, from the excellent Michael input
(below),
that
mandating 802.1q is not
appropriate:
"I therefore propose to not include a specific mandate to
support
802.1Q just as it would be inappropriate to mandate the use
of
MPLS, PPP, or PPP/MPLS which could be used to satisfy the
same
functional requirements."
The
Michael argumentation:
" allowing operators to use existing network infrastructure in
support of 802.20 deployments (including the operation of
a
wholesale access network)."
is a good
reason to allow for Layer 2 interfaces that are
NOT
Ethernet
(may be IPoMPLS, IPoATM, IPoVDSL) and to
NOT
mandate
802.1d support inside the MAC!.
Here is
the clarification requested by you, Alan, taken
from
the
"5 Criteria" template:
"The AI
protocols SHALL be in conformance with the IEEE
802.1
Architecture,
Management and Interworking documents as
follows:
802
Overview and Architecture, 802.1D, 802.1Q and parts of
802.1f.
If
any variances in conformance emerge, they SHALL be
thoroughly
disclosed
and reviewed with 802."
As you
see, 802 is open for discussions, the rules are
flexible.
Hope this
will help people to pass the barrier between WLAN and
BWA.
Best
Regards,
Marianna
P.S. I
accept you sugestion to make in September the
presentation
relative
to the suitable "Functional
Diagram".
-----Original
Message-----
From:
Chickinsky, Alan [mailto:alan.chickinsky@ngc.com]
Sent:
Monday,
August 04, 2003
3:04
PM
To:
Stds-80220-Requirements (E-mail)
Subject:
RE: stds-80220-requirements: Higher Layer Services,
x.x.x
Folk-
This
e-mail traffic raises an series of issues at a higher
level. When I
made my
ISO presentation, I noted there were other IEEE 802.xx
standards
that
effect us. Now is the time for us to say which standards
we will use,
will not
use or defer the decision for use till a later time and
why.
Please
remember to include the "why" or in two years we will again
debate
the
issue.
A question
to the 802.20 chair is, "How much in stone is it written that
we
MUST use
the existing 802.XX standards?"
a.
chickinsky
-----Original
Message-----
From:
Michael Youssefmir [mailto:mike@arraycomm.com]
Sent:
Friday,
August 01, 2003
4:53
PM
To: Neka
Hicks
Cc:
Stds-80220-Requirements (E-mail); Michael
Youssefmir
Subject:
Re: stds-80220-requirements: Higher Layer Services,
x.x.x
Hi
Neka,
I
definitely share your sentiments with regard for the need
for an
operator to be (optionally) able to run a wholesale
network.
Nevertheless,
there have been a number of contributions that have
proposed
keeping 802.20 "network agnostic". In particular, for
example,
http://www.ieee802.org/20/Contribs/C802.20-03-31r1.pdf
argues
this point and its advantages in allowing operators to
use
existing
network infrastructure in support of 802.20
deployments
(including
the operation of a wholesale access
network).
I
therefore propose to not include a specific mandate to
support
802.1Q
just as it would be inappropriate to mandate the use
of
MPLS, PPP,
or PPP/MPLS which could be used to satisfy the
same
functional
requirements.
Regarding
code push to the UT, this is a management
function
independent
of the air interface, and dependent on
the
on the
operations processes of the ISP or network
operator.
Alan
Chickinsky made an excellent proposal at the meeting
last week.
He said
that, for those requirements that are not at the PHY/MAC
level,
we need to
understand what features the
PHY/MAC
must
support. It would be helpful if you would
recast
your
requirement in those terms. In this context, I believe
it is
safe to
say that the PHY/MAC could accomplish what you suggest through
an
appropriate
QOS service level for the code data
itself.
Finally
requirements on the number of code images a UT should
support
and how it
switches between the two are clearly out of the
scope
of the
PHY/MAC and should not appear in the requirements
document.
For
completeness here is your original
contribution:
Proposed
New text
Additional
items:
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).
CPE
software upgrade .push. . an operator should have the ability
to .push.
a software
upgrade to CPE that are currently connected to the
network. The
packets
that make up the software image should be given a very high
priority
and should
be coded heavily such that they have a very high chance
of
arriving
error free at the CPE. The CPE should be capable of
holding 2
software
loads (the existing one and a new one) such that an operator
can
ensure
that the .new. software load has arrived safely at the CPE
before
deciding
to switch from the .old. software load to the .new. software
load.
Rationale
It is very
important for operators to be able to manage traffic on
the
backbone
for different customer types (business vs. residential) or to
enter
into
wholesale arrangements whereby the wholesale partner provides
the CPE
to the end
user, but the network is owned and maintained by the
operator.
In this
scenario, the operator needs to have the ability to separate
traffic
from CPE
belonging to each wholesale partner and direct that traffic to
each
wholesale
partner independently.
It is very
important (particularly during the early deployment stage)
that
operators
have the ability to .push. out new software loads to CPE
quickly
and
efficiently to ensure network element software upgrades can
efficiently
coincide
with user CPE software upgrades
Mike
On
Tue, Jul
29, 2003 at
02:20:47PM -0500,
Neka Hicks wrote:
>
All,
>
> I'm
not sure which section will contain a list of these (possibly
one of
the
>
Appendices), but here is a contribution for that
section:
>
>
<<clearwire contribution 072803 - higher layer
services.doc>>
>
> Neka
C. Hicks
>
Director of Network Engineering
>
Clearwire Technologies
>
>
469-737-7555 (office)
>
817-706-2548 (cell)
>
This mail
passed through mail.alvarion.com
****************************************************************************
********
This
footnote confirms that this email message has been scanned
by
PineApp
Mail-SeCure for the presence of malicious code, vandals &
computer
viruses.
****************************************************************************
********
This mail
was sent via mail.alvarion.com
************************************************************************************
This
footnote confirms that this email message has been scanned
by
PineApp
Mail-SeCure for the presence of malicious code, vandals &
computer viruses.
************************************************************************************
This mail passed through
mail.alvarion.com
************************************************************************************
This
footnote confirms that this email message has been scanned
by
PineApp Mail-SeCure for the presence of malicious code,
vandals & computer
viruses.
************************************************************************************