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

["Gal, Dan (Dan)" <dgal@lucent.com>]

Title:

Jim,

 

Thanks for providing this interesting historical account on the IEEE 802 LLC. It certainly adds a sense of perspective for 802.20.

 

 

Dan   

 

 

 

 -----Original Message-----
From: Jim Mollenauer [mailto:jmollenauer@technicalstrategy.com]
Sent: Friday, August 08, 2003 12:51 PM
To: Klerer Mark
Cc: 'Gal, Dan (Dan)'; 'Marianna Goldhammer'; 'Chickinsky, Alan'; Joanne (E-mail); Vladimir Yanover; 'Stds-80220-Requirements (E-mail)'
Subject: Re: stds-80220-requirements: Reference Model in rev. 5 - revise d figure

Mark, Dan, Marianna, and all:

The issue of working with LLC seems to come up in every group that wants to support more than data traffic.  LLC was originally designed to carry the identity of the higher layer ("Ethertype" in the original pre-802 Ethernet).  In fact, almost all usage of LLC is type 0, which otherwise does nothing. Hence many if not most actual Ethernet installations skip it and continue to use the Ethertype field as such rather than to carry the packet length.  802 in general has become comfortable with this state of affairs.

The other LLC types are 1, which builds a connection over a connectionless link layer, and 2, which provides an immediate acknowledgement.  Type 1 was used by Prime Computer in the 80's because their networking was modeled on X.25 and they needed a connection at the link layer.  No one else that I know of used it.  Type 3 was put in because the MAP factory automation project requested it, but to my knowledge it was never used after the demise of MAP.

The issue of whether everything should formally go under LLC was first raised 20 years ago by 802.6, and 802.2 (the LLC working group) responded that it was not necessary for real-time traffic.  This position was confirmed in the days of 802.14, before 802.2 went into hibernation.  The 802 protocol stack diagram doesn't include all the fine print.

Certainly we need to develop our own approach to issues like ARQ, which may be tied closely with our physical layer and needs to operate with tight time constraints.  Dealing with LLC may be a more difficult problem in theory than in practice.

Jim Mollenauer



Klerer Mark wrote:

Dan, Mariana & All

First, as I stated and as Dan says the detail of the architecture needs to be addressed later once we get to the technical work. Also this is not a "dawning" that we need to work on the whole layer 2 it was understood by many of us. These were the issues that were hinted at by stating in the Five Criteria that the group will clearly identify where divergence from the LAN/PAN architecture is required. Again let's work the details later.

Now on principles, I agree expanding the definition of what the MAC does is BAD architecture and confusing, and should not have been done by anyone. As Dan said the upper half of L2 needs to be specific to the 802.20 environment and we need to be open about that. We will have LLC functionality - so I disagree with Mariana that an LLC can not be used. Just like there are different MACs there can be different LLCs so I see no problem with the LLC paradigm.

So I believe, where this leaves us is, that we can use the existing figures we have or one of the prettied up ones and express the need for a joint optimized design across L1 and L2 in the Requirments document. We then talk about details of further functionality when we get to the specification stage of the work.

Regards,

Mark

-----Original Message-----
From: Gal, Dan (Dan) [mailto:dgal@lucent.com]
Sent: Thursday, August 07, 2003 4:35 PM
To: 'Marianna Goldhammer'; Klerer Mark; 'Chickinsky, Alan'; Joanne (E-mail); Vladimir Yanover
Cc: 'Stds-80220-Requirements (E-mail)'
Subject: RE: stds-80220-requirements: Reference Model in rev. 5 - revise d figure

All,

The realization seems to dawn on us that the IEEE 802.20 standard should specify the entire Layer-1 and Layer-2 protocols stack. It also appears that the IEEE 802.1 (Layer 2, Bridging protocol) and IEEE 802.2 (Layer 2, LLC) are not applicable to the 802.20 MBWA system. Notwithstanding the language of the 802.20 MBWA PAR [to develop] "...physical and medium control layers of an air interface ..." , it is quite clear that intention was to develop the entire Layer-1 and Layer-2, and definitely not limit the standard to the PHY and MAC as defined and shown in the illustration that appears in the "Introduction to ANSI/IEEE Std 802.11 1999 Edition" (page iii) of IEEE 802.11 (please note that this introduction is "not a part of ANSI/IEEE Std 802.11...").

