DOCSLIB.ORG

BRKIOT-2517.Pdf

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
BRKIOT-2517.Pdf BRKIOT-2517 Precision Time Protocol - deep dive and use cases Subtitle goes here Albert Mitchell January 2019 Agenda Basics of PTP • PTP Messaging • Grandmaster clock • PTP Profiles • Boundary and Transparent Clocks Configuring PTP on Cisco IE Switches • Profile, modes and changing the defaults Troubleshooting: How to know its working? • Show commands • Debug commands • Vlan impacts • Spanning tree issues Close BRKIOT-2517 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 3 Perspective for PTP Breakout session • This Training oriented towards Network Administrator needing to configure PTP in the network. • Not a PTP expert, yet responsible to implement • The session covers • What is PTP • How to configure on the Cisco Industrial Ethernet Bridges • How to Troubleshoot problems BRKIOT-2517 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 4 PTP Timing Distribution Architecture • PTP uses a hierarchical master-slave architecture for clock distribution. GPS • Grandmaster clock (GMC) is the root timing reference. It transmits Antenna synchronization information to the clocks residing on its network segment. • Ordinary clock (OC) is a device with a single network (PTP) connection and is either the source of (master) or destination for (slave) a synchronization Grandmaster reference. • Boundary clock (BC) has multiple network (PTP) connections and can M White VLAN accurately bridge synchronization from one network segment to another. • ‘M’ – interface in Master sate Boundary • ‘S’ – interface in Slave State Clock S S • Clocks in cascaded topologies: Transparent Ordinary • End-to-end transparent clock (E2E) Clock Clock • Peer-to-peer transparent clock (P2P) M M Red VLAN Green VLAN • PTP epoch is the same as Unix time (Midnight, 1 January 1970). • Using UTC with PTP is subject to leap seconds. S S S S S • PTP uses TAI (Temps Atomique International) time scale and moves forward monotonically. • TAI is currently ahead of UTC by 35 seconds. • TAI is always ahead of GPS by 19 seconds. • The PTP grandmaster communicates the current offset between UTC and Ordinary Clocks TAI so that UTC can be computed from the received PTP time. BRKIOT-2517 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 5 PTP messages Have you seen this diagram? Master Slave t1 Sy F nc ol Delay low -U 1 p ( t1) t2 • What does this mean? t3 eq l_R • How can I use this? Delay De 2 t4 De l_R es p ( t4) BRKIOT-2517 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 7 But first, Well used Terms in PTP • Common terms used throughout the session. • Good for a reference BRKIOT-2517 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 8 PTP Terms • PTP –precision time protocol • GMC – Grand Master Clock (Master) • BC – boundary clock • TC – Transparent clock • OC – Ordinary clock (eg: slave) • E2E TC – End to End Transparent clock • P2P TC – Peer to Peer transparent clock • PDV – packet Delay Variation • M – designates an interface is in Master mode • S – designates an interface is in Slave Mode BRKIOT-2517 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 9 Event Messaging in PTP master and slave Event msgs are timed. • Sync – master to all slaves, contains time • Announce – used by BMCA to build clock hierarchy select GMC • Follow_Up – master to all slaves, contains time t1; only in two-step • Delay_Request (E2E only)– Slave to master, requests delay time • Pdelay_Req (P2P only) slave Peer asking for per hop delay from Master BRKIOT-2517 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 10 PTP Protocol General messages General messages are untimed • Follow_Up master to all slaves, contains time t1; only in two-step • Delay_Resp, (E2E only) Master to Slave, responds with time t4 • Pdelay_Resp_Follow_Up (P2P only) • Management • Signaling • Pdelay_Req, Pdelay_Resp and Pdelay_Resp_Follow_Up are used by Peer-to- Peer Transparent Clocks to measure delays across the network so that they can be compensated for by the system. BRKIOT-2517 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 11 PTP Synchronization Message Exchange 1. It startsMaste whenr Master clockSla vsendse ‘Sync’ message. 1. ‘t1’ is timestamp when it leaves master 2.t1 In one-step ‘t1’ in Sync message 3. In two-step,Sy ‘t1’ in Follow-up message F nc 2. Slave receivesol ‘Sync’ at ‘t2’. Delay low -U 1 3. Slave sends ‘Delay_Reqp ( ’ message t1) 1. ‘t3’ is timestamp when it leavest2 slave 4. Master receives ‘Delay_Req’ at ‘t4’ 5. Master responds with ‘Delay_Respt3 ’ eq 1. contains ‘t4’ l_R Delay De 2 Slave needs t3 and t4 timestamps for delay t4 MeanPathDelay = ((t - t ) + (t - t ))/2 De 2 1 4 3 l_R es p ( Offset = t2 – t1 – MeanPathDelayt4) Offset = difference between the master and slave clock BRKIOT-2517 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 12 Calculating Delay Mean Mpathaster Delay = ((tS2la–vet1)+(t4 – t3))/2 t1 Mean path DelaySyis really an Average F nc ol Delay low -U 1 p ( An assumption is made:t1) t2 Delay 1 = Delay 2 t1, t2 t3 eq l_R AssumptionDelay is usuallyDe wrong 2 (to some degree) t4 De Protocol Mechanismsl_R can correct es p ( for known Asymmetryt4) t1, t2, t3, t4 Asymmetry cannot be detected BRKIOT-2517 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 13 Calculating Time Offset Delay = ((t2 – t1)+(t4 – t3))/2 Master Slave t1 Sy F nc Offset = ((t2 –ol t1)-(t4 – t3))/2 Delay low -U 1 p ( Offset = (Delay1–Delay2)/2t1) or t2 t1, t2 Offset = Master Time – Slavet3 Time – Delay eq l_R Delay De In other2 words: t4 De l_R es When Ordinary clockp is Frequency Locked (t4 and you assume Delay1) = Delay2, then any t1, t2, t3, t4 difference is due to error in Time (Offset). BRKIOT-2517 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 14 Packet Delay Variation (PDV) PDV is primarily due to Varying Queue Delays at each hop… Packet Network Master Hop 1 Hop 2 Hop 3 Hop 4 Hop n Slave PTP SessionSession Even High Priority packets get behind a 1518 from time to time. The variance comes from the fact that sometimes you do and sometimes you don’t. It’s all statistics… BRKIOT-2517 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 15 PTP Message rates Message Power profile Default profile Announce 1 Second 2 second intervals Sync 1 Second 1 Follow-up ( two step only) Triggered by Sync Triggered by Sync Delay Request NA 32 seconds to slaves from BC/GMC* Delay Response NA Triggered by Delay request Peer Delay Request 1 second; NA 802.1AS = 8 / second Peer Delay Response Triggered by Peer Delay request NA ‘*’ burst at beginning then fall back,path delay should not change BRKIOT-2517 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 16 PTP messaging End to End Time Synchronization across the network How PTP works to distribute time using messages GPS Antenna A ‘typical’ Ethernet network topology Grandmaster A single PTP Domain M S Transparent Transparent Clock Clock M M Boundary Clock Transparent Clocks S S S S S Ordinary Clocks BRKIOT-2517 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 18 Synchronization across the network - Sync GPS ‘Sync’ from GMC to all Ordinary Clocks (slaves) Antenna throughout the PTP Domain Grandmaster Clock 1. Starts from GMC M sync 2. Passed to from Master Ports to Slave ports by S sync sync network devices Transparent Transparent Clock M Clock BC M 3. Arrives at Ordinary Clocks Boundary sync Clock sync sync Transparent Clocks sync sync sync S S S S S Ordinary Clocks BRKIOT-2517 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 19 Synchronization across the network – Delay Req GPS Delay Request from all Ordinary Clocks toward GMC Antenna throughout the PTP Domain Grandmaster Clock 1. Starts at ordinary clocks M Delay_Req 2. Passed to from Slave Ports to Master ports by S Delay_Req network devices Delay_Req Transparent Transparent Clock M Clock BC M 3. Delay_Req stop at the Boundary Clock Boundary Delay_Req Clock Delay_Req Delay_Req 1. BC initiates its own Delay_Req Transparent Clocks Delay_Req Delay_Req S S S S S Ordinary Clocks BRKIOT-2517 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 20 End to End Sync Msg – 2 Step Ordinary Clock GMC E2E TC E2E TC link link or link BC SYNC t1 path delay (pd) SYNC Residence Follow up Time (rt) (contains t1) T1 not modified by SYNC Residence E2E TCs Time (rt) Follow up (contains t1 , rt , pd) t2 Follow up Follow up Contains t1, and All Delay (contains t1, - except path delay of last hop sum of all rt, OC must compute its own sum of all pd) path delay on last hop ‘rt’ of SYNC carried in correction field of Follow_Up BRKIOT-2517 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 21 End to End Delay_Req and Delay_Resp – 2 Step Ordinary Clock GMC E2E TC E2E TC link link or link BC Delay_Req Residence t Time (rt) 3 T3 not Delay_Req modified by Residence Time (rt) E2E TCs Delay_Req t4 Master responds with T4 Delay_Resp (contains T4) Delay_Resp (contains T4, rt for T3) Delay_Resp (contains T4, sum of rt for T3) ‘rt’ of Delay_Req carried in correction field of Delay_Resp BRKIOT-2517 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 22 Peer to Peer Transparent Clock – Sync and Delay P2P MASTER Transparent SLAVE Master time = TM Clock Slave time = TS t = TM + offset 1 SYNC Offset = ((t2 – t1)–(t4 – t3))/2 Residency Time (rt) SYNC Offset = (t2 – t1) pt1 pDelay_Request – PD2 t 2 – correctionField pt 2 pDelay_Request pt1 pt 3 pDelay_Response pt2 correctionField = PD1 + rt pt4 pt 3 pDelay_Response PD : meanPathDelay pt PD1= ((pt2 – pt1)+(pt4 – pt3))/2 4 PD2= ((pt2 – pt1)+(pt4 – pt3))/2 BRKIOT-2517 © 2019 Cisco and/or its affiliates.
Load more

