NAME

  tst_send_tclass_udp - Specifying the traffic class as ancillary data


PURPOSE

  To check that the traffic class can be specified as ancillary data.


SYNOPSIS

  ./tst_send_tclass_udp [-tooloption ...]
    -tooloption : v6api tool option


TEST PROCEDURE

  1. Create an IPv6/UDP socket
  2. Bind the socket to address
  3. Specifying the outgoing traffic class -1 as ancillary data and
     send the message
  4. Check A: Message can be send used kernel default hop limit
  5. Specifying the outgoing traffic class 0 as ancillary data and
     send the message
  6. Check B: Message can be send
  7. Specifying the outgoing traffic class 64 as ancillary data and
     send the message
  8. Check C: Message can be send
  9. Specifying the outgoing traffic class 255 as ancillary data and
     send the message
  10.Check D: Message can be send
  11.Specifying the outgoing traffic class 256 as ancillary data and
     send the message
  12.Check E: Message can not be send, return EINVAL error
  13.Specifying the outgoing traffic class -2 as ancillary data and
     send the message
  14.Check F: Message can not be send, return EINVAL error


NOTE

  None


REFERENCE

  RFC 3493
  6.5.  Specifying/Receiving the Traffic Class value
    The outgoing traffic class is normally set to 0.  Specifying the
    traffic class as ancillary data lets the application override either
    the kernel's default or a previously specified value, for either a
    unicast destination or a multicast destination, for a single output
    operation.  Returning the received traffic class is useful for
    programs such as a diffserv debugging tool and for user level ECN
    (explicit congestion notification) implementation.
    The received traffic class is returned as ancillary data by recvmsg()
    only if the application has enabled the IPV6_RECVTCLASS socket
    option:
      int  on = 1;
      setsockopt(fd, IPPROTO_IPV6, IPV6_RECVTCLASS, &on, sizeof(on));
    In the cmsghdr structure containing this ancillary data, the
    cmsg_level member will be IPPROTO_IPV6, the cmsg_type member will be
    IPV6_TCLASS, and the first byte of cmsg_data[] will be the first byte
    of the integer traffic class.
    To specify the outgoing traffic class value, just specify the control
    information as ancillary data for sendmsg() or using setsockopt().
    Just like the hop limit value, the interpretation of the integer
    traffic class value is
      x < -1:        return an error of EINVAL
      x == -1:       use kernel default
      0 <= x <= 255: use x
      x >= 256:      return an error of EINVAL
    In order to clear a sticky IPV6_TCLASS option the application can
    specify -1 as the value.
    There are cases where the kernel needs to control the traffic class
    value and conflicts with the user-specified value on the outgoing
    traffic.  An example is an implementation of ECN in the kernel,
    setting 2 bits of the traffic class value.  In such cases, the kernel
    should override the user-specified value.  On the incoming traffic,
    the kernel may mask some of the bits in the traffic class field.