1 / 17

IEEE 802.1 OmniRAN TG July 2 nd , 2014 Conference Call

IEEE 802.1 OmniRAN TG July 2 nd , 2014 Conference Call. 2014-07-02 Max Riegel, Nokia Networks ( OmniRAN TG Chair). Wednesday , July 2 nd , 2014 at 10:00-11:30am ET WebEX : Meeting Number: 703 150 141 Meeting Password: OmniRAN To join this meeting

homer
Download Presentation

IEEE 802.1 OmniRAN TG July 2 nd , 2014 Conference Call

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. IEEE 802.1 OmniRAN TGJuly 2nd, 2014 Conference Call 2014-07-02Max Riegel, Nokia Networks (OmniRAN TG Chair)

  2. Wednesday, July 2nd, 2014 at 10:00-11:30am ET WebEX: Meeting Number: 703 150 141 Meeting Password: OmniRAN To join this meeting 1. Go to https://nsn.webex.com/nsn/j.php?J=703150141&PW=NZDEwOGIxNmMy 2. Enter the meeting password: OmniRAN 3. Click "Join Now". 4. Follow the instructions that appear on your screen. Teleconference information Show global numbers: http://www.nsn.com/nvc Conference Code: 433 819 2102 Conference Call

  3. All participants in this meeting have certain obligations under the IEEE-SA Patent Policy. Participants [Note: Quoted text excerpted from IEEE-SA Standards Board Bylaws subclause 6.2]: “Shall inform the IEEE (or cause the IEEE to be informed)” of the identity of each “holder of any potential Essential Patent Claims of which they are personally aware” if the claims are owned or controlled by the participant or the entity the participant is from, employed by, or otherwise represents “Personal awareness” means that the participant “is personally aware that the holder may have a potential Essential Patent Claim,” even if the participant is not personally aware of the specific patents or patent claims “Should inform the IEEE (or cause the IEEE to be informed)” of the identity of “any other holders of such potential Essential Patent Claims” (that is, third parties that are not affiliated with the participant, with the participant’s employer, or with anyone else that the participant is from or otherwise represents) The above does not apply if the patent claim is already the subject of an Accepted Letter of Assurance that applies to the proposed standard(s) under consideration by this group Early identification of holders of potential Essential Patent Claims is strongly encouraged No duty to perform a patent search Participants, Patents, and Duty to Inform

  4. All participants should be familiar with their obligations under the IEEE-SA Policies & Procedures for standards development. Patent Policy is stated in these sources: IEEE-SA Standards Boards Bylawshttp://standards.ieee.org/develop/policies/bylaws/sect6-7.html#6 IEEE-SA Standards Board Operations Manualhttp://standards.ieee.org/develop/policies/opman/sect6.html#6.3 Material about the patent policy is available at http://standards.ieee.org/about/sasb/patcom/materials.html If you have questions, contact the IEEE-SA Standards Board Patent Committee Administrator at patcom@ieee.org or visit http://standards.ieee.org/about/sasb/patcom/index.html This slide set is available at https://development.standards.ieee.org/myproject/Public/mytools/mob/slideset.ppt Patent Related Links

  5. If anyone in this meeting is personally aware of the holder of any patent claims that are potentially essential to implementation of the proposed standard(s) under consideration by this group and that are not already the subject of an Accepted Letter of Assurance: Either speak up now or Provide the chair of this group with the identity of the holder(s) of any and all such claims as soon as possible or Cause an LOA to be submitted Call for Potentially Essential Patents

  6. Other Guidelines for IEEE WG Meetings All IEEE-SA standards meetings shall be conducted in compliance with all applicable laws, including antitrust and competition laws. • Don’t discuss the interpretation, validity, or essentiality of patents/patent claims. • Don’t discuss specific license rates, terms, or conditions. • Relative costs, including licensing costs of essential patent claims, of different technical approaches may be discussed in standards development meetings. • Technical considerations remain primary focus • Don’t discuss or engage in the fixing of product prices, allocation of customers, or division of sales markets. • Don’t discuss the status or substance of ongoing or threatened litigation. • Don’t be silent if inappropriate topics are discussed … do formally object. --------------------------------------------------------------- See IEEE-SA Standards Board Operations Manual, clause 5.3.10 and “Promoting Competition and Innovation: What You Need to Know about the IEEE Standards Association's Antitrust and Competition Policy” for more details.

  7. Link to IEEE Disclosure of Affiliation http://standards.ieee.org/faqs/affiliationFAQ.html Links to IEEE Antitrust Guidelines http://standards.ieee.org/resources/antitrust-guidelines.pdf Link to IEEE Code of Ethics http://www.ieee.org/web/membership/ethics/code_ethics.html Link to IEEE Patent Policy http://standards.ieee.org/board/pat/pat-slideset.ppt Resources – URLs

  8. Agenda bashing Approval of minutes Reports ITU-T Liaisonhttp://www.ieee802.org/1/files/public/docs2014/liaison-ITUTSG15-LS114_229P-AnnN-0414.DOCX An archive containing the referenced ITU-T specifications is available byhttps://mentor.ieee.org/omniran/dcn/14/omniran-14-0045-00-00TG-reference-archive-g-80xx-specs.zip Contributions to P802.1CF Preparation of July F2F meeting AOB Agenda

  9. Business#1 • Call Meeting to Order • Meeting called to order by chair at • Minutes taker: • Roll Call

  10. Business#2 • Agenda bashing • Approval of minutes • May 2014 interim meeting in Norfolk • https://mentor.ieee.org/omniran/dcn/14/omniran-14-0043-00-00TG-meeting-minutes-for-may-2014-f2f-interim-meeting.docx • Reports • SDN update • ITU • Third JCA-SDN meeting (Geneva, 11 July 2014 – PM) • http://www.itu.int/en/ITU-T/jca/sdn/Pages/default.aspx • online participation possible • Archive of IEEE 802 SDN mailing list • http://grouper.ieee.org/groups/802/OmniRANsg/email/ • UCI Forum • http://uciforum.wordpress.com/2014/05/16/uci-forum-advances-software-defined-networking-with-unified-communication-use-case/ • http://ucif.org/Portals/0/documents/2014_02_27_Use_Case.pdf • Others • Other topics

  11. “UCI Forum Advances Software Defined Networking with Unified Communication Use Case” • SAN RAMON, Calif., May 15, 2014 – The Unified Communications Interoperability Forum (UCI Forum) today announced that it has released its first Unified Communication Software Defined Network (UC SDN) Use Case specification for automating Quality of Service (QoS). Developed by its newly formed UC SDN Task Group (TG), the specification describes in detail how a UC system can automate the programming of the network for proper treatment of voice, video and web conferencing. • This innovative approach removes the expensive and error prone manual administration of deploying QoS, thereby eliminating misconfiguration, configuration drift and increased cost of operations. All an operator has to do is specify a set of policies for voice, video and web conferencing and the UC systems will automatically program the network via a UC SDN North Bound Interface (NBI) to the desired QoS treatment. The specification details how to dynamically manage QoS, which involves four different use cases: • Dynamic Marking QoS: dynamically mark authorized voice and video traffic with the appropriate QoS markings. • Call Admission Control: prevent voice and video traffic from exceeding the available bandwidth capacity, and notify applications of changes in available bandwidth so they can adjust selected codecs (e.g. based on policies). • Dynamic Traffic Engineering of Bandwidth Capacity for each Class of Service: dynamically adjust the amount of bandwidth associated with various Classes of Service (CoS) to match bandwidth requirements of the corresponding applications. • Dynamic Traffic Engineering of Media Paths: route media along a path that is best able to meet performance requirements, rather than along the “default” least-cost path. • Version 1.0 of the specification focuses on dynamically marking QoS and can be downloaded here: http://ucif.org/Portals/0/documents/2014_02_27_Use_Case.pdf. Version 2.0, set for release later this year, will extend the specification to cover dynamic Traffic Engineering (TE) and Call Admission Control.Given that more and more customers demand UC to work correctly over Wi-Fi, the specification covers both wired and wireless networks, thereby improving the end user experience.

  12. Business#3 • ITU-T Liaisonhttp://www.ieee802.org/1/files/public/docs2014/liaison-ITUTSG15-LS114_229P-AnnN-0414.DOCX • An archive containing the referenced ITU-T specifications is available byhttps://mentor.ieee.org/omniran/dcn/14/omniran-14-0045-00-00TG-reference-archive-g-80xx-specs.zip SG15 has become aware of the IEEE 802.1 project “P802.1CF - Network reference model for IEEE 802 access network”. We note that IEEE 802.1 is considering referencing ITU-T Rec. I.130 ‘Stage 2’ process to provide a mapping of the existing IEEE 802 protocols to a functional network model and then use that model to develop an SDN abstraction of the IEEE 802 access network. We suggest that you consider SG15 models. For Ethernet these include ITU-T G.8010, G.8021, G.8031, G.8032, G.8011, G.8012, G.8051 and G.8052. In SG15 we have been evaluating the application of SDN in the transport network for the past year and, at this meeting, have agreed to begin work on a Recommendation - G.asdtn Architecture for SDN control of transport networks. ITU-T G.asdtn will describe the reference architecture for SDN control of transport networks applicable to both connection-oriented circuit and/or packet transport networks. The architecture will be described in terms of abstract components and interfaces that represent logical functions (abstract entities versus physical implementations). Please keep us informed on the progress of your work in IEEE 802.1.

  13. ITU-T G.80XX Specifications • G.8010: Architecture of Ethernet layer networks • This Recommendation describes the functional architecture of Ethernet networks using the modelling methodology described in ITU-T Recs G.805 and G.809. The Ethernet network functionality is described from a network level viewpoint, taking into account an Ethernet network layered structure, client characteristic information, client/server layer associations, networking topology, and layer network functionality providing Ethernet signal transmission, multiplexing, routing, supervision, performance assessment, and network survivability. The functional architecture of the server layer networks used by the Ethernet network is not within the scope of this Recommendation. Such architectures are described in other ITU-T Recommendations or IETF RFCs. • This Recommendation is based on the Ethernet specifications in IEEE Standards 802.1D-2003, 802.1Q-2003 and 802.3-2002, and developments of provider bridged networks. Furthermore, the architectural aspects of provider bridges currently being defined in IEEE P802.1ad task force are taken into account. • This Recommendation defines the Ethernet maintenance entities, but the specific impact on the transport functions of connection monitoring in a connectionless layer network is not addressed. Ethernet network survivability is intended for inclusion in a future version. • This Recommendation is the first of a series of Ethernet and Ethernet over Transport-related Recommendations. Other Recommendations in this series will address e.g., equipment, OAM, service, performance aspects. • G.8011: Ethernet service characteristics • Recommendation ITU-T G.8011/Y.1307 describes a framework for defining network-oriented characteristics of Ethernet services that is aligned with MEF 10.2. The framework is based on the modelling of Ethernet layer networks described in Recommendation ITU-T G.8010/Y.1306. The attribute sets introduced in this framework, (Ethernet virtual connection (EVC), Ethernet connection (EC), user-to-network interface (UNI) and network‑to‑network interface (NNI)), are intended to be used to create numerous specific Ethernet services. • G.8012: Ethernet UNI and Ethernet NNI • This Recommendation specifies the Ethernet UNI and the Ethernet NNI. A set of physical Ethernet interfaces is defined for the Ethernet UNI and the Ethernet NNI. Further, a set of Ethernet over Transport interfaces are defined for the Ethernet NNI. The Ethernet over Transport NNI uses various server layer networks like ATM, OTH, PDH and SDH. • G.8021: Characteristics of Ethernet transport network equipment functional blocks • Recommendation ITU-T G.8021/Y.1341 specifies both the functional components and the methodology that should be used in order to specify the Ethernet transport network functionality of network elements; it does not specify individual Ethernet transport network equipment. • G.8031: Ethernet linear protection switching • Recommendation ITU-T G.8031/Y.1342 describes the specifics of linear protection switching for Ethernet VLAN signals. Included are details pertaining to ETH linear protection characteristics, architectures, and the APS protocol. The protection scheme considered in this Recommendation is: • VLAN-based Ethernet subnetwork connection linear protection with sublayer monitoring. • G.8032: Ethernet ring protection switching • Recommendation ITU-T G.8032/Y.1344 defines the automatic protection switching (APS) protocol and protection switching mechanisms for ETH layer Ethernet ring topologies. Included are details pertaining to Ethernet ring protection characteristics, architectures and the ring APS (R-APS) protocol. • G.8051: Management aspects of the Ethernet Transport capable network element • Recommendation ITU-T G.8051/Y.1345 addresses management aspects of the Ethernet transport network element containing transport functions of one or more of the layer networks of the Ethernet transport network. The management of the Ethernet layer networks is separable from that of its client layer networks so that the same means of management can be used regardless of the client. The management functions for fault management, configuration management, performance monitoring, and security management are specified. • The 2009 Revision of this Recommendation has added the management of additional transport functions that have been introduced in the 2009 Revision of Recommendation ITU‑T G.8021/Y.1341. • The 2013 revision of this Recommendation has added the management of additional functions, including: client signal fail (CSF); proactive loss measurement using loss measurement message/loss measurement reply (LMM/LMR); proactive delay measurement using delay measurement message/delay measurement reply (DMM/DMR) and one-way delay measurement (1DM); synthetic loss measurement using synthetic loss message/synthetic loss reply (SLM/SLR) and one-way synthetic loss measurement (1SL) (proactive and on-demand); performance management (PM) requirements on protocol data unit (PDU) generation type, message period, measurement interval, repetition period, start time, stop time and session duration; and PM data collection requirements. • G.8052: Protocol-neutral management information model for the Ethernet Transport capable network element • Recommendation ITU-T G.8052/Y.1346 contains the protocol-neutral unified modelling language (UML) model for Ethernet transport capable network element management.This Recommendation includes an electronic attachment containing the UML model file in the HTML format.

  14. Business#4 • Contributions to P802.1CF • ToC Refinementshttps://mentor.ieee.org/omniran/dcn/14/omniran-14-0044-00-CF00-toc-refinement-suggestions.pptx • Preparation of July F2F meeting • Schedules • Wireless SDN BoF • Agenda proposal • AOB

  15. July 2014 Agenda Graphics

  16. Wireless SDN BoFTuesday, July 15th, 16:00-18:00, Room: Gaslamp CD • Following the "Wireless SDN" BoF meeting at the January Wireless Interim, and its successor at the March 802 Plenary, we are organizing yet another such meeting for the July 802 Plenary. This will be a joint meeting of the IEEE 802.1 OmniRAN TG and the IEEE 802.16 WG, held in one two-hour slot. Contributions are welcome, as are further discussions on this list regarding the subject matter. You may submit contributions via the Mentor server facility of either OmniRAN or IEEE 802.16. For more information, contact:Max Riegel, Chair, OmniRAN TGRoger Marks, Chair, 802.16 WG • Please upload contributions to the OmniRAN file space on mentor tagged by ‘Wireless SDN BoF’

  17. Agenda proposal for July ‘14 session • Approval of minutes • Reports • P802.1CF contributions • ToC • Network reference model • Functional design and decomposition • SDN Abstraction • OmniRAN organizational issues • ITU-T Liaison response • Location of September 2014 interim meeting • Conference calls until Nov 2014 session • Status report to IEEE 802 WGs • Motions to the 802.1 closing plenary • AOB

More Related