Now. Trying to expand the traditional scope of the MAC to encompass the entire Layer-2 (so that we are in line with the language of the PAR) is wrong. It is wrong because such an approach will lead to confusion in the larger wireless engineering community and to a "messy" 802.20 standard. Established (wireless) standards maintain a clear separation of communication and control entities within Layer-2.

I support Mark Klerer's proposal to include an Layer-2 LLC above the MAC. That is a good step in the right direction. Of course, this LLC should be an MBWA-specific LLC, not the IEEE 802.2 !!

But, LLC is not the only missing part in the Layer-1 & Layer-2 picture. There should also be some sort of convergence sub-layer between the LLC and Layer-3 as well as other Layer-2 entities that support MOBILTY and Radio Resource Management.

Thus, to reiterate my point: this discussion is good and important, but, it should be deferred to the actual standard development phase. There is no need to specify the protocols stack in the System Requirements document!!  In addition, reason requires that in this phase of the 802.20 project, we should be putting much more emphasis on defining the system architecture than on reference models. Clearly, the protocols stack definition cannot come before the MBWA system is fully defined and understood.

Regards,

Dan Gal
Lucent Technologies O
Mobility Solutions - Wireless Standards Development
email: dgal@lucent.com
phone: +1 973-428-7734

-----Original Message-----
From: Marianna Goldhammer [mailto:marianna.goldhammer@alvarion.com]
Sent: Thursday, August 07, 2003 2:30 PM
To: Klerer Mark; 'Chickinsky, Alan'; Klerer Mark
Cc: 'Stds-80220-Requirements (E-mail)'; Vladimir Yanover
Subject: RE: stds-80220-requirements: Reference Model in rev. 5 - revise d figure

Mark,

I have consulted Vladimir, who has been involved in 802.16 Reference Model design.

Here are his oppinions:

1. There is no LLC in ref. model of 802.16. LLC would prescribe very specific primitives and message formats,

this is why 802.16 preferred another, optimized for 802.16 business, primitives and formats for connection setup etc.

802.20 has same reasons to avoid using LLC paradigm.

2. LLC is not  a part of MAC though both belong to Data Link Layer (or Layer 2)

802 model typically covers LLC and Bridging sublayers, but 802.16 not. Placing either of them

in Requirements document would make LLC / Bridging conformance mandatory.

 So the best is to avoid mentioning both of them.

CS in 802.16 is a part of MAC, as well as Security sublayer. In 802.16

MAC = CS + "MAC Common Part" + Security sublayer

LLC framework is not good and we need CS.

Arguments:

1. LLC is using specific formats (802.2, sec. 3.2): 8 bits dest SAP address etc.  which most probably are not convenient

2. LLC is using specific types of communication procedures and commands (sec. 4, sec. 5) that 802.20 will obviously

prefer to define differently

3. Mark is wrong: there is no place in LLC for classification as data units come to there already with destination address

and should be forwarded to destination according to the address. Compare it to 802.16 CS where a packet coming from the

network is classified and its destination is defined only at this moment. As I already said, CS in 802.16 is a part of MAC,

so most probably 802.20 will have nothing to say about LLC, and thus (Joanne is right) there is no need to involve it.

Kind Regards,

Marianna

-----Original Message-----
From: Klerer Mark [mailto:M.Klerer@flarion.com]
Sent: Wednesday, August 06, 2003 9:27 PM
To: Marianna Goldhammer; 'Chickinsky, Alan'; Klerer Mark
Cc: 'Stds-80220-Requirements (E-mail)'
Subject: RE: stds-80220-requirements: Reference Model in rev. 5 - revise d figure

Previous version attachment too long.

Mariana,

In trying to rework the figure that you provided based on  802.16 and the text from you below - I believe there are some problems. I would also like to point out that if you look at the published version of 802.16 (e.g. from GET 802) you will actually see that the Introduction to 802.16  includes the second layered diagram that you object to (i.e. the diagram from the 802 Architecture document).

