[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]
Versions: 00
MBONE Deployment Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation
<draft-ietf-mboned-sntp-heart-00.txt> Thomas Pfenning
23 October 1996 Microsoft Corporation
The Use of SNTP as a Multicast Heartbeat
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference mate-
rial or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
The distribution of this memo is unlimited. It is filed as <draft-
ietf-mboned-sntp-heart-00.txt>, and expires May 1, 1997. Please send
comments to the authors.
2. Abstract
This document describes how the Simple Network Time Protocol (SNTP)
can be used to provide a multicast heartbeat. Given the current state
of the art in multicast diagnostics, use of a heartbeat may prove a
useful diagnostic tool for operators as well as for applications
developers. Operators may use the heartbeat to alert themselves to
losses of multicast connectivity in portions of the network. Applica-
tions developers may use the heartbeat to determine whether to enable
multicast features or to default to unicast operation. In the long
term, better solutions (such as improved IGMP diagnostics) are likely
to become available, so that a multicast heartbeat is unlikely to have
long-term utility.
3. Introduction
3.1. Problem statement
Today an increasing number of applications support both multicast and
unicast modes of operation. Typically these applications default to
Aboba & Pfenning [Page 1]
INTERNET-DRAFT 23 October 1996
unicast mode, switching to multicast mode on explicit instructions
from the user. However, it is also possible to initially put an
application into multicast mode, join a group, then wait to receive
packets on the group. If packets arrive, then the application is left
in multicast mode; otherwise, after a suitable timeout interval, the
application is switched to unicast mode. However, this approach is
usually not satisfactory since join latencies of several minutes are
common.
Another issue arises with multicast applications running over dialup
connections. In this case, applications are typically unaware of the
state of the dialup interface; it is possible for the dialup connec-
tion to go down or come up again, possibly with a new IP address
assignment, without the application being notified. In such a case,
the IGMP state of the dialup interface may be cleared, leaving the
dialup interface without any group memberships. Thus the host will not
respond to subsequent IGMP membership queries on the dialup interface,
even though the application believes that its group memberships per-
sist.
3.2. Alternative solutions
The problems described above have several solutions, including:
Use of a multicast heartbeat
IGMP membership query detection
Use of multicast diagnostic tools, such as mtrace
SNMP queries
Additional IGMP messages
3.2.1. Use of a multicast heartbeat group
Both of the problems described above can be addressed by use of a mul-
ticast heartbeat. A heartbeat group is a group to which routers and
NAS devices are continually subscribed, providing low join latencies.
On startup, routers and applications looking to determine whether they
have multicast connectivity can listen to the heartbeat group. Since
the gateway router or NAS device is already subscribed to the heart-
beat group, a host joining the group will experience low join latency,
allowing an application to quickly determine whether to enable multi-
cast features. Once it has determined that multicast connectivity is
available, the application can close the connection, which (assuming
the host is IGMP v2 capable) may result in the host leaving the heart-
beat group.
Similarly, in the case where a dialup interface goes down and the
application stops receiving packets on the multicast group, after a
suitable interval, the application can listen for the presence of the
multicast heartbeat. If it does not receive the heartbeat, it may
then conclude that IGMP membership state has been lost, and should
close and reopen multicast sockets.
Aboba & Pfenning [Page 2]
INTERNET-DRAFT 23 October 1996
3.2.2. IGMP membership query detection
While IGMP membership queries do not provide information on the state
of multicast connectivity, they do provide an indication that a multi-
cast-capable router is present on the network. This information, were
it to be made available to an application, could be used to determine
whether to enable multicast features.
Unfortunately for applications developers, current programming inter-
faces do not provide applications with this information.
3.2.3. Use of multicast diagnostics
Application-initiated mtrace queries could readily be used by applica-
tions to determine connectivity to specific groups. Alternatively,
periodic mtrace queries with a multicast response address could be
used to provide a heartbeat on the mtrace group 224.0.1.32,
mtrace.mcast.net. However, these responses would take up considerably
more bandwidth than SNTP, and it is doubtful that the additional
information provided by mtrace would be useful in this context.
3.2.4. SNMP queries
The IGMP MIB, described in [3] provides access to the IGMP Interface
Table as well as to the IGMP Cache Table. This could be used to deter-
mine whether a router is multicast-capable.
However, while SNMP information is typically available to a management
station operated by a NOC, it is usually not made available to appli-
cations running on arbitrary hosts.
3.2.5. Additional IGMP messages
Today the Internet gets along quite well without a unicast heartbeat.
So we would do well to ask ourselves "why do we not need a unicast
heartbeat?" The answer is that we have ICMP messages to indicate when
a host, network or port is unreachable. As a result, applications
receive timely indications of connectivity problems, and can respond
appropriately.
Not only are there no equivalent ICMP error messages for multicast,
but it is expressly forbidden to generate ICMP messages in response to
a packet with a multicast destination. As a result, a host has no
immediate way of determining that its join request is being sent on a
non-multicast capable network.
However, it may be desirable to provide for additional diagnostic
capabilities within IGMP. Such facilities could include a means for
retrieving the IGMP Interface Table as well as the IGMP Cache Table.
Were such facilities to be required of all multicast-capable routers,
then a host could determine the state of multicast connectivity via an
Aboba & Pfenning [Page 3]
INTERNET-DRAFT 23 October 1996
IGMP query. It is believed that this is the best long-term solution to
the problem.
4. Use of SNTP as a multicast heartbeat
While it is likely that better diagnostic methods will become avail-
able in the long term, given the current state of the art, use of a
multicast heartbeat may prove useful. If such a heartbeat is needed,
then the Simple Network Time Protocol (SNTP) appears ideal for this
purpose.
SNTP was created in order to support synchronization of clocks on the
Internet in situations where the high precision of the Network Time
Protocol (NTP) is not required. SNTP supports unicast, broadcast, and
multicast modes. Unicast mode provides for clock synchronization via a
client/server interaction, and is typically used prior to initiation
of multicast mode. In multicast mode, the SNTP server periodically
sends the time to a designated multicast group, and clients listen to
the messages, but do not reply. Existing SNTP implementations typi-
cally support all three modes, and allow for adjusting both the send-
ing interval as well as the destination port.
With SNTP it is possible to multicast to an address with global scope
or to an administratively scoped address. For example, reference [1]
describes SNTP use of the group address 224.0.1.1 as well as UDP port
123 for both the source and destination ports. In addition, use of an
address in the administratively scoped region may also be desirable.
The use of separate heartbeats for global and administratively scoped
addresses allows an application to determine if multicast connectivity
is available, and if so, whether it is global or exists only within
the administratively scoped region.
Today we face a scarcity of multicast diagnostic tools suitable for
use by Network Operations Centers. By enabling routers as SNTP listen-
ers, and adding one or more SNMP MIB variables, the ability to monitor
multicast connectivity on a network-wide basis can be enhanced.
5. Implementation issues
5.1. Address allocation and group announcements
In cases where a firewall is used, multicast connectivity may be
restricted to the administratively scoped region. In this case, lis-
tening to the SNTP multicast group (224.0.1.1) will not allow an
application or device to determine whether it has multicast connectiv-
ity. It will also need to listen to an equivalent group within the
administratively scoped region.
Currently there is no static multicast group allocated for use of SNTP
within the administratively scoped region. As a result, an announce-
ment mechanism (such as that provided by SAP) can be used to announce
Aboba & Pfenning [Page 4]
INTERNET-DRAFT 23 October 1996
the heartbeat group in the administratively scoped region.
5.2. Use by clients and network devices
In order to provide the desired heartbeats, an SNTP server will typi-
cally be operated within the administratively scoped region, as well
as on the global Internet. On startup, network devices such as routers
or NASes will join 224.0.1.1 as well as the administratively scoped
SNTP group, and will listen to SNTP multicasts on UDP port 123. Having
routers and NASes as perennial members of the heartbeat group is nec-
essary in order to guarantee low latency for host join requests.
On startup, host applications will typically join both the 224.0.1.1
group as well as the administratively scoped heartbeat group, and will
listen on UDP port 123. Should they not receive the expected SNTP
multicasts within 15 seconds (three heartbeat periods), they may then
conclude that multicast connectivity is not available, and take action
accordingly. These actions could include defaulting to unicast opera-
tion, or presenting a dialog indicating the failure to detect multi-
cast connectivity. If multicast connectivity is detected, the applica-
tion may then close the connection.
Similarly, after not receiving packets on a multicast group for at
least 30 seconds, an application may once again listen for the multi-
cast heartbeat. If it does not receive the expected SNTP multicasts
within 15 seconds, it may conclude that multicast connectivity has
been lost, and take action accordingly. These actions could include
closing and reopening multicast sockets (in case dialup connectivity
was lost), or presenting a dialog indicating the loss of signal.
5.3. Security issues
The use of SNTP as a multicast heartbeat makes it a target for mali-
cious individuals interested in disrupting network operation. As noted
in [1], it is possible for any SNTP server to send to the 224.0.1.1
group address. As a result, client implementations will need to check
the authenticity of the source. This should be accomplished by check-
ing the source IP address, as well as by taking advantage of the
authenticator field within SNTP.
5.4. Bandwidth consumption
A major concern with implementation of a heartbeat capability is the
resulting bandwidth consumption, and CPU utilization. Since the SNTP
heartbeat described in this document would be implemented by a variety
of network devices, it will consume bandwidth on an Internet-wide
basis. In addition, determining the authenticity of the SNTP multicast
heartbeat requires use of public-key cryptography, and can take as
long as several hundred milliseconds.
Aboba & Pfenning [Page 5]
INTERNET-DRAFT 23 October 1996
As defined in [1], the SNTP packet is 60 octets in length. This when
added to the 28 octet IP/UDP header gives a total packet size of 88
octets. In order to keep bandwidth consumption to an minimum, we rec-
ommend that the interval between SNTP multicasts be set to 5 seconds
or greater. Keeping to these guidelines will keep the SNTP bandwidth
consumption under 200 bps.
6. Acknowledgements
Thanks to Tom Blank of Microsoft and Louis Mamakos of UUNET for many
useful discussions of this problem space.
7. References
[1] D. Mills. "Simple Network Time Protocol." RFC 1769, University
of Delaware, March 1995.
[2] S.E. Deering. "Host Extensions for IP Multicasting." RFC 1112,
Stanford University, August, 1989.
[3] K. McCloughrie, D. Farinacci. "Internet Group Management Proto-
col MIB." draft-ietf-idmr-igmp-mib-03.txt, cisco Systems, June 1996.
8. Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 206-936-6605
EMail: bernarda@microsoft.com
Thomas Pfenning
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 206-703-4830
EMail: thomaspf@microsoft.com
Aboba & Pfenning [Page 6]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/