1 / 32

802.11 Review of July 2013 Proposed Pars

802.11 Review of July 2013 Proposed Pars. Authors:. Date : 2013-07-18. Abstract. Review of 802 WG PARS submitted for review during the July 2013 Session. PARs under consideration. July 1x-1x, 2013, Geneva, Switzerland

carlyn
Download Presentation

802.11 Review of July 2013 Proposed Pars

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 802.11 Review of July 2013 Proposed Pars Authors: • Date:2013-07-18 Jon Rosdahl, CSR Technology Inc.

  2. Abstract • Review of 802 WG PARS submitted for review during the July 2013 Session. Jon Rosdahl, CSR Technology Inc.

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

  4. 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? • 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.

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

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

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

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

  9. Response Summary Jon Rosdahl, CSR Technology Inc.

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

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

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

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

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

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

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

  17. 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 Qcdwill 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

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

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

  20. 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”

  21. 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? • Yes • 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

  22. Comments Received fromChair 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”

  23. Comments Received fromChair 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.

  24. Pat Thaler, IEEE 802.1 DCB task group chair . 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>.

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

  26. 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_DMLT_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.

  27. 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_DMLT_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.

  28. 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:” • Accepted • 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_DMLT_SG_Tutorial_v04.pdf. • No changes needed.? Jon Rosdahl, CSR Technology Inc.

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

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

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

  32. 802.19.1 Cont Jon Rosdahl, CSR Technology Inc.

More Related