Alex Mailer

The  need  for  and  use  of Time-To-Live or simply TTL  scoping was  largely motivated by  the  kinds  of multicast  routing protocols  that were  first  developed. These  protocols  were  based  on  broadcasting data  to  the entire  network  and  then  having  uninterested  receivers  prune  their  links  from  the  tree.  The two  most  common  of  these  protocols  were  the  Distance  Vector  Multicast  Routing  Protocol (DVMRP) and Protocol  Independent Multicast-Dense Mode  (PIM-DM).  From  an  application  programmer  point  of view,  the most  important  thing  to  know  is  that  these  protocols  had  the  undesirable  property of broadcasting  large  amounts  of  data  to  the  network.  Because  of  this  property,  DVMRP  and PIM-DM are  referred  to  as  dense  mode  or broadcast-and-prune  protocols. The  approach  used  by  dense  mode  protocols  to  get  packets  to  all  group  members  is obviously  very  unscalable. 

However,  it  was  effective  as  a  first  effort  in  reaching  potential receivers  and  letting  them  know  that  there  was  multicast  traffic  for  a  group.  This  function has  since  been  replaced  by  using  rendezvous  points  (or  having  receivers  explicitly  learn  of sources  in  the  SSM model).  The  modern  set  of  protocols  is  called  sparse  mode  or  join-and- graft  protocols. With  these  protocols,  multicast packets  flow only  across  links  that  have been explicitly added  to  a  tree by join messages  from  receivers. With dense mode protocols,  because  a potentially  significant  amount  of unwanted  traffic is being broadcast  around  the network,  it is important  to  try to control  the  scope of a multicast group.

The goal should be  to limit the amount of unsolicited traffic that flows across  links of the multicast  infrastructure.  Imagine  the  early days  of multicast when  the  number  of  events was increasing  rapidly.  As more  events  were  occurring,  multicast-capable  routers  were  spending an  increasing  amount  of  time  removing  themselves  from broadcast  trees because  they had  no interested  downstream  receivers. As  use  of multicast  grew,  it became  increasingly  important to  control  the  scope  in  order  to  limit  the  areas  of  the  network  in which  a  broadcast  from  a particular  source would  reach. While  there might  still be  “global” events, many more multicast groups were being created  for more  regional or local videoconferences.  The  solution was  to  try to  control  the  scope  of a group  based  on  the  group  creator’s  perceived  level of  local,  regional, or  global  interest. TTL Scoping Details Scoping  is  implemented  by  overloading  the  TTL  function  in  the  IP  header. 

Consider  what happens  in  the  simple  case when  the  TTL value  of  a multicast  packet  is  set  to  1. The  packet makes  it  to  the  first  hop  router  and  is  discarded. All receivers  that  are within  one  hop  receive the packet, but no one  else does. Given that  the TTL can be  any integer between 0 and  255,  this gives  a programmer  a  reasonable  amount  of control  in  scoping  a  stream of multicast packets. Instead  of re-presenting  the  details  on how  to  set  the TTL value  of a packet.  The  more  important  question  for  the programmer  is what  to  set  the  TTL value  to be. Implications of TTL Scoping The use  of TTL scoping  is no  longer particularly needed  or particularly effective  at  controlling the  scope  of  a  multicast  transmission.  The  key  reason  is  that  dense  mode  protocols  have almost  completely disappeared.  Therefore,  network  administrators  do not  necessarily need  to worry  about  overwhelming  amounts  of unrequested  multicast  traffic. TTL  scoping  is  also  not particularly  effective  because  it  presumes  the  use  of  thresholds.  Thresholds  allow  a  network administrator  to  configure  routers  to  throw multicast packets  away if their TTL value  is below some  level. This  allows  the  administrator  to  protect  a network  from  external multicast  traffic that  does  not  have  a  large  enough TTL. However,  in practice,  because  TTL scoping  is not used, neither  are  thresholds. Thresholds  are  used  to  keep  multicast  group  traffic  limited  to  a  specific  area.  These areas  can  be  either  local,  organizational,  regional,  or  worldwide.  When  multicast  was  first being  deployed,  it was  common  practice  to  use  1,  16,  63,  and  127,  representing  local  subnet, organization,  regional,  and  global,  respectively.  In  this way,  if  an  organization wanted  to  use TTL scoping  to  limit transmissions  from being  sent outside  the organization,  a TTL of 16 could be used.  This would be  enforced by all border  routers  implementing a  threshold  for multicast. If  a multicast  packet  was  received with  a  TTL  less  than  16,  it would  be  thrown  away.  In  this way an application programmer  could  ensure  that  a TTL of  16 was  sufficiently high  to reach all receivers  in  the  organization but not  so high  that packets would  leak across  the  organization’s link to the Internet.

Network administrators would figure  the threshold based on a value slightly higher  than  the  diameter  of  their  network. Aside  from  the  fact  that TTL scoping  is not  particularly necessary  for wide-area  applica- tions,  it  still has  its uses  for  local  testing.  For  example,  if writing  and  testing  an  application,  it is  helpful  to  use  a  small TTL  to  avoid  packets  being  sent  to  places  they  should  not  be  due  to some  network  configuration  error. However,  because  proper  TTL  scoping  sometimes  requires thresholds  in key places  and  these  thresholds  may not  always  exist,  an  application  program- mer  should be  careful not  to  create  a  dependency  that breaks  the  application  if the  network  is configured  in  some way  that  is  different  from  that  expected. One noteworthy side effect of using TTL scoping is that Internet Control Message Protocol (ICMP) TTL-expired messages  need  to  be  suppressed  for multicast. While TTLs  reaching  zero is  an  error  condition  for  unicast  packets,  it  is  not  for  multicast.  This  is  not  something  most programmers need  to worry about, but  it does have interesting implications for how a multicast version  of  traceroute  should work.