AN1202: ITU-T Precision Time Protocol Grandmaster, Boundary Clock, and Slave Clock Mode

Total Page:16

File Type:pdf, Size:1020Kb

AN1202: ITU-T Precision Time Protocol Grandmaster, Boundary Clock, and Slave Clock Mode AN1202: ITU-T Precision Time Protocol Grandmaster, Boundary Clock, and Slave Clock Mode ITU-T Precision Time Protocol (PTP) is an extension of IEEE1588 Precision Time Pro- tocol that tailors the use of PTP to telecommunication applications. PTP is a key solution KEY FEATURES in transmitting both frequency and time synchronization to achieve 5G network goals. • There are three critical clock types in the Telecommunication technology has been shifting to asynchronous protocols such as IEEE 1588 standard. Ethernet to save on cost. However, this has compromised the network’s ability to • Grandmaster is the top of the maintain timing accuracy. synchronization chain, the requirement for its accuracy is the most stringent. An obvious solution is to add a Global Poisitioning System (GPS) to every site to allow local clocks to synchronize to an accurate clock source. But this is both very expensive, • Boundary Clock receives its synchronization from the grandmaster contradicting the industry’s original intent of being cost effective and less reliable than clock or other Boundary clocks and sends 99.999% availabilty. the synchronization information to downstream boundary clocks and slave Another solution is Network Time Protocol (NTP); however, its accuracy is insufficient clocks. for many applications. The need for a higher accuracy protocol is rising as mobile mar- • Slave Clock receives its synchronization kets approach the challenge of a 5G network. from boundary clocks and it is the last clock in the synchronization chain. PTP is perfectly positioned for these applications because it provides the high accuracy time transfer without requiring a hardware change to the entire network. The protocol can also work in conjunction with SyncE to compensate for nodes that cannot process PTP data. This Application Note will discuss the generic IEEE1588 PTP features and how ITU-T expands on these features for telecommunication use, as well as implementation considerations. silabs.com | Building a more connected world. Rev. 1.1 AN1202: ITU-T Precision Time Protocol Grandmaster, Boundary Clock, and Slave Clock Mode IEEE 1588 Overview 1. IEEE 1588 Overview Although the focus of this paper is the ITU-T application of the IEEE 1588 Precision Timing Protocol, this section will first describe the foundational elements in terms of IEEE1588 before discussing the extensions in ITU-T. The IEEE1588 discussed here is IEEE1588-2008[1]. silabs.com | Building a more connected world. Rev. 1.1 | 2 AN1202: ITU-T Precision Time Protocol Grandmaster, Boundary Clock, and Slave Clock Mode IEEE 1588 Overview 1.1 Grandmaster, Boundary Clock, Slave Clock, and Transparent Clock There are four different types of clocks in the IEEE1588 architecture – grandmaster, boundary clock, slave clock, and transparent clock. In the following figure, the grandmaster is referred to as T-GM, boundary clock as T-BC, slave clock as T-TSC, and transparent clock as T-TC. These are the designated shorthand for PTP clocks in ITU-T, and they will be used throughout this Application Note. As shown in the figure below, the grandmaster receives Time of Day (ToD) and 1 pulse per second (1PPS) information from the GPS and converts it to 1588 timestamp messages. The 1588 messages are passed down to either a telecom time slave clock (T-TSC) or the slave side of a telecom boundary clock (T-BC). If the receiving clock is a T-BC, the master side of the T-BC will then transmit to the next boundary clock, transparent clock, or slave clock. The T-TSC receives the PTP timing information but is not responsible for transmitting it to downstream clocks. ToD 1588 1588 1588 ToD Clocks 1PPS T-GM T-BC T-TC T-TSC GNSS/GPS 1PPS ToD 1PPS Clocks Figure 1.1. IEEE1588 Architecture Block Diagram T-BC and T-TSC can also convert the 1588 messages into clock information in the form of ToD, 1PPS, and other relevant clock fre- quencies depending on the network needs. The telecom transparent clock (T-TC) is another plausible clock type in IEEE1588, it is less common in the ITU-T applications. The role of the transparent clock is to account for the inherent delay that occurred when packets passed through. The T-TC will record the en- trance and exit time of a packet and add the delay (called “residence time”) to the correction field of the packet. A T-TC does not syn- chronize its clock with the master’s clock. Table 18 from IEEEStd 1588-2008 represents the basic packet format [1]. Table 1.1. IEEE1588 Common Elements of a Packet IEEEStd 1588-2008 - Table 18 - Common Message Header Bits Octets Offset 7 6 5 4 3 2 1 0 transportSpecific messageType 1 0 reserved versionPTP 1 1 messageLength 2 2 domainNumber 1 4 reserved 1 5 flagField 2 6 correctionField 8 8 reserved 4 16 sourcePortIdentity 10 20 sequenceId 2 30 controlField 1 32 logMessageInterval 1 33 silabs.com | Building a more connected world. Rev. 1.1 | 3 AN1202: ITU-T Precision Time Protocol Grandmaster, Boundary Clock, and Slave Clock Mode IEEE 1588 Overview 1.2 Definition and Derivation of Two-Way Delay and Offset The most fundamental purpose of PTP is to synchronize the time between clocks, so the foundation of PTP is the Delay Calculation. To synchronize between two clocks, the master clock sends timestamps to the slave clock using one of two methods, One-Way Delay or Two-Way Delay. One-Way Delay can only achieve frequency synchronization while Two-Way Delay can achieve both frequency and time synchroniza- tion. Frequency synchronization allows each clock to have the same time base, i.e., a second lasts the same amount of time for all clocks. Time Synchronization is more stringent because the clocks also must be at the same clock time. One-Way Delay is used when the application only requires frequency synchronization. Two-Way Delay is used in applications with smaller error margins, such as the sub-µs market, where the time synchronization is also critical. In One-Way Delay, only the master transmits timing messages to the slave, and the transmission delay between them is not consid- ered. In Two-Way Delay, the slave responds to the master with a series of timing messages to calculate the transmission delay be- tween the master and the slave. For the math derivations in this section, the variable Offset is defined as the time deviance of the slave clock from the master clock; and the variable Delay is the time spent in transmission. In One-Way Delay mode depicted in the figure below, the master clock sends its clock information to the slave clock using Sync and Follow-up messages. The slave clock corrects its time offset according to the master’s clock time in the time stamps. There is no con- sideration of the transmission delay in One-Way Delay mode. Master Slave Master Slave Offset Sync ta Sync t1 Delay Follow-up t2 Follow-up t3 Delay Request Delay tb Sync t4 Offset Follow-up Delay Response One-Way Two-Way Figure 1.2. One-Way & Two-Way Delay Synchronization The Delay can be calculated using Two-Way Delay mode. Two-Way Delay mode requires additional communication between the slave and the master. A “Delay Request” is sent from the slave and the master responds with a Delay Response. These additional packets provide the slave with additional timestamps to subtract Delay from Offset. Four timestamps are obtained through the Two-Way exchange, t1, t2, t3, and t4. t1 is the time the master transmitted the Sync mes- sage, t2 is the time the slave received it, t3 is the time the slave transmitted the Delay Request message, and t4 is the time the master received it (which is transmitted to the slave via Delay Response). Note: t2 and t3 are measured with the slave’s local clock. Assuming the transmission is symmetrical, the following equations are true: Delay + Offset = t2 - t1 Delay - Offset = t4 - t3 When the two equations are added, the two Offset values cancel each other out, leaving the value of twice the Delay: (Delay + Offset) + (Delay - Offset) = 2Delay + Offset = 2Delay = t2 - t1 + t4 - t3 silabs.com | Building a more connected world. Rev. 1.1 | 4 AN1202: ITU-T Precision Time Protocol Grandmaster, Boundary Clock, and Slave Clock Mode IEEE 1588 Overview Again, assuming symmetry, the value of the Delay can be calculated: t2 - t1 + t4 - t3 Delay = 2 Similarly, for the offset: (Delay + Offset) - (Delay - Offset) = Delay - Delay + 2Offset = t2 - t1 - (t4 - t3) t2 - t1 - (t4 - t3) t2 + t3 - t1 - t4 Offset = = 2 2 The result is an Offset value the slave clock can adjust itself to without the error from the delay. Therefore, a more accurate clock. silabs.com | Building a more connected world. Rev. 1.1 | 5 AN1202: ITU-T Precision Time Protocol Grandmaster, Boundary Clock, and Slave Clock Mode IEEE 1588 Overview 1.3 Two-Step Versus One-Step In the previous section, the One-Way Delay and Two-Way Delay transmissions both start with the transmission of the Sync message. The Sync message transmits the timing information about the master clock. However, there are two methods in IEEE1588 to transmit master timing: One-Step and Two-Step. The difference between One-Step and Two-Step, is that Two-Step needs a Follow-up message to communicate when the previous Sync message was transmitted; while One-Step includes the transmission time of the Sync message in the message itself, as seen in the figure below. Master Slave Master Slave ta Sync ta Sync Follow-up tb Sync tb Sync Follow-up One-Step Two-Step Figure 1.3. One-Step & Two-Step Timestamp It is the master clock designer’s choice to produce either One-Step or Two-Step messages.
Recommended publications
  • 15-744: Computer Networking Multicast Routing Example Applications Overview
    Multicast Routing • Unicast: one source to one destination • Multicast: one source to many destinations 15-744: Computer Networking • Two main functions: • Efficient data distribution • Logical naming of a group L-20 Multicast 2 Example Applications Overview • Broadcast audio/video • IP Multicast Service Basics • Push-based systems • Software distribution • Multicast Routing Basics • Web-cache updates • Teleconferencing (audio, video, shared • Overlay Multicast whiteboard, text editor) • Multi-player games • Reliability • Server/service location • Other distributed applications • Congestion Control 3 4 1 IP Multicast Architecture Multicast – Efficient Data Distribution Src Src Service model Hosts Host-to-router protocol (IGMP) Routers Multicast routing protocols (various) 5 6 Multicast Router Responsibilities IP Multicast Service Model (rfc1112) • Learn of the existence of multicast groups • Each group identified by a single IP address (through advertisement) • Groups may be of any size • Identify links with group members • Members of groups may be located anywhere in the Internet • Establish state to route packets • Members of groups can join and leave at will • Replicate packets on appropriate interfaces • Senders need not be members • Routing entry: • Group membership not known explicitly • Analogy: Src, incoming interface List of outgoing interfaces • Each multicast address is like a radio frequency, on which anyone can transmit, and to which anyone can tune-in. 7 8 2 IP Multicast Addresses Multicast Scope Control – Small TTLs • Class
    [Show full text]
  • 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]
  • IEEE 1588 Frequency and Time & Phase Profiles at ITU-T
    IEEE 1588 Frequency and Time & phase profiles at ITU-T Silvana Rodrigues, System Engineering, IDT , [email protected] WSTS - 2013, San Jose ©2009 Integrated Device Technology, Inc. Agenda ● IEEE-1588TM Profile ● ITU-T G.8265.1 – Frequency Profile ● ITU-T G.8275.1 – Time and Phase Profile ● ITU-T G.8275.2 – Time and Phase Profile with partial support from the network IEEE 1588TM is a trademark of its respective owner www.IDT.com PAGE 2 CONFIDENTIAL IEEE-1588 Profiles ● IEEE-1588 defines profile as “The set of allowed Precision Time Protocol (PTP) features applicable to a device” ● “The purpose of a PTP profile is to allow organizations to specify specific selections of attribute values and optional features of PTP that, when using the same transport protocol, inter-work and achieve a performance that meets the requirements of a particular application.” ● A PTP profile should define ● Best master clock algorithm options ● Configuration management options ● Path delay mechanisms (peer delay or delay request-response) ● The range and default values of all PTP configurable attributes and data set members ● The transport mechanisms required, permitted, or prohibited ● The node types required, permitted, or prohibited ● The options required, permitted, or prohibited * IEEE Std 1588-2008 IEEE Standard for a Precision Clock Synchronization Protocol, copyright 2008 IEEE. All right reserved. www.IDT.com PAGE 3 CONFIDENTIAL ITU-T FREQUENCY PROFILE www.IDT.com PAGE 4 CONFIDENTIAL ITU-T G.8265.1 Frequency Profile IEEE-1588 without support from
    [Show full text]
  • 1722 Over IP
    1722 over IP Kevin Gross 26 October 2010 [email protected] 1722 fields • 802.3 header • 802.1Q tag • Ethertype • Control/data • Subtype • Version • Type specific data • Stream ID • Media clock restart • Sequence number • 802.1AS timestamp • Timestamp uncertain • Gateway info • Length • Payload IP fields • IP header – Version – Header length – DSCP – Total length – ID – Flags – Fragment offset – TTL – Protocol – Header checksum – Source IP – Destination IP • UDP header – Source port number – Destination port number – Checksum – Length RTP fields • Version • Marker • Payload type • Sequence number • Timestamp • Synchronization source • Synchronization routes 1733 RTCP fields • Name • Grandmaster ID • Time base indicator • Stream ID • 802.1AS timestamp 1722 over IP • Ethernet header • 802.1Q tag • IP header – DSCP • UDP header – Length • Control/data • Subtype • Version • Type specific data • Stream ID • Media clock restart • Sequence number • 802.1AS timestamp • Timestamp uncertain • Gateway info • Length • Payload Overhead • 1722 – Ethernet – 38 (includes preamble, header, FCS and IFG) – 802.1Q tag – 4 – 1722 header – 24 – Total = 66 octets • 1733 – Ethernet – 38 – 802.1Q tag – 4 – IP header – 20 or 40 – UDP header – 8 – RTP header – 12 – Total = 82 or 102 octets • 1722 over IP – Ethernet – 38 – 802.1Q tag – 4 – IP header – 20 or 40 – UDP header – 8 – 1722 header – 24 – Total = 94 or 114 octets IP multicast • Internet Group Management Protocol (IGMP) – IPv4 group membership • Multicast Listener Discovery (MLD) – IPv6 group membership • Multicast Address Dynamic Client Allocation Protocol (MADCAP) – RFC 2730. Implemented in Microsoft DHCP servers. Not widely deployed. • Unicast-Prefix-based IPv6 Multicast Addresses – RFC 3306, 3307. Requires ZMAAP. • ZMAAP – Not in use. IETF draft ( draft-ietf-zeroconf-zmaap- 02.txt ) expired in 2003.
    [Show full text]
  • Ipv6 Addresses
    56982_CH04II 12/12/97 3:34 PM Page 57 CHAPTER 44 IPv6 Addresses As we already saw in Chapter 1 (Section 1.2.1), the main innovation of IPv6 addresses lies in their size: 128 bits! With 128 bits, 2128 addresses are available, which is ap- proximately 1038 addresses or, more exactly, 340.282.366.920.938.463.463.374.607.431.768.211.456 addresses1. If we estimate that the earth’s surface is 511.263.971.197.990 square meters, the result is that 655.570.793.348.866.943.898.599 IPv6 addresses will be available for each square meter of earth’s surface—a number that would be sufficient considering future colo- nization of other celestial bodies! On this subject, we suggest that people seeking good hu- mor read RFC 1607, “A View From The 21st Century,” 2 which presents a “retrospective” analysis written between 2020 and 2023 on choices made by the IPv6 protocol de- signers. 56982_CH04II 12/12/97 3:34 PM Page 58 58 Chapter Four 4.1 The Addressing Space IPv6 designers decided to subdivide the IPv6 addressing space on the ba- sis of the value assumed by leading bits in the address; the variable-length field comprising these leading bits is called the Format Prefix (FP)3. The allocation scheme adopted is shown in Table 4-1. Table 4-1 Allocation Prefix (binary) Fraction of Address Space Allocation of the Reserved 0000 0000 1/256 IPv6 addressing space Unassigned 0000 0001 1/256 Reserved for NSAP 0000 001 1/128 addresses Reserved for IPX 0000 010 1/128 addresses Unassigned 0000 011 1/128 Unassigned 0000 1 1/32 Unassigned 0001 1/16 Aggregatable global 001
    [Show full text]
  • Information About Implementing Ipv6 Multicast Routing
    Implementing IPv6 Multicast • Information About Implementing IPv6 Multicast Routing, on page 1 • Implementing IPv6 Multicast, on page 9 • Additional References, on page 31 • Feature Information, on page 32 Information About Implementing IPv6 Multicast Routing This chapter describes how to implement IPv6 multicast routing on the switch. Traditional IP communication allows a host to send packets to a single host (unicast transmission) or to all hosts (broadcast transmission). IPv6 multicast provides a third scheme, allowing a host to send a single data stream to a subset of all hosts (group transmission) simultaneously. IPv6 Multicast Overview An IPv6 multicast group is an arbitrary group of receivers that want to receive a particular data stream. This group has no physical or geographical boundaries--receivers can be located anywhere on the Internet or in any private network. Receivers that are interested in receiving data flowing to a particular group must join the group by signaling their local switch. This signaling is achieved with the MLD protocol. Switches use the MLD protocol to learn whether members of a group are present on their directly attached subnets. Hosts join multicast groups by sending MLD report messages. The network then delivers data to a potentially unlimited number of receivers, using only one copy of the multicast data on each subnet. IPv6 hosts that wish to receive the traffic are known as group members. Packets delivered to group members are identified by a single multicast group address. Multicast packets are delivered to a group using best-effort reliability, just like IPv6 unicast packets. The multicast environment consists of senders and receivers.
    [Show full text]
  • Introduction to IP Multicast Routing
    Introduction to IP Multicast Routing by Chuck Semeria and Tom Maufer Abstract The first part of this paper describes the benefits of multicasting, the Multicast Backbone (MBONE), Class D addressing, and the operation of the Internet Group Management Protocol (IGMP). The second section explores a number of different algorithms that may potentially be employed by multicast routing protocols: - Flooding - Spanning Trees - Reverse Path Broadcasting (RPB) - Truncated Reverse Path Broadcasting (TRPB) - Reverse Path Multicasting (RPM) - Core-Based Trees The third part contains the main body of the paper. It describes how the previous algorithms are implemented in multicast routing protocols available today. - Distance Vector Multicast Routing Protocol (DVMRP) - Multicast OSPF (MOSPF) - Protocol-Independent Multicast (PIM) Introduction There are three fundamental types of IPv4 addresses: unicast, broadcast, and multicast. A unicast address is designed to transmit a packet to a single destination. A broadcast address is used to send a datagram to an entire subnetwork. A multicast address is designed to enable the delivery of datagrams to a set of hosts that have been configured as members of a multicast group in various scattered subnetworks. Multicasting is not connection oriented. A multicast datagram is delivered to destination group members with the same “best-effort” reliability as a standard unicast IP datagram. This means that a multicast datagram is not guaranteed to reach all members of the group, or arrive in the same order relative to the transmission of other packets. The only difference between a multicast IP packet and a unicast IP packet is the presence of a “group address” in the Destination Address field of the IP header.
    [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]
  • Shortest Path Bridging IEEE 802.1Aq
    Shortest Path Bridging IEEE 802.1aq NANOG49 June 13-16/2010 Peter Ashwood-Smith Fellow [email protected] Abstract 802.1aq Shortest Path Bridging is being standardized by the IEEE as an evolution of the various spanning tree protocols. 802.1aq allows for true shortest path routing, multiple equal cost paths, much larger layer 2 topologies, faster convergence, vastly improved use of the mesh topology, single point provisioning for logical membership (E-LINE/E-LAN/E-TREE etc), abstraction of attached device MAC addresses from the transit devices, head end and/or transit multicast replication , all while supporting the full suit of 802.1 OA&M. 2 Outline • Challenges • What is 802.1aq/SPB • Applications • How does it work • Example (won’t cover but included here) 3 Challenges • L2 networks that scale to ~1000 bridges. • Use of arbitrary mesh topologies. • Use of (multiple) shortest paths. • Efficient broadcast/multicast routing and replication points. • Avoid address learning by tandem devices. • Get recovery times into 100’s of millisecond range for larger topologies. • Good scaling without loops. • Allow creation of very many logical L2 topologies (subnets) of arbitrary span. • Maintain all L2 properties within the logical L2 topologies (transparency, ordering, symmetry, congruence, shortest path etc). • Reuse all existing Ethernet OA&M 802.1ag/Y.1731 4 Example STP 36 nodes 1- Can’t use these links SOURCE ROOT A1.. A100 DEST 2 - LEARN A1..A100 5 Outline • Challenges • What is 802.1aq/SPB • Applications • How does it work 6 What is 802.1aq/SPB • IEEE protocol builds on 802.1 standards • A new control plane for Q-in-Q and M-in-M – Leverage existing inexpensive ASICs – Q-in-Q mode called SPBV – M-in-M mode called SPBM • Backward compatible to 802.1 – 802.1ag, Y.1731, Data Center Bridging suite • Multiple loop free shortest paths routing – Excellent use of mesh connectivity – Currently 16, path to 1000’s including hashed per hop.
    [Show full text]
  • IP Multicast
    Data Communication & Networks G22.2262-001 Session 10 - Main Theme IP Multicast Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical Sciences 1 Agenda Introduction to Multicast Multicast Addresses IP Multicast Reliable Multicast Pragmatic General Multicast (PGM) Reliable Multicast Protocol (RMP) Conclusion 2 Part I Introduction to Multicast 3 Cast Definitions Unicast - send to one destination (198.122.15.20) General Broadcast - send to EVERY local node (255.255.255.255) Directed Broadcast - send to subset of nodes on LAN (198.122.15.255) Multicast - send to every member of a Group of “interested” nodes (Class D address). RFC 1112 (an easy read!) 4 Why Multicast, Why Not Unicast? Unicast: Many applications require same message sent to many nodes (10, 100, 1000, n) Same message transits network n times. n messages requires n*(CPU time) as 1 message Need to deliver “timely” information. Message arrives at node n >> node 1 5 Why Multicast, Why Not Broadcast? Broadcast: Send a copy to every machine on the net Simple, but inefficient All nodes “must” process the packet even if they don’t care Wastes more CPU cycles of slower machines (“broadcast radiation”) General broadcast cannot be routed Directed broadcast is limited in scope (to machines on same sub-net or same domain) 6 Multicast Applications News/sports/stock/weather updates Software distribution Video-conferencing, shared whiteboards Distributed interactive gaming or simulations Email distribution lists Database replication 7 IP Multicast - Concepts Message sent to multicast “group” of receivers Senders need not be group members Each group has a “group address” Groups can have any size End-stations (receivers) can join/leave at will Data Packets are UDP (uh oh!) 8 IP Multicast Benefits Distribution tree for delivery/distribution of packets (i.e., scope extends beyond LAN) Tree is built by multicast routing protocols.
    [Show full text]