802.11 Review of July 2013 Proposed Pars doc.: IEEE 802.11-13/0789r2 July 2013 802.11 Review of July 2013 Proposed Pars Date: 2013-07-18 Authors: Jon Rosdahl, CSR Technology Inc. Jon Rosdahl, CSR Technology Inc.

July 2013 doc.: IEEE 802.11-13/0789r2 July 2013 Abstract Review of 802 WG PARS submitted for review during the July 2013 Session. Jon Rosdahl, CSR Technology Inc. Jon Rosdahl, CSR Technology Inc.

PARs under consideration July 2013 doc.: IEEE 802.11-13/0789r2 July 2013 PARs under consideration July 1x-1x, 2013, Geneva, Switzerland 802.1Qcc - amendment for Stream Reservation Protocol (SRP), PAR and 5C 802.1Qcd - amendment for Application Virtual Local Area Networks (VLAN) Type, Length, Value (TLV), PAR and 5C 802.3br - amendment for Specification and Management Parameters for Interspersing Express Traffic, PAR and 5C 802.15.10 - recommended practice on Layer 2 Routing, PAR and 5C P802.19.1 - PAR Extension Jon Rosdahl, CSR Technology Inc. Jon Rosdahl, CSR Technology Inc.

802.1Qcc July 2013 doc.: IEEE 802.11-13/0789r2 July 2013 PAR In general the PAR appears to be written by and for a community already knowledgeable in 802.1Q. However, one of the purposes of a PAR is to advertise the start of a new project to a broad community. 802.11 members can not read the PAR and determine the scope. Do you plan to issue a press release if the project is approved. How would you describe the project in a press release? In 5.2.b Change “amendment provides” to “amendment describes new” Change “and provide:’ to “which provides:” “Configurable SR (stream reservation) classes and streams “ wording is confusing. Can this be written more clearly? What is the current stream limit. What will the new limit be? What are the characteristics of the streams before and after Qcc? What types of layer three support do you plan to offer? 8.1 is empty. Could some of the 5C material be used to further explain the project? 5.2, 5.4 and 5.5 do not seem to describe the same project – please clarify. 5C Technical feasibility What is the AVnu Alliance and what is its relationship to 802.1Q? Did AVnu supply use cases or requirements that could be referenced/made available? What does C mean? “The technology re‐use, and other augmented methods are deemed proven for their reliability.” What assumptions are being made of 802.11 and its ability to participate in SRP? Jon Rosdahl, CSR Technology Inc. Jon Rosdahl, CSR Technology Inc.

July 2013 802.1Qcd PAR Does IETF provide any similar VLAN tag? How does VLAN tag simplify management? In 5.2.b, the last scope sentence is actually a need statement and should be moved to 5.5. 5C Slide 6 Please define the scope of “end stations” or provide some examples. The 5C alternately claims that Qcd will simplify network management and end station management – which is it? Jon Rosdahl, CSR Technology Inc.

July 2013 doc.: IEEE 802.11-13/0789r2 July 2013 802.15.10 PAR Section 1.2 Is this really a Recommended Practice or a Standard? Section 5.2 Change to “This standard defines a protocol that routes packets in a dynamically changing network (changes on the order of a minute time frame), with minimal impact to route handling. Section 5.4 What L3 mechanisms are to be considered? Section 8.1 Clarify the relationship between 15.4e and 15.10. Are there any new functions being added by 15.10? Does 15.10 use only features previously defined by 15.4e? Is 15.10 for use only with 15.4 based networks? Should the project be called 802.15.4.1 because this is a recommended practice (standard) for 15.4? 5C Jon Rosdahl, CSR Technology Inc. Jon Rosdahl, CSR Technology Inc.

July 2013 802.3br PAR 2.1 Change to: Standard for Ethernet Amendment Specification and Management Parameters for Interspersed Express Traffic. 5.2.b Clarify the scope regarding whether the project will add only Qos parameters or also a management protocol. 5.2.b Change “The scope of this project is to specify” to “This amendment specifies” Is there any dependency between 802.1Qbu and 802.3br? Please explain what “interspersed express traffic” is. Could the term be described in either 5.2 or 8.1? 5.5 the last sentence does not seem to be appropriate. 5.5 replace “, including but not limited to,” with “such as” 5.6 Delete “stakeholders included to date include but are not limited to:” 5C Distinct Identity (slide 5) What does close to zero delay on converged networks mean? Jon Rosdahl, CSR Technology Inc.