Maybe I do not understand what you are saying in 2. below, but are you saying that the MAC includes the LLC ?? Also you say in "our case"  I am not sure where these conclusions come from. (Yes Layer 2 frames can carry other Layer 2 frames, even layer 3 packets can be used to carry Layer 2 frames but that is a way of "tunneling" through a network).

With respect to the figure the following problems exist:

<!--[if !supportLists]-->1.       <!--[endif]-->Lack of clarity (probably intentional and related to the above point) what sits on top of the CS-SAP?  Is it an LLC,i.e. more of Layer 2,or is it a Layer 3 Entity or either?

<!--[if !supportLists]-->2.       <!--[endif]-->If I look at the definition of LLC in 802 I get the following:
                        4.2.17 LLC:

That part of a data station that supports the logical link control functions of one or more logical links. The LLC generates command PDUs and response PDUs for sending and interprets received command PDUs and response PDUs. Specific responsibilities assigned to an LLC include

1) Initiation of control signal interchange,

2) Organization of data flow,

3) Interpretation of received command PDUs and generation of appropriate response PDUs, and

4) Actions regarding error control and error recovery functions in the LLC sublayer.

<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->

From 802.16 for the CS I get the following definition (with my annotation):

The service specific convergence sublayer (CS) resides on top of the MAC CPS and utilizes, via the MAC

SAP, the services provided by the MAC CPS (see Figure 1). The CS performs the following functions:

- accepting higher-layer PDUs from the higher layer  -> true of every layer in the protocol stack

- performing classification of higher-layer PDUs   -> Item 2 above

- processing (if required) the higher-layer PDUs based on the classification  -> Item 2 above

- delivering CS PDUs to the appropriate MAC SAP -> true of an entity lying on top of the MAC , probably better described as an MSDU

- receiving CS PDUs from the peer entity -> true of all peer layers

Sure sounds to me like they have the same functionality!

<!--[if !supportLists]-->3.       <!--[endif]-->From a theoretical viewpoint the figure implies that both the control and user plane use the same protocol stacks - generally this will actually not be true.

<!--[if !supportLists]-->4.       <!--[endif]-->The figure mixes logical and physical entities in the case of management. It shows Layer Management Entities communicating directly with a "Network management System". This is mixing things. In general the communication between management entities in a local system to management infrastructure is via its own communications path frequently using SNMP. That communication may be either to an Element Manager or Network Manager. Layer management messages may run between peer layer entities.

I am attaching some "pretty" pictures that show the layered architecture both with and without management interaction. The figures use symbols as defined by Mariana and the structure of Fig 1 from Joanne and me. The figures show an LLC. I have also shown the possibility of modeling Security as a function within a layer rather than as a sublayer. Though I agree with Joanne that some of this detail may not be needed in the Req contribution but needs to be addressed in the std when we get there. One (or all) of these figures could be used to replace Fig 1 supplied by Joanne and me. The text as supplied by Joanne belongs in the Req document. Further detail text as described by Mariana ought to go in the std. I am working on some detailed text to see if we can get some common understanding on this.

Figure 2 is interpreted by me to just give some general background on IEEE architectures and can therefore stay. As I indicated it is also included in the published version of 802.16.

Mark

-----Original Message-----
From: Marianna Goldhammer [mailto:marianna.goldhammer@alvarion.com]
Sent: Wednesday, August 06, 2003 8:57 AM
To: Chickinsky, Alan; 'Klerer Mark'
Cc: Stds-80220-Requirements (E-mail)
Subject: RE: stds-80220-requirements: Reference Model in rev. 5 - revise d figure

        Alan,

