SIP User's Manual 372 Document #: LTRT-68806
Mediant 2000 & TP-1610 & TP-260/UNI
8.8 Simple Network Time Protocol Support
The Simple Network Time Protocol (SNTP) client functionality generates requests and
reacts to the resulting responses using the NTP version 3 protocol definitions (according to
RFC 1305). Through these requests and responses, the NTP client synchronizes the
system time to a time source within the network, thereby eliminating any potential issues
should the local system clock 'drift' during operation. By synchronizing time to a network
time source, traffic handling, maintenance, and debugging become simplified for the
network administrator.
The NTP client follows a simple process in managing system time: the NTP client requests
an NTP update, receives an NTP response, and updates the local system clock based on a
configured NTP server within the network.
The client requests a time update from a specified NTP server at a specified update
interval. In most situations, this update interval is every 24 hours based on when the
system was restarted. The NTP server identity (as an IP address) and the update interval
are user-defined that can be specified using the Embedded Web Server (refer to
'Configuring the Application Settings' on page 157), the ini file (NTPServerIP and
NTPUpdateInterval respectively), or an SNMP MIB object (refer to the SIP Series
Reference Manual).
When the client receives a response to its request from the identified NTP server it must be
interpreted based on time zone, or location, offset that the system is to a standard point of
reference called the Universal Time Coordinate (UTC). The time offset that the NTP client
uses is configurable using the Embedded Web Server (refer to 'Configuring the Application
Settings' on page 157), the ini file (NTPServerUTCOffset), or via an SNMP MIB object
(refer to the SIP Series Reference Manual).
If required, the clock update is performed by the client as the final step of the update
process. The update is performed in such a way as to be transparent to the end users. For
instance, the response of the server may indicate that the clock is running too fast on the
client. The client slowly robs bits from the clock counter to update the clock to the correct
time. If the clock is running too slow, then in an effort to catch the clock up, bits are added
to the counter, causing the clock to update quicker and catch up to the correct time. The
advantage of this method is that it does not introduce any disparity in the system time that
is noticeable to an end user or that could corrupt call timeouts and timestamps.
8.9 IP QoS via Differentiated Services (DiffServ)
DiffServ is an hitecture providing different types or levels of service for IP traffic. DiffServ
(according to RFC 2474) offers the capability to prioritize certain traffic types depending on
their priority, thereby, accomplishing a higher-level QoS at the expense of other traffic
types. By prioritizing packets, DiffServ routers can minimize transmission delays for time-
sensitive packets such as VoIP packets.
The gateway can be configured to set a different DiffServ value to IP packets according to
their class-of-service (i.e., Network, Premium Media, Premium Control, Gold, and Bronze).
For the mapping of an application to its class-of-service, refer to 'IEEE 802.1p/Q (VLANs
and Priority)' on page 373.
The DiffServ parameters are described in 'Networking Parameters' on page 273.
To Next Page
Loading...
Need help?
General