July 2013 802.19.1 extension PAR In 2 delete “and therefore an extension of the PAR is required” Insert in 2 an explanation of expected project timeline to justify a two year extension. Fix 3.5. What percentage of the Draft is stable: % (blank) 5C N/A Jon Rosdahl, CSR Technology Inc.

Response Summary July 2013 PAR Response Comments only Revised PAR Revised 5c 802.11 action 802.1Qcc P 5C ok where is revised PAR? 802.1Qcd PAR ok. 5C explanation OK still wish this was added to 5C 802.15.10 802.3br PAR ok, 5C ok 802.19.1 PAR ok Jon Rosdahl, CSR Technology Inc.

Response to IEEE 802.11 comments on PAR for IEEE P802.1Qcc July 2013 Response to IEEE 802.11 comments on PAR for IEEE P802.1Qcc July 2013 Pat Thaler, IEEE 802.1 DCB task group chair .

July 2013 802.1Qcc PAR In general the PAR appears to be written by and for a community already knowledgeable in 802.1Q. However, one of the purposes of a PAR is to advertise the start of a new project to a broad community. 802.11 members can not read the PAR and determine the scope. Do you plan to issue a press release if the project is approved. How would you describe the project in a press release? We have assumed that dealing with your specific comments will resolve this general comment. Jon Rosdahl, CSR Technology Inc.

July 2013 802.1Qcc (cont) In 5.2.b Change “amendment provides” to “amendment describes new” Accepted - change made. Change “and provide:’ to “which provides:” Accepted in principle – wording clarified. “Configurable SR (stream reservation) classes and streams “ wording is confusing. Can this be written more clearly? Accepted – wording improved (in our opinion). What is the current stream limit. What will the new limit be? Accepted. The wording has clarified this. What are the characteristics of the streams before and after Qcc? Accepted. Wording improved. Jon Rosdahl, CSR Technology Inc.

July 2013 802.1Qcc (cont) What types of layer three support do you plan to offer? Accepted. Wording improved. 8.1 is empty. Could some of the 5C material be used to further explain the project? Accepted. A pointer to the 5C wil be included in 8.1. 5.2, 5.4 and 5.5 do not seem to describe the same project – please clarify. 5.2 and 5.5 are introduced by this project and are mutually consistent; 5.4 is the Purpose as it appears in the current base document (802.1Q) and as it will appear in the rolled-up document (802.1Q plus this and other amendments). This amendment is consistent with the purpose as described. Jon Rosdahl, CSR Technology Inc.

July 2013 802.1Qcc (cont) 5C - Technical feasibility What is the AVnu Alliance and what is its relationship to 802.1Q? Accepted. Clarification included. Did AVnu supply use cases or requirements that could be referenced/made available? No. What does C mean? “The technology re‐use, and other augmented methods are deemed proven for their reliability.” Accepted. Wording improved. What assumptions are being made of 802.11 and its ability to participate in SRP? This amendment makes no assumptions regarding 802.11. Jon Rosdahl, CSR Technology Inc.

Response to IEEE 802.11 comments on PAR for IEEE P802.1Qcd July 2013 Response to IEEE 802.11 comments on PAR for IEEE P802.1Qcd July 2013 Pat Thaler, IEEE 802.1 DCB task group chair .

July 2013 802.1Qcd PAR Does IETF provide any similar VLAN tag? No, VLAN tags are defined in IEEE 802.1Q and was fundamental to the initial IEEE 802.1Q. VLAN tags carry QoS information (i.e. priority) and VLAN IDs. How does VLAN tag simplify management? The VLAN ID is used to mark traffic as belonging to a Virtual LAN. This amendment simplifies management of end stations (i.e. devices that create and are the destination of traffic, rather than bridging the traffic) by providing a means for the adjacent bridge to tell the end station what VLAN ID to use for a particular application. We already have a similar TLV that indicates the priority to use for a particular application. See IEEE 802.1Q Annex D.2.12.3 (currently published in IEEE 802.1Qaz). In 5.2.b, the last scope sentence is actually a need statement and should be moved to 5.5. Accept, we will move that sentence to the start of 5.5 Pat Thaler, IEEE 802.1 DCB task group chair .

July 2013 802.1Qcd continued 5C Slide 6 Please define the scope of “end stations” or provide some examples. This term is defined in IEEE 802 and used in IEEE 802.1Q. The 5C alternately claims that Qcd will simplify network management and end station management – which is it? It doesn’t say that it simplifies network management – it says management of such networks. The network includes the end station network interfaces and the bridges, even though the term “network management” often is used in industry meaning just management of bridges. Typically, different administrators and management applications are involved in managing end stations and bridges. This presents a challenge for coordinating end stations with the network to which they are attached. DCBX (part of IEEE 802.1Qaz) was created to address this by providing a way for the adjacent bridge to tell an end station things it needed to know about the network configuration. The Application VLAN ID TLV fills a gap in the information currently covered by DCBX. This simplifies end station management as well as management of the network as a whole. Pat Thaler, IEEE 802.1 DCB task group chair