1. I do not see differences between PHSAP and PHY SAP, as long as these abreviations have the same explanations.

           PHY SAP is more self-explanatory; it is not new in 802,  has been previously used by 802.16.

 2. The fig. on page 29 is correct for standards having only one Layer 2, like 802.3.  In our case we have:           

                 - a sub-layer 2, called MAC, including LLC

                 - a sub-layer 2 , making the adaptation between the MAC and the next Layers, called Service Specific Convergence Sub-Layer

                 - another sub-layer 2, that can be Ethernet, ATM, etc.

                 - another sub-layer 2, that is the LLC for Ethernet, ATM, etc

                 - a optional layer 2.5, that is MPLS

                 - a Layer 3, that is IP.

     The communication over the wireless MAC does not directly reach the application Layer of the ISO model.        

     It adapts or encapsulates packets belonging to another Layer 2. It is similar with Frame Relay if you want, where you can encapsulate Ethernet over Frame Relay frames.

          In the encapsulation / adaptation of packets from other layers, the second Layer 2 can be omitted, directly  encapsulating IP packets. This is an option to be discussed. My diagram offers any possibility.

The "Service Specific Convergence Sublayer" has a double role:

       - payload handling

       - QoS translation, using "classifiers", that understand the QoS information, embedded in 802.1q, IP ToS, etc. and convey it to the MAC.

       

3. Regarding your last group of questions:

     -

1- Is there a 802.1 Bridging at the LLC layer?

Probably will not be, nobody will need to transport Eth. if only Layer 3 transport is requested. See below.

2- Which other 802.1 standards do we think are applicable?  From a security prespective, we need to look at 802.1X, "Key Distribution".

Probably, I am not an expert in this.

3- What is our interface to other networks, i.e. ATM or X.25? I would suggest that it's at layer 3.

No standard network will communicate directly with 802.20 MAC; X.25 seems to be obsolate; ATM (Layer 2) may be avoided if you have a 3d party Router on Base Station, providing Ethernet; Ethernet can arrive on Fiber or other Local Loop (802.3_something = EFM);

On Terminal, on the other hand, you will not have an Ethernet address for audio, another one for display, etc. The Terminal actually does not need an Ethernet address. In order to activate the other physical interfaces, you will need only the IP information. This is why you do not need to incapsulate Ethernet over the MAC.

Marianna

 -----Original Message-----
From: Chickinsky, Alan [mailto:alan.chickinsky@ngc.com]
Sent: Tuesday, August 05, 2003 11:35 PM
To: 'Klerer Mark'; Marianna Goldhammer
Cc: Stds-80220-Requirements (E-mail)
Subject: RE: stds-80220-requirements: Reference Model in rev. 5 - revise d figure

Mark-

I agree that there is an LLC above the MAC in layer 2.  But our title infers we are MAC and PHY, not LLC, MAC and PHY.  How do you propose to resolve this dilema? 

Marianna-

To answer some of your questions. 

As to the figure on page 29 being incorrect, that's a copy of a diagram from the IEEE 802 master document.  To say that the diagram is incorrect, is to say the IEEE 802 committee is incorrect.  In this diagram it uses the terms "PHSAP" not "PHY SAP" is there a difference?  If not, lets use PHSAP.  In the same way, can we use"MSAP"? This is an effort to minimize the number of new terms. 

As for your use of the terms "CS", I am not sure it's a new interface.. Are you talking about the MAC LLC interface?

As for the figure on page 30 at the top.  I copied the figure from 802.2, 1998 edition, re-afrimed in 2001.  Yes, any commitee above 11 was missing.  Before I redraw the figure with all the committes up to and incliuding 802.20, I want to start the discussion to answer the following questions

1- Is there a 802.1 Bridging at the LLC layer?

2- Which other 802.1 standards do we think are applicable?  From a security prespective, we need to look at 802.1X, "Key Distribution".

3- What is our interface to other networks, i.e. ATM or X.25? I would suggest that it's at layer 3.

-----Original Message-----
From: Klerer Mark [mailto:M.Klerer@flarion.com]
Sent: Tuesday, August 05, 2003 11:22 AM
To: 'Marianna Goldhammer'; Klerer Mark; Chickinsky, Alan
Cc: Stds-80220-Requirements (E-mail)
Subject: RE: stds-80220-requirements: Reference Model in rev. 5 - revise d figure

I believe that this is getting close to what would work as a compromise between the various proposals. I would like to fine tune the text a bit and see whether we can get agreement between the principles in the debate and then post that as joint opinion on the reflector.

