Cisco Connected Grid Switch Software Configuration Guide, Cisco IOS Release 15.0(2)SE
Cisco IOS Release 15.0(2)SE Features
IEEE 1588 Precision Time Protocol
Power Profile Modes on the Switch
PTP Clock Modes Supported on the Switch
Switch Configuration Guidelines for PTP
Configuring PTP Power Profile Mode on the Switch
Configuring Non-Power Profile Mode on the Switch
Tagging Behavior for PTP Packets
Temperature and Voltage Monitoring
Power Supply Voltage Monitoring
Monitoring and Storing Temperature and Voltage Data
Configuring Temperature and Voltage Monitoring Options
Configure Temperature Monitoring Features
Configure Power Supply Monitoring Features
Configure RPS Monitoring Features
Temperature and Voltage Monitoring Show Commands
Enable Entity Sensor Threshold Notifications
Specify SNMP Notification Recipients
Last revised: October 10, 2012
This guide provides configuration information about the software features released in Cisco IOS Release 15.0(2)SE. This software release is supported on the Connected Grid switch devices listed in the section Supported Hardware. This document should be used in conjunction with the related software documentation for the supported devices.
For details on the software release, please refer to the Release Notes for Cisco IOS Release 15.0(2)SE:
http://www.cisco.com/en/US/partner/docs/switches/lan/catalyst3750/software/release/15.0_2_se/release/notes/OL25301.html
|
Send your feedback about this document directly to the Connected Grid Documentation Team. |
This section describes Precision Time Protocol (PTP) and how to configure it on the switch. This section includes following topics:
Precision Time Protocol (PTP) is defined in IEEE-1588 as Precision Clock Synchronization for Networked Measurements and Control Systems, and was developed to synchronize the clocks in packet-based networks that include distributed device clocks of varying precision and stability. PTP is designed specifically for industrial, networked measurement and control systems, and is optimal for use in distributed systems because it requires minimal bandwidth and little overhead processing.
Note The section About Precision Time Protocol, is a general discussion of PTP and PTP profiles. If you are familiar with PTP and PTP profiles, you can skip to the section Configuring PTP on the Switch, which describes the switch default PTP configuration and how to configure the switch PTP options.
Smart grid power automation applications such as peak-hour billing, virtual power generators, and outage monitoring and management, require extremely precise time accuracy and stability. Timing precision improves network monitoring accuracy and troubleshooting ability.
In addition to providing time accuracy and synchronization, the PTP message-based protocol can be implemented on packet-based networks, such as Ethernet networks. The benefits of using PTP in an Ethernet network include:
In an Ethernet network, switches provide a full-duplex communication path between network devices. Switches send data packets to packet destinations using address information contained in the packets. When the switch attempts to send multiple packets simultaneously, some of the packets are buffered by the switch so that they are not lost before they are sent. When the buffer is full, the switch delays sending packets. This delay can cause device clocks on the network lose synchronization with one another.
Additional delays can occur when packets entering a switch are stored in local memory while the switch searches the MAC address table to verify packet CRC fields. This process causes variations in packet forwarding time latency, and these variations can result in asymmetrical packet delay times.
Adding PTP to a network can compensate for these latency and delay problems by correctly adjusting device clocks so that they stay synchronized with one another. PTP enables network switches to function as PTP devices, including boundary clocks and transparent clocks.
Note To learn more about PTP clock devices and their role in a PTP network, refer to the section PTP Clocks.
To ensure clock synchronization, PTP requires an accurate measurement of the communication path delay between the time source ( master) and the receiver ( slave). PTP sends messages between the master and slave device to determine the delay measurement. Then PTP measures the exact message transmit time and receive times and uses these times to calculate the communication path delay. PTP then adjusts current time information contained in network data for the calculated delay, resulting in more accurate time information.
This delay measurement principle determines path delay between devices on the network and the local clocks are adjusted for this delay using a series of messages sent between masters and slaves. The one-way delay time is calculated by averaging the path delay of the transmit and receive messages. This calculation assumes a symmetrical communication path; however, switched networks do not necessarily have symmetrical communication paths, due to the buffering process.
PTP provides a method, using transparent clocks, to measure and account for the delay in a time-interval field in network timing packets, making the switches temporarily transparent to the master and slave nodes on the network. An end-to-end transparent clock forwards all messages on the network in the same way that a switch does.
shows a typical 1588 PTP network that includes grandmaster clocks, switches in boundary clock mode, and Intelligent Electronic Device (IEDs) such as a digital relays or protection devices. In this diagram, Master 1 is the grandmaster clock. If Master 1 becomes unavailable, the boundary clock slaves switch to Master 2 for synchronization.
This section describes the PTP event message sequences that occur during synchronization.
Synchronizing with Boundary Clocks
The ordinary and boundary clocks configured for the delay request-response mechanism use the following event messages to generate and communicate timing information:
These messages are sent in the following sequence:
1. The master sends a Sync message to the slave and notes the time (t1) at which it was sent.
2. The slave receives the Sync message and notes the time of reception (t2).
3. The master conveys to the slave the timestamp t1 by embedding the timestamp t1 in a Follow_Up message.
4. The slave sends a Delay_Req message to the master and notes the time (t3) at which it was sent.
5. The master receives the Delay_Req message and notes the time of reception (t4).
6. The master conveys to the slave the timestamp t4 by embedding it in a Delay_Resp message.
After this sequence, the slave possesses all four timestamps. These timestamps can be used to compute the offset of the slave clock relative to the master, and the mean propagation time of messages between the two clocks.
The offset calculation is based on the assumption that the time for the message to propagate from master to slave is the same as the time required from slave to master. This assumption is not always valid on an Ethernet network, due to asymmetrical packet delay times.
Figure 2 Detailed Steps—Boundary Clock Synchronization
Synchronizing with Peer-to-Peer Transparent Clocks
When the network includes multiple levels of boundary clocks in the hierarchy, with non-PTP enabled devices between them, synchronization accuracy decreases.
The round-trip time is assumed to be equal to mean_path_delay/2, however this is not always valid for Ethernet networks. To improve accuracy, the resident time of each intermediary clock is added to the offset in the end-to-end transparent clock. Resident time, however, does not take into consideration the link delay between peers, which is handled by peer-to-peer transparent clocks.
Peer-to-peer transparent clocks measure the link delay between two clock ports implementing the peer delay mechanism. The link delay is used to correct timing information in Sync and Follow_Up messages.
Peer-to-peer transparent clocks use the following event messages:
These messages are sent in the following sequence:
1. Port 1 generates timestamp t1 for a Pdelay_Req message.
2. Port 2 receives and generates timestamp t2 for this message.
3. Port 2 returns and generates timestamp t3 for a Pdelay_Resp message.
To minimize errors due to any frequency offset between the two ports, Port 2 returns the Pdelay_Resp message as quickly as possible after the receipt of the Pdelay_Req message.
4. Port 2 returns timestamps t2 and t3 in the Pdelay_Resp and Pdelay_Resp_Follow_Up messages respectively.
5. Port 1 generates timestamp t4 after receiving the Pdelay_Resp message. Port 1 then uses the four timestamps (t1, t2, t3, and t4) to calculate the mean link delay.
Figure 3 Detailed Steps—Peer-to-Peer Transparent Clock Synchronization
In an ideal PTP network, the master and slave clock operate at the same frequency. However, drift can occur on the network. Drift is the frequency difference between the master and slave clock. You can compensate for drift by using the time stamp information in the device hardware and follow-up messages (intercepted by the switch) to adjust the frequency of the local clock to match the frequency of the master clock.
The Best Master Clock (BMC) algorithm is the basis of PTP functionality. BMC specifies how each clock on the network determines the best master clock in its subdomain of all the clocks it can see, including itself. The BMC algorithm runs on the network continuously and quickly adjusts for changes in network configuration.
BMC uses the following criteria to determine the best master clock in the subdomain:
In addition to identifying the best master clock, BMC also ensures that clock conflicts do not occur on the PTP network by ensuring that:
A PTP network is made up of PTP-enabled devices and devices that are not using PTP. The PTP-enabled devices typically consist of the following clock types, which are described in this section:
Within a PTP domain, the grandmaster clock is the primary source of time for clock synchronization using PTP. The grandmaster clock usually has a very precise time source, such as a GPS or atomic clock. When the network does not require any external time reference and only needs to be synchronized internally, the grandmaster clock can free run.
An ordinary clock is a PTP clock with a single PTP port. It functions as a node in a PTP network and can be selected by BMC as a master or slave within a subdomain. Ordinary clocks are the most common clock type on a PTP network because they are used as end nodes on a network that is connected to devices requiring synchronization. Ordinary clocks have various interface to external devices.
A boundary clock in a PTP network operates in place of a standard network switch or router. Boundary clocks have more than one PTP port, and each port provides access to a separate PTP communication path. Boundary clocks provide an interface between PTP domains. They intercept and process all PTP messages, and pass all other network traffic. The boundary clock uses the BMC algorithm to select the best clock seen by any port. The selected port is then set as a slave. The master port synchronizes the clocks connected downstream, while the slave port synchronizes with the upstream master clock.
The role of transparent clocks in a PTP network is to update the time-interval field that is part of the PTP event message. This update compensates for switch delay and has an accuracy of within one picosecond.
There are two types of transparent clocks:
End-to-end (E2E) transparent clocks measure the PTP event message transit time (also known as resident time) for SYNC and DELAY_REQUEST messages. This measured transit time is added to a data field (correction field) in the corresponding messages:
The slave uses this information when determining the offset between the slave’s and the master’s time. E2E transparent clocks do not provide correction for the propagation delay of the link itself.
Peer-to-peer (P2P) transparent clocks measure PTP event message transit time in the same way E2E transparent clocks do, as described above. In addition, P2P transparent clocks measure the upstream link delay. The upstream link delay is the estimated packet propagation delay between the upstream neighbor P2P transparent clock and the P2P transparent clock under consideration.
These two times (message transit time and upstream link delay time) are both added to the correction field of the PTP event message, and the correction field of the message received by the slave contains the sum of all link delays. In theory this is the total end-to-end delay (from master to slave) of the SYNC packet.
illustrates PTP clocks in a master-slave hierarchy within a PTP network.
This section describes PTP profiles and specifically the PC37.238 IEEE-1588 standard, Power Profile, which is also known as the Profile for Protection Applications.
Note The switch documentation and CLI use the terms Power Profile, power profile mode, and non-power profile mode when referring to this IEEE-1588 profile and its associated configuration values.
The IEEE-1588 definition of a PTP profile is the set of allowed PTP features applicable to a device. A PTP profile is usually specific to a particular type of application or environment and defines the following values:
The IEEE Power Profile defines specific or allowed values for PTP networks used in power substations. The defined values include the optimum physical layer, the higher level protocol for PTP messages, and the preferred best master clock algorithm. The Power Profile values ensure consistent and reliable network time distribution within substations, between substations, and across wide geographic areas.
The switch is optimized for PTP in these ways:
Table 1 lists the configuration values defined by the IEEE-1588 Power Profile.
Table 1 Configuration Values for the IEEE PTP Power Profile and Switch Modes
Ethernet 802.3, with Ethertype 0X88F7. PTP messages are sent as 802.1Q tagged Ethernet frames with a default VLAN 0 and default priority 4. |
Access Ports –Untagged Layer 2 packets, Trunk Ports –802.1Q tagged Layer 2 packets with native VLAN on the port and default priority value of 4. |
||
Peer-to-peer transparent clocks using the peer_delay mechanism. |
End-to-end transparent clocks using the delay_request mechanism. |
||
Two-step and one-step clocks are supported. Two-step is preferred for Ethernet. |
|||
Epoch.1 |
|||
PTP-specific TLV (type, length, value) to indicate Grandmaster ID. |
PTP-specific type, length, and value to indicate Grandmaster ID. |
||
Over 16 hops, slave device synchronization accuracy is within 1 usec (1 microsecond). |
Over 16 hops, slave device synchronization accuracy is within 1 usec (1 microsecond). |
This section describes how to configure the switch for PTP applications.
This section describes the two PTP modes that the switch uses.
Note For detailed information about the IEEE-1588 Power Profile, refer to About the PTP Power Profile.
By default, the switch PTP configuration uses the values defined by the IEEE-1588 Power Profile and the switch is in power profile mode. In this mode:
Table 1 lists the configuration values for the switch in power profile mode.
When power profile mode is disabled on the switch with the no ptp profile power command, the switch is in non-power profile mode. In this mode:
Table 1 lists the configuration values for the switch in non-power profile mode.
PTP synchronization behavior depends on the PTP clock mode that you configure on the switch. You can configure the switch for one of the following global modes:
A switch configured for boundary clock mode participates in selecting the best master clock on the subdomain, selecting from all clocks it can see, including itself. If the switch does not detect a more accurate clock than itself, then the switch becomes the master clock. If a more accurate clock is detected, then the switch synchronizes to that clock and becomes a slave clock.
After initial synchronization, the switch and the connected devices exchange PTP timing messages to correct the changes caused by clock offsets and network delays. These are some guidelines for this mode:
A switch configured for forward mode passes incoming PTP packets as normal multicast traffic. These are some guidelines for this mode:
A switch configured for end-to-end transparent clock mode does not synchronize its clock with the master clock. A switch in this mode does not participate in master clock selection and uses the default PTP clock mode on all ports. These are some guidelines for this mode
A switch configured for peer-to-peer transparent clock mode does not synchronize its clock with the master clock. A switch in this mode does not participate in master clock selection and uses the default PTP clock mode on all ports. These are some guidelines for this mode:
Be aware of the guidelines in this section when you configure PTP on the switch.
If the grandmaster clock is not compliant with PTP and sends announce messages without these TLVs, configure the switch to process the announce message by entering the ptp allow-without-tlv command.
Refer to the section Configuring PTP Power Profile Mode on the Switch, for a complete description of this command.
To change to Boundary Clock Mode and the peer_delay mechanism, enter the ptp mode boundary pdelay-req command.
Refer to the section Configuring Non-Power Profile Mode on the Switch, for a complete description of this command.
To change to Boundary Clock Mode with the delay_request mechanism, enter the ptp mode boundary delay-req command.
– When the PTP interface is configured as an access port, PTP messages are sent as untagged, Layer 2 packets.
– When the PTP interface is configured as a trunk port, PTP packets are sent as 802.1q tagged Layer 2 packets over the port native VLAN.
This section describes how to configure the switch to use the PTP Power Profile and operate in power profile mode.
These are some guidelines for configuring the Power Profile on the switch:
To configure the switch for power profile mode, follow these steps:
Enables the PTP Power Profile on the switch and configures the switch for power profile mode (if the switch is in non-power profile mode). The switch default configuration is power profile enabled. If the switch is already in power profile mode, then this command has no effect. |
||
ptp { allow-without-tlv | domain | mode { boundary pdelay-req | p2ptransparent | forward } | packet | priority1 priority | priority2 priority } |
Specifies the synchronization clock mode.
The following options specify the clock priority properties when the switch port is in boundary mode.
|
|
ptp { announce interval interval } | timeout { timeout-in-secs } | delay-req { interval interval } | enable | pdelay-req { interval interval } | sync { interval interval } | limit { offset-in-nanosecs } |
Specifies the settings for PTP timing messages. These options are available only when the switch is in boundary mode.
|
|
This section describes how to configure the switch to operate in non-power profile mode.
The switch sends untagged PTP packets on the native VLAN when the switch port connected to the grandmaster clock is configured as follows:
When the grandmaster clock requires tagged packets, make one of the following configuration changes:
To configure the switch for non-power profile mode, follow these steps:
Configures the switch for non-power profile mode when the switch is in power profile mode. If the switch is already in non-power profile mode, this command has no effect. |
||
ptp { domain | mode boundary delay-req | e2etransparent | forward } | packet | priority1 priority | priority2 priority } |
Specifies the synchronization clock.
These options specify the clock priority properties when the switch port is in boundary mode:
|
|
ptp { announce { interval interval | timeout interval } | delay-req interval interval | enable | sync { interval interval | limit offset-in-nanosecs }} |
Specifies the settings for the timing messages. These options are available only when the switch is in boundary mode.
|
|
This section describes the PTP show command options.
Table 2 describes the switch tagging behavior in power profile and non-power profile modes.
Table 2 Tagging Behavior for PTP Packets
This release includes enhancements to features that support monitoring of the switch operating temperature and power supply voltage. This section describes how to configure this feature on the switch, and includes the following topics:
Earlier software releases for the switch supported user configurable alarm thresholds (maximum and minimum) for the switch operating temperature. You can configure operating temperature ranges (primary and secondary) for the switch, and then configure alarm options to trigger an event message when the switch operating temperature is out of the defined range.
Cisco IOS Release 15.0(2)SE includes a similar feature for the switch power supply. You can configure power supply voltage ranges and then configure alarm options for when the voltage is out of range. These features include:
Cisco IOS Release 15.0(2)SE includes new features to support switch historical data collection and storage. Use these features to configure the switch to save historical data about switch operating temperature and power supply voltage. New features include:
This section describes how often the switch monitors and stores temperature and voltage data.
The switch checks the operating temperature and power supply voltage once per minute.
The switch stores temperature and voltage data as follows:
You must enter the alarm facility history command to enable the switch to store the data that it collects at the monitoring intervals. Refer to these sections for details about how to use these commands:
The switch stores temperature and voltage data for a maximum of 72 hours. After 72 hours, the oldest data is purged as the switch adds the most recent data.
At each monitoring interval, the switch checks the operating temperature and power supply voltage. If the switch detects that either is out of range of the thresholds defined with the alarm facility command, then it generates an event message (alarm). The message type is SYSLOG or SNMP trap. Refer to these sections for details about how to use these commands:
This section describes the temperature and voltage monitoring configuration commands supported in Cisco IOS Release 15.0(2)SE and later.
Use the alarm facility temperature global configuration command to configure temperature thresholds for the purpose of generating event messages (alarms). You can configure an alarm for both of these threshold types.
You can also use this command to:
The switch supports the power supply models described below. The alarm facility power-supply voltage command options and alarm threshold ranges are different for each model.
For detailed information about these power supplies, refer to the switch hardware installation guide.
Use the alarm facility power-supply voltage global configuration command to configure voltage thresholds for the purpose of generating event messages (alarms). You can also use this command to:
Use the alarm facility power-supply rps global configuration command to configure event messages (alarms) for the switch redundant power supply (RPS). Use this command to:
This section describes the temperature and voltage monitoring show commands supported in Cisco IOS Release 15.0(2)SE and later.
This section describes the MIBs that are supported by the TVM feature:
– entSensorThresholdNotificationEnable
– entSensorThreshNotifGlobalEnable
Note TVM supports read operations (get operations) only, including for objects that support read and write operations.
http://www.cisco.com/en/US/products/ps10978/products_installation_and_configuration_guides_list.html
http://www.cisco.com/en/US/products/ps10978/prod_release_notes_list.html