RE: stds-80220-requirements: Reference Model in rev. 5

["Chickinsky, Alan" <alan.chickinsky@ngc.com>]

Title: RE: stds-80220-requirements: Higher Layer Services, Reference Mod el

Marianna-

 

I stand corrected.  I thought the diagram on page 33 was yours.  I reviewed the e-mail traffic and found your original proposal.  Some of my comments still apply-

 

1- If you fell we need to replace the three diagrams, then can you include all seven layers in the combined diagram and how we fit into the other 802 documents?

2- Can you explain why you have introduced new terms  for the terms as defined in the figure on page 29 and page 33?  Please remember we had a big discussion about definitions in the PAR at meeting #1.  So we could have another lenghty discussion if we re-invent terms.

 

I would also comment that your diagram has more details then the current figures. 

 

Please note I am biased, since I suggest the diagrams on page 29 and 30.

 

discussion-

 

The figure on page 29 shows the reader where our specification fits into the ISO layers.  The figure on page 30 show our place relative to the other 802 specifications.  The figure on page 33 shows a details of our work.  Since your diagram also shows the details, I would suggest we see what we gain or lose if we replace the diagram on page 33 with your diagram.

 

You introduce the term "CS", but do not support why it is different from the MSAP or the other existing SAP terms. 

 

You also comment that 802.1 bridging and 802.1 management are not applicable, but do not give concrete examples.  We need to take these examples to the rest of 802 for concurrence.

 

alan

-----Original Message-----
From: Marianna Goldhammer [mailto:marianna.goldhammer@alvarion.com]
Sent: Monday, August 04, 2003 1:25 PM
To: Chickinsky, Alan
Cc: Stds-80220-Requirements (E-mail)
Subject: RE: stds-80220-requirements: Reference Model in rev. 5

Alan,

 

I think that the supporters of all the mentioned diagrams should answer your questions. I did not introduce them, and I feel uncomfortable with the existing diagrams.

 

I would be happy to respond questions related to the diagram that I proposed.

 

Marianna :)

 

-----Original Message-----
From: Chickinsky, Alan [mailto:alan.chickinsky@ngc.com]
Sent: Monday, August 04, 2003 8:02 PM
To: Marianna Goldhammer
Cc: Stds-80220-Requirements (E-mail)
Subject: RE: stds-80220-requirements: Reference Model in rev. 5

Marianna-

 

Based on your comments, I have re-examined  in document "802.20 Requirements Document - Rev 5", the  figures on the top of page 30,  on page 33 "Figure 1 - Reference partitioning" and on page 29 "Figure 1- IEEE 802 RM for end stations (LAN&MAN/RM)"

 

The figure on page 33 defines the service access point between the MAC and LLC as "MAC_SAP".  The same interface on page 29 is defined as  "MSAP".  Similarly we have "PHY_SAP" and "PHSAP".  But the figure on page 29 has no equivalent for "PMD_SAP".   

 

So I ask the following questions,

 

1- Why are we changing the interface names from those specified in the base IEEE 802 document (Figure on page 29)? 

2- Why do we need a "PLCP" and "PMD sub layer"?  The only place these terms exist is in the figure  on page 33.

 

In the figure on page 33,  the left side legend says "Data Link Layer" and no Logical Link Control is specified, are you saying that the MAC contains the LLC?

 

Figure 33 defines the Management layers into two sections.  In terms of the document structure, I agree that each layer has it's own management section.  But why did you stop with only a "PHY Management".  Why not have a 'PMD Management" and "PLCP Management" sections?

 

As for  the diagram on page 29, I believe that we need a diagram showing the relationship between the ISO layers and the MAC/PHY layer.  This will help the reader understand what we mean, when we say a requirement  defined at "Network" layer will not be satisfied by the 802.20 system.  Rather a derived requirement, base on the Network layer requirement, will be satisfied by the 802.20 system.

 

As for the diagram on the top of page 30, we need a diagram showing how we fit into the other 802 documents.  I believe the diagram should show which parts of 802 we use and which we cannot (or will not) use.  In terms of the Requirement Document only, I suggest we use the diagram on page 30 as a starting point and shade the those documents we feel are not applicable to our system.  

 

a. chickinsky

 

-----Original Message-----
From: Marianna Goldhammer [mailto:marianna.goldhammer@alvarion.com]
Sent: Monday, August 04, 2003 10:48 AM
To: Klerer Mark; Joanne Wilson (E-mail); Chickinsky, Alan; Stds-80220-Requirements (E-mail)
Subject: RE: stds-80220-requirements: Reference Model in rev. 5 (was: Hi gher Layer Services)

Mark,  Joanne,

 

At this point I hope that you realized that the existing Reference Diagram in rev. 5 of the Requirement Document , page 33, par. 5.1.1 is  NOT suitable for Access. I agree with its status: OPEN.

 

Be aware, that the diagram on page 36, is suitable for multiple PHYs. It defines the PLCP layer and also defines PHY SAP.

 

The diagram proposed by me shows essential functional interface points, and replaces ALL the 3 existing diagrams. As I already mentioned, was already used in 802.

 

Please let me know how do you wish to continue,

 

Marianna

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

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

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