Recommended publications
  • Time-Synchronized Data Collection in Smart Grids Through Ipv6 Over
    Time-synchronized Data Collection in Smart Grids through IPv6 over BLE Stanley Nwabuona Markus Schuss Simon Mayer Pro2Future GmbH Graz University of Technology Pro2Future GmbH and Graz Graz, Austria Graz, Austria University of Technology [email protected] [email protected] Graz, Austria [email protected] Konrad Diwold Lukas Krammer Alfred Einfalt Siemens Corporate Siemens Corporate Siemens Corporate Technology Technology Technology Vienna, Austria Vienna, Austria Vienna, Austria [email protected] [email protected] [email protected] ABSTRACT INTRODUCTION For the operation of electrical distribution system an increased Due to the progressing integration of distributed energy re- shift towards smart grid operation can be observed. This shift sources (such as domestic photovoltaics) into the distribution provides operators with a high level of reliability and efficiency grid [5], conventional – mostly passive – monitoring and con- when dealing with highly dynamic distribution grids. Techni- trol schemes of power systems are no longer applicable. This cally, this implies that the support for a bidirectional flow of is because these are not designed to handle and manage the data is critical to realizing smart grid operation, culminating in volatile and dynamic behavior stemming from these new active the demand for equipping grid entities (such as sensors) with grid entities. Therefore, advanced controlling and monitoring communication and processing capabilities. Unfortunately, schemes are required for distribution grid operation (i.e., in- the retrofitting of brown-field electric substations in distribu- cluding in Low-Voltage (LV) grids) to avoid system overload tion grids with these capabilities is not straightforward – this which could incur permanent damages.
    [Show full text]
  • Ieee 802.1 for Homenet
    IEEE802.org/1 IEEE 802.1 FOR HOMENET March 14, 2013 IEEE 802.1 for Homenet 2 Authors IEEE 802.1 for Homenet 3 IEEE 802.1 Task Groups • Interworking (IWK, Stephen Haddock) • Internetworking among 802 LANs, MANs and other wide area networks • Time Sensitive Networks (TSN, Michael David Johas Teener) • Formerly called Audio Video Bridging (AVB) Task Group • Time-synchronized low latency streaming services through IEEE 802 networks • Data Center Bridging (DCB, Pat Thaler) • Enhancements to existing 802.1 bridge specifications to satisfy the requirements of protocols and applications in the data center, e.g. • Security (Mick Seaman) • Maintenance (Glenn Parsons) IEEE 802.1 for Homenet 4 Basic Principles • MAC addresses are “identifier” addresses, not “location” addresses • This is a major Layer 2 value, not a defect! • Bridge forwarding is based on • Destination MAC • VLAN ID (VID) • Frame filtering for only forwarding to proper outbound ports(s) • Frame is forwarded to every port (except for reception port) within the frame's VLAN if it is not known where to send it • Filter (unnecessary) ports if it is known where to send the frame (e.g. frame is only forwarded towards the destination) • Quality of Service (QoS) is implemented after the forwarding decision based on • Priority • Drop Eligibility • Time IEEE 802.1 for Homenet 5 Data Plane Today • 802.1Q today is 802.Q-2011 (Revision 2013 is ongoing) • Note that if the year is not given in the name of the standard, then it refers to the latest revision, e.g. today 802.1Q = 802.1Q-2011 and 802.1D
    [Show full text]
  • Implementing an IEEE 1588 V2 on I.MX RT Using Ptpd, Freertos, and Lwip TCP/IP Stack
    NXP Semiconductors Document Number: AN12149 Application Note Rev. 1 , 09/2018 Implementing an IEEE 1588 V2 on i.MX RT Using PTPd, FreeRTOS, and lwIP TCP/IP stack 1. Introduction Contents This application note describes the implementation of 1. Introduction .........................................................................1 the IEEE 1588 V2 Precision Time Protocol (PTP) on 2. IEEE 1588 basic overview ..................................................2 2.1. Synchronization principle ........................................ 3 the i.MX RT MCUs running FreeRTOS OS. The IEEE 2.2. Timestamping ........................................................... 5 1588 standard provides accurate clock synchronization 3. IEEE 1588 functions on i.MX RT .......................................6 for distributed control nodes in industrial automation 3.1. Adjustable timer module .......................................... 6 3.2. Transmit timestamping ............................................. 8 applications. 3.3. Receive timestamping .............................................. 8 3.4. Time synchronization ............................................... 8 The implementation runs on the i.MX RT10xx 3.5. Input capture and output compare block .................. 8 Evaluation Kit (EVK) board with i.MX RT10xx MCUs. 4. IEEE 1588 implementation for i.MX RT ............................9 The demo software is based on the NXP MCUXpresso 4.1. Hardware components .............................................. 9 4.2. Software components ............................................
    [Show full text]
  • Kysync,Kyland Precision Clock Synchronization Solutions
    Precise Timing Solutions KySYNC,Kyland Precision Clock Synchronization Solutions Introduction Precision clock synchronization solutions are using external precise time reference to establish the synchronization with local clocks by delivering all kinds of time signal. The time source provides the time reference, and the time server distributes the timing. While the time source is not available, the time server’s time keeping ability will be critical to assure the precision of the time reference. So in a precision clock synchronization network, the precision of time reference, time distribution and time keeping are hook-ups and all plays important role in each time node. In order to ensure all legacy devices which only support IRIG-B format could still be synced, the PTP (Precision Time Protocol) signal will need to be converted into IRIG-B format through clock conversion. IEEE 1588 will also be need to be distributed through all kinds of network including PRP/HSR and also SDH network. Kyland provides turnkey timing solution including: High-precision time server and IEEE 1588 industrial Ethernet switches supporting IEEE 1588 in both power profile (C37.238) and telecom profile PTP to IRIG-B time conversion IEEE 1588 over PRP/HSR IEEE 1588 over SDH network TMS (Time Management System) & Service Management System Time tester Satellite KySYNC, Intelligent Gateway, PRP/HSR Solution E1/T1 GPS Antenna Remote Control Center KySYNC Station Level Protection Engineering Server A Sever B Operation Maintenance Operation Workstation Workstation Workstation
    [Show full text]
  • Timing Needs in Cable Networks
    Timing Needs in Cable Networks Yair Neugeboren Director System Architecture, Network and Cloud, ARRIS ITSF 2017 Outline • What is a Cable Network? • Timing Aspects in Cable • Distributed Architecture and Timing Requirements • Mobile Backhaul Support through Cable Networks Copyright 2017 – ARRIS Enterprises, LLC. All rights reserved 09 October 2017 2 Outline • What is a Cable Network? • Timing Aspects in Cable • Distributed Architecture and Timing Requirements • Mobile Backhaul Support through Cable Networks Copyright 2017 – ARRIS Enterprises, LLC. All rights reserved 09 October 2017 3 Cable Services Delivery - Today Commercial Residential Web Surf + OTT Video Voice Data Video Video Digital Analog Telephone Services Services Conferencing On Demand Television Television Gaming HFC Channelized Network Downstream [MHz] Copyright 2017 – ARRIS Enterprises, LLC. All rights reserved 09 October 2017 5 What is DOCSIS? The cable TV industry came together in the late 90’s and set up a group called CableLabs They created a set of specifications called Data Over Cable Service Interface Specifications, or DOCSIS for short DOCSIS defines the electrical and logical interfaces specification for network and RF elements in a cable network DOCSIS is a Point to Multipoint Protocol Downstream is continuous “One to Many” Upstream is dynamically scheduled BW allocation DOCSIS versions are 1.0, 1.1, 2.0, 3.0 and 3.1 Copyright 2017 – ARRIS Enterprises, LLC. All rights reserved 09 October 2017 6 Customer Assurance Lawful Cable Network TopologyRecord / Billing Systems Enforcement Back Office Northbound API The HFC network provides the communications link between the CMTS/CCAP and the stations, STBs, CMs and eMTAs. SDN Controller Abstrac on & Applica on HFC plant consists of up to ~160 km of optical fiber, fewLogi chundred meters of coaxial cable, RF distributions and Amplifiers.
    [Show full text]
  • Synchronization Requirements in Cellular Networks Over Ethernet
    Synchronization Requirements in Cellular Networks over Ethernet IEEE 802.3 TS Interim, May. 2009 J. Kevin Rhee 1, Kyusang Lee 2, and Seung-Hwan Kim 3 1 KAIST, 2 ACTUS Networks, and 3 ETRI, S. Korea Acknowledgment • ChanKyun Lee, KAIST • SeongJin Lim, KAIST Mobile Cellular Network: WiMAXWiMAX/EV/EV/EV/EV----DODODODO PSTN/PLMN AAA Authentication, Authorization and Accounting ACR Access Control Router AR Access Router BR Broader Router PSN GSN GPRS Support Node Internet HA Home Agent IMS IP Multimedia Sub-system BR Home PSDN Packet Data Serving Node NodeB RAS Radio Access Station Gateway AAA GSN/PSDN Femtocell CN Femto ACR ACR NodeB/BTS RNC/BSC 3G RAN RAS 3G MS RAS CDMA EV-DO Femtocell WiMAX Wireless backhaul • Wireless backhaul network connects wireless base stations to the corresponding BSC • It delivers the expected bandwidth requirements of new technologies such as WiMAX, 3G, and 4G. • PSN and TDM can be used for wireless backhaul network Backhaul Cell Site Medium Aggregation Site RNC/BSC TDM TDM TDM/SONET/SDH ATM TDM/ SONET/SDH Ethernet FR/HDLC Ethernet CSAG Ethernet/DSL/PON Ethernet Multiservice SGSN BS Edge Router Radio Bearer Backhaul RNC/BSC Interface Technology Medium SGSN Interface Wireless Backhaul Network BSC: Base Station Controller PSN: Packet Switched Network Backhaul Market Growth • 3G and 4G is driving 25-40% a year growth in mobile backhaul traffic • The Carrier Ethernet markets are expected to increase 76% by 2011 • Data oriented mobile traffic is increasing • Legacy TDM-based system is being replaced packet-based Ethernet
    [Show full text]
  • Time Synchronization in Short Range Wireless Networks
    Filip Gummesson & Kristoffer Hilmersson Time Synchronization in Short Range Wireless Networks Master’s Thesis Time Synchronization in Short Range Wireless Networks Filip Gummesson Kristoffer Hilmersson Series of Master’s theses Department of Electrical and Information Technology LU/LTH-EIT 2016-521 http://www.eit.lth.se Department of Electrical and Information Technology, Faculty of Engineering, LTH, Lund University, 2016. Time Synchronization in Short Range Wireless Networks Filip Gummesson Kristoer Hilmersson u-blox Östra Varvsgatan 4 211 75 Malmö Advisors: Mats Cedervall, EIT Mats Andersson, u-blox June 23, 2016 Printed in Sweden E-huset, Lund, 2016 Abstract Energy ecient wireless devices is a trend that has been on the rise the last few years. Energy eciency properties may ll a function in wireless sensor networks where the devices could run on coin-cell batteries and still last for years. To make sense of the sensor data collected, there is a requirement of accurate time syn- chronization in the network. This report focuses on investigating if present time synchronization standards, NTP and PTP, and de facto-standards, RBS, TPSN, and FTSP, can provide sucient accuracy in a network consisting of devices where energy eciency and mobility are the ground pillars, or if accurate time synchro- nization and the constraints of highly energy ecient devices proves contradictory. The knowledge gained from studying the standards lay the foundation of a case study where RBS was implemented in a network consisting of Bluetooth low energy devices, proving that low millisecond accurate time synchronization was achievable using application based timestamping. Compared to wireless sensor networks consisting of devices not developed with today's high energy eciency focus, the accuracy is a factor thousand less precise, but with some hardware features, like hardware based timestamping and a more accurate clock, it would not be impossible to reduce the gap.
    [Show full text]
  • Configuring Precision Time Protocol (PTP)
    Configuring Precision Time Protocol (PTP) • Finding Feature Information, on page 1 • Restrictions and Limitations for PTP, on page 1 • Information About Precision Time Protocol, on page 2 • Configuring PTP, on page 10 • Examples: Layer 2 and Layer 3 PTP Configurations, on page 18 • Feature History for PTP, on page 22 Finding Feature Information Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required. Restrictions and Limitations for PTP • The output of the show clock command on the device and PTP servo clock displayed in the output of the show platform software fed switch active ptp domain command are not synchronized. These are two different clocks used on the switch. • Inter-VLAN is not supported in PTP Transparent Clock Mode. • PTP is not supported on Cisco StackWise Virtual enabled devices. • The switch supports IEEE 802.1AS and IEEE 1588 Default profile and they are both mutually exclusive. Only one profile can be enabled on the switch at a time. • The Cisco PTP implementation supports only the two-step clock and not the one-step clock.
    [Show full text]
  • Master's Thesis
    Eindhoven University of Technology MASTER Time synchronization in IoT lighting control Beke, T. Award date: 2017 Link to publication Disclaimer This document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Student theses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the document as presented in the repository. The required complexity or quality of research of student theses may vary by program, and the required minimum study period may vary in duration. General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain Department of Mathematics and Computer Science System Architecture and Networking Research Group Time synchronization in IoT lighting control Master Thesis Beke, Tibor Supervisors: dr. T. Oz¸celebi¨ dr. ir. P.H.F.M. Verhoeven ing. H. Stevens dr. ir. E.O. Dijk dr. ir. M.C.W. Geilen Eindhoven, 20 December 2016 Abstract The Internet of Things is the next evolution of the internet, a game-changer in collecting, analyzing and distributing data. The challenge taken up by the OpenAIS (Open Architectures for Intelligent Solid State Lighting Systems) project is to set the leading standard for inclusion of lighting for professional applications into IoT, with a focus on office lighting.
    [Show full text]
  • Layer 2 Configuration Guide, Cisco IOS XE Gibraltar 16.10.X (Catalyst 9500 Switches) Americas Headquarters Cisco Systems, Inc
    Layer 2 Configuration Guide, Cisco IOS XE Gibraltar 16.10.x (Catalyst 9500 Switches) Americas Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 527-0883 © 2018 Cisco Systems, Inc. All rights reserved. CONTENTS CHAPTER 1 Configuring Spanning Tree Protocol 1 Restrictions for STP 1 Information About Spanning Tree Protocol 1 Spanning Tree Protocol 1 Spanning-Tree Topology and BPDUs 2 Bridge ID, Device Priority, and Extended System ID 3 Port Priority Versus Path Cost 4 Spanning-Tree Interface States 4 How a Device or Port Becomes the Root Device or Root Port 7 Spanning Tree and Redundant Connectivity 8 Spanning-Tree Address Management 8 Accelerated Aging to Retain Connectivity 8 Spanning-Tree Modes and Protocols 8 Supported Spanning-Tree Instances 9 Spanning-Tree Interoperability and Backward Compatibility 9 STP and IEEE 802.1Q Trunks 10 Spanning Tree and Device Stacks 10 Default Spanning-Tree Configuration 11 How to Configure Spanning-Tree Features 12 Changing the Spanning-Tree Mode (CLI) 12 Disabling Spanning Tree (CLI) 13 Configuring the Root Device (CLI) 14 Configuring a Secondary Root Device (CLI) 15 Configuring Port Priority (CLI) 16 Configuring Path Cost (CLI) 17 Configuring the Device Priority of a VLAN (CLI) 19 Layer 2 Configuration Guide, Cisco IOS XE Gibraltar 16.10.x (Catalyst 9500 Switches) iii Contents Configuring the Hello Time (CLI) 20 Configuring the Forwarding-Delay Time for a VLAN (CLI) 21 Configuring the Maximum-Aging Time
    [Show full text]
  • IEEE 1588 Precision Time Protocol-Enabled, Three-Port, 10/100 Managed Switch with MII Or RMII
    KSZ8463ML/RL/FML/FRL IEEE 1588 Precision Time Protocol-Enabled, Three-Port, 10/100 Managed Switch with MII or RMII Features Port 2 and Source Address Filtering for Imple- menting Ring Topologies Management Capabilities • MAC Filtering Function to Filter or Forward • The KSZ8463ML/RL/FML/FRL Includes All the Unknown Unicast Packets Functions of a 10/100BASE-T/TX/FX Switch Sys- • Port 1 and Port 2 MACs Programmable as Either tem that Combines a Switch Engine, Frame Buffer E2E or P2P Transparent Clock (TC) Ports for Management, Address Look-Up Table, Queue 1588 Support Management, MIB Counters, Media Access Con- • Port 3 MAC Programmable as Slave or Master of trollers (MAC) and PHY Transceivers Ordinary Clock (OC) Port for 1588 Support • Non-Blocking Store-and-Forward Switch Fabric • Microchip LinkMD® Cable Diagnostic Capabilities Ensures Fast Packet Delivery by Utilizing 1024 for Determining Cable Opens, Shorts, and Length Entry Forwarding Table • Port Mirroring/Monitoring/Sniffing: Ingress and/or Advanced Switch Capabilities Egress Traffic to any Port • Non-Blocking Store-and-Forward Switch Fabric • MIB Counters for Fully Compliant Statistics Gath- Ensures Fast Packet Delivery by Utilizing 1024 ering: 34 Counters per Port Entry Forwarding Table • Loopback Modes for Remote Failure Diagnostics • IEEE 802.1Q VLAN for Up to 16 Groups with Full • Rapid Spanning Tree Protocol Support (RSTP) for Range of VLAN IDs Topology Management and Ring/Linear Recovery • IEEE 802.1p/Q Tag Insertion or Removal on a per • Bypass Mode Ensures Continuity Even
    [Show full text]
  • Audio Video Bridging (AVB) White Paper
    White Paper Audio Video Bridging (AVB) Audio Video Bridging, AVB, is a method for transport of audio and video streams over Ethernet-based networks. It is based on ratified IEEE standards for Ethernet networks that define signaling, transport and synchronization of the audio and video streams. A critical component in a converged, universal network that is shared by legacy data traffic and AV streams is Quality of Service (QoS) because it allows voice and video traffic to be prioritized over data traffic ensuring timely and reliable delivery. AVB takes this concept to a new level by adding stream signaling, automatic bandwidth reservation and traffic prioritization, as well as time synchronization thus allowing high quality digital audio and video streams to be reliably transported over Ethernet. The standard QoS needs to be manually implemented on every device and interface in the path between the sender and receiver. This includes identifying traffic, tagging it with QoS priority values, and then configuring queuing and/ or shaping policies that are applied per interface. This approach labor-intensive and static, i.e. it does not allow for dynamic, on-demand updates.. AVB, on the other hand, has a fully automated end-to-end QoS. As the AV streams are setup all devices along the path automatically and on-demand implement queuing, shaping, and prioritization for each AV stream. When the stream stops, the policies are automatically removed and bandwidth freed up. At the same time, AVB QoS mechanism limits the total amount of interface bandwidth that can be reserved for AV streams, so that other applications get their fair share of the available bandwidth.
    [Show full text]