Response to IEEE 802.11 comments on PAR for IEEE P802.15.10 July 2013 Response to IEEE 802.11 comments on PAR for IEEE P802.15.10 July 2013 Pat Thaler, IEEE 802.1 DCB task group chair .

July 2013 doc.: IEEE 802.11-13/0789r2 July 2013 802.15.10 Attached are the updated 15.10 PAR and 5C redlines for your reference reflecting the responses to comments circulated previously with one exception. The response to 6.1b has been changed to yes, at the further request of Bob Grow, as a courtesy and as early notice that the project will be reviewed by the RAC even though the proposed recommended practice is not changing the MAC addressing used in IEEE Std. 802.15.4, therefore no changes to registration activity are anticipated. Additionally changes were made to the Title (2.1), Scope (5.2) and Explanatory Notes (8.1). In the 5C a change was made to Section 2. Jon Rosdahl, CSR Technology Inc. Jon Rosdahl, CSR Technology Inc.

Comments Received from 802.11 doc.: IEEE 802.11-13/0789r1 July 2013 Comments Received from 802.11 PAR 1.2 Type of Document Is this really a Recommended Practice or a Standard? Yes, it is a recommended practice. A recommended practice is more appropriate to verify that this appropriately meets the market demands of 802.15.4 5.2 Scope Change to “This standard defines a protocol that routes packets in a dynamically changing network (changes on the order of a minute time frame), with minimal impact to route handling. Changed to “This recommended practice defines a protocol that routes packets in a dynamically changing network (changes on the order of a minute time frame), with minimal impact to route handling. 5.4 Purpose What L3 mechanisms are to be considered? The L3 mechanisms are described in IETF RFC4903 “Multilink Subnet Issues” Jon Rosdahl, CSR Technology Inc.

Comments Received from 802.11 (cont’d.) doc.: IEEE 802.11-13/0789r1 July 2013 Comments Received from 802.11 (cont’d.) PAR 8.1 Additional Explanatory Notes Clarify the relationship between 15.4e and 15.10. 802.15.4e (MAC enhancements) is anticipated to facilitate 802.15.10 Are there any new functions being added by 15.10? No functions are being added to IEEE 802.15.4 15.10 will have define IEEE 802.15.4 behaviors for routing Does 15.10 use only features previously defined by 15.4e? Yes Is 15.10 for use only with 15.4 based networks? Should the project be called 802.15.4.1 because this is a recommended practice (standard) for 15.4? While 15.10 is a recommended practice for IEEE 802.15.4, it keeps a clear distinction between the standard and the recommended practice This also provides a capability to extend the recommended practice to other IEEE 802.15 networks Jon Rosdahl, CSR Technology Inc.

Comments Received from Chair 802.19 doc.: IEEE 802.11-13/0789r1 July 2013 Comments Received from Chair 802.19 PAR 2.1 Title Change “dynamically changing wireless networks” to “dynamically changing wireless personal area networks” Change to “dynamically changing IEEE 802.15.4 networks” 5.2 Scope The scope says that this recommended practice “extends wireless networks.” It is not clear what is meant by “extend” in this phrase. Is the distance extended? Would the word “enhance” be a better word than “extend” in this scope? Change to ”extends the area of coverage of IEEE 802.15.4 networks” When you say that the network is “dynamically changing” are you saying that the network connections are changing due to mobility? Yes, among other s (see below). Please explain what is meant by “dynamically changing networks” in Section 8.1, Additional Explanatory Notes. Add to 8.1: “Dynamically changing networks refer to network connections changing due to mobility, signal impairments, and the transient nature of networks” Jon Rosdahl, CSR Technology Inc.

Comments Received from Chair 802.19 (cont’d.) doc.: IEEE 802.11-13/0789r1 July 2013 Comments Received from Chair 802.19 (cont’d.) PAR 5.2 Scope We suggest changing “This recommended practice will facilitate the routing of packets …” to “This recommended practice will provide recommendations on the routing of packets …” Agree 5.5 Need for the Project Please add an explanation in Section 8.1 on what is a “Field Area Network” Add to 8.1: The Field Area Network (FAN) may provide a connectivity path from field Distribution Automation (DA) devices to the substation upstream, or connectivity that bypasses the Substations and links the field DA devices into a centralized management and control system. Jon Rosdahl, CSR Technology Inc.

