[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.124, available from https://tools.ietf.org/tools/rfcmarkup/