-----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.
************************************************************************************