I also would like to stimulate some discussion about a CS on top of the MAC and inside L2. My own preference is to have a clean interface to Layer 2 (which could be an LLC on top of the MAC) based on the requirements of a Packet based layer 3. Convergence of services would then be done to the packet layer (e.g. XoIP). In ATM the AALs are modeled as being in Layer 2, but that is because the traffic type is being adapted directly to layer 2 rather then to a common networking layer. I believe that is the appropriate technical issue to address  before showing explicit CSs in L2. The PAR actually does imply that we are designing for an IP based L3.

Mark Klerer

-----Original Message-----
From: Marianna Goldhammer [mailto:marianna.goldhammer@alvarion.com]
Sent: Tuesday, August 05, 2003 10:46 AM
To: Marianna Goldhammer; Klerer Mark; Chickinsky, Alan
Cc: Stds-80220-Requirements (E-mail)
Subject: RE: stds-80220-requirements: Reference Model in rev. 5 - revise d figure

Mark,

Following your observations, I found an error in the figure that I submitted for inclusion in the Requirements document, relative to the figure that I proposed in my submission C802.20-03-67. Instead of PHY SAP, appears CS PHY.

I have also deleted the Radio stuff.

Please consider the revised  attached figure.

Kind Regards,

Marianna

-----Original Message-----
From: Marianna Goldhammer
Sent: Tuesday, August 05, 2003 5:08 PM
To: Klerer Mark; Chickinsky, Alan
Cc: Stds-80220-Requirements (E-mail)
Subject: RE: stds-80220-requirements: Reference Model in rev. 5

O.K. My diagram shows the dependence between the different sub-layers and the management.

Marianna

-----Original Message-----
From: Klerer Mark [mailto:M.Klerer@flarion.com]
Sent: Tuesday, August 05, 2003 5:06 PM
To: Marianna Goldhammer; Chickinsky, Alan
Cc: Stds-80220-Requirements (E-mail)
Subject: RE: stds-80220-requirements: Reference Model in rev. 5

Management is mentioned in the 5 criteria and a statement is made that we will be developing a MIB.

Mark

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

Alan,

Thanks for opening the technical discussion.

1. Including the 7 Layers brings a technical inconsistency. What you want to include is actually a packet SAP. Reason:

     - the MAC may interface with Ethernet, Layer 2; Why to show the interconnection with Layer 3 in this case?

     - the MAC may interface with ATM; same as before

     - the MAC may interface directly with IP; only in this case the interface to Layer 3 is correct.

2. I did not find any reference, in Session one minutes, to naming conventions (doc. IEEE 802.20-03/12r1). The naming conventions that I used, come for 802.16, a BWA standard. I do not see why 802.11 naming conventions are more legitimate than these. But I am open to use any conventions the group wants.

3. Comments to your last paragraph:

The figure on page 29 shows the reader where our specification fits into the ISO layers. 

See my point 1: the figure is technically incorrect, if you use Ethernet or ATM interface. You have 2 choices:

   - make different diagrams, function of connection ISO level of the packet adaptation layer (Convergence sub-layer in my diagram)

  - avoid showing where fits ( I have chosen this one).

 The figure on page 30 show our place relative to the other 802 specifications.

Sorry, but you have a bunch of some of the 802 standards, and the figure does NOT mention to 802.20 placement. Do not see the utility of showing what SOME other standards do. And if you want to do this, you should not omit 802.16 (hope you are not completely biased :) )

  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.

O.K. How do you want to continue?

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

The general difference between SAP and CS is:

- SAP defines primitives, generally not implemented in a system, but necessary to make order; you have such examples in 802.11 as well.

- CS defines functions to be implemented in a system

You also comment that 802.1 bridging and 802.1 management are not applicable, but do not give concrete examples

Regarding bridging (802.1d), see my e-mail from yesterday (RE: stds-80220-requirements: Higher Layer Services, Reference Model).

If you want 802.1d bridging, while the interface with external Layer 2  is not Ethernet, you need to actually make a ROUTER inside your MAC!

Do not think that there is anybody in 802.20 wanting to do it!

Regarding 802.1 Management, is not in the PAR scope. So 802.20 will NOT be compliant.

Regards,

Marianna

   

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

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

<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->

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

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

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