Response to IEEE 802.11 comments on PAR for IEEE P802.3br July 2013 Response to IEEE 802.11 comments on PAR for IEEE P802.3br July 2013 <http://www.ieee802.org/3/DMLT/8023-DMLT- SG-1305-Winkel-PAR-2013-07-17r2.pdf>. Pat Thaler, IEEE 802.1 DCB task group chair .

July 2013 802.3br response PAR 2.1 Change to: Standard for Ethernet Amendment Specification and Management Parameters for Interspersed Express Traffic. Rejected: According to native speakers’ advice, the SG DMLT decided explicitly to use the verbal form INETERSPERSING in the title and in the scope to use “to add a support for INTERSPERSED express traffic.”! Rationale: the project will be describing how to intersperse express traffic. Jon Rosdahl, CSR Technology Inc.

July 2013 802.3br (cont) 5.2.b Clarify the scope regarding whether the project will add only Qos parameters or also a management protocol. Rejected: The Scope shall not include solutions. The objectives are giving boundaries for the Task Force. As said in the tutorial, more than one solution is possible, see http://www.ieee802.org/3/DMLT/public/Jul13/Winkel_00_0713_DML T_SG_Tutorial_v04.pdf. IEEE 802.3 already has a management protocol. There is no intent to change the management protocol. IEEE 802.1 projects cover the QoS aspects. This project is to augment the data path capabilities of 802.3 to support interspersing express traffic. As typically for 802.3 the project will specify the management parameters for the new capability. The title of this Amendment mentions “… Management Parameters …”. Jon Rosdahl, CSR Technology Inc.

July 2013 802.3br (cont) 5.2.b Change “The scope of this project is to specify” to “This amendment specifies” Rejected: The wording is typical for IEEE 802.3 PARs. The scope of an amendment will not be in included in the body of the amendment. Is there any dependency between 802.1Qbu and 802.3br? 􀀃Noted: No dependency for 802.3br known. This Amendment can be used by several 802.1 projects. Please explain what “interspersed express traffic” is. Could the term be described in either 5.2 or 8.1? AiP: The tutorial provided an explanation, see http://www.ieee802.org/3/DMLT/public/Jul13/Winkel_00_0713_DM LT_SG_Tutorial_v04.pdf. Any more detailed explanations would vary depending on the solution adopted. No further explanation in the PAR is appropriate. No changes needed. Jon Rosdahl, CSR Technology Inc.

802.3br 5.5 the last sentence does not seem to be appropriate. July 2013 802.3br 5.5 the last sentence does not seem to be appropriate. Rejected: Because the alternative to interspersing express traffic would be to run express traffic on a separate physical link and this point out the need for the single physical link. 5.5 replace “, including but not limited to,” with “such as” Accepted 5.6 Delete “stakeholders included to date include but are not limited to:” 5C -- Distinct Identity (slide 5) What does close to zero delay on converged networks mean AiP: Delay substantially less than a max frame transmission time. See the tutorial for more explanations, see http://www.ieee802.org/3/DMLT/public/Jul13/Winkel_00_0713_D MLT_SG_Tutorial_v04.pdf. No changes needed.? Jon Rosdahl, CSR Technology Inc.

Response to IEEE 802.11 comments on PAR for IEEE P802.19.1 July 2013 Response to IEEE 802.11 comments on PAR for IEEE P802.19.1 July 2013 Pat Thaler, IEEE 802.1 DCB task group chair .

July 2013 802.19.1 response PAR In 2 delete “and therefore an extension of the PAR is required” Insert in 2 an explanation of expected project timeline to justify a two year extension. Fix 3.5. What percentage of the Draft is stable: % (blank) 5C - N/A 802.19 response - We have updated the extension request 3.5. What percentage of the Draft is stable: 80% Jon Rosdahl, CSR Technology Inc.

July 2013 802.19.1 2. Why an Extension is Required: The 802.19.1 draft passed working group letter ballot in November 2012. The first recirculation was run in May 2013, the second recirculation is planned for August 2013, and the third recirculation (if needed) is planned for October 2013. Initial Sponsor Ballot is planned for November 2013 with recirculation planned for March 2014 and final IEEE 802 executive committee approval in July 2014. The draft is expected to be submitted to RevCom in October 2014. If an additional working group or Sponsor Ballot recirculations are required, the completion of the draft standard could be delayed until the beginning of 2015. Therefore a 2 year extension is required. Jon Rosdahl, CSR Technology Inc.

July 2013 802.19.1 Cont Jon Rosdahl, CSR Technology Inc.