Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4712

Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU)

Pages: 48
Proposed Standard
Updated by:  8996
Part 1 of 2 – Pages 1 to 22
None   None   Next

Top   ToC   RFC4712 - Page 1
Network Working Group                                        A. Siddiqui
Request for Comments: 4712                                  D. Romascanu
Category: Standards Track                                          Avaya
                                                           E. Golovinsky
                                                             Alert Logic
                                                               M. Rahman
                                     Samsung Information Systems America
                                                                  Y. Kim
                                                                Broadcom
                                                            October 2006


    Transport Mappings for Real-time Application Quality-of-Service
              Monitoring (RAQMON) Protocol Data Unit (PDU)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

This memo specifies two transport mappings of the Real-Time Application Quality-of-Service Monitoring (RAQMON) information model defined in RFC 4710 using TCP as a native transport and the Simple Network Management Protocol (SNMP) to carry the RAQMON information from a RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC).
Top   ToC   RFC4712 - Page 2

Table of Contents

1. Introduction ....................................................3 2. Transporting RAQMON Protocol Data Units .........................3 2.1. TCP as an RDS/RRC Network Transport Protocol ...............3 2.1.1. The RAQMON PDU ......................................5 2.1.2. The BASIC Part of the RAQMON Protocol Data Unit .....7 2.1.3. APP Part of the RAQMON Protocol Data Unit ..........14 2.1.4. Byte Order, Alignment, and Time Format of RAQMON PDUs ........................................15 2.2. Securing RAQMON Session ...................................15 2.2.1. Sequencing of the Start TLS Operation ..............18 2.2.2. Closing a TLS Connection ...........................21 2.3. SNMP Notifications as an RDS/RRC Network Transport Protocol ..................................................22 3. IANA Considerations ............................................38 4. Congestion-Safe RAQMON Operation ...............................38 5. Acknowledgements ...............................................39 6. Security Considerations ........................................39 6.1. Usage of TLS with RAQMON ..................................41 6.1.1. Confidentiality & Message Integrity ................41 6.1.2. TLS CipherSuites ...................................41 6.1.3. RAQMON Authorization State .........................42 7. References .....................................................43 7.1. Normative References ......................................43 7.2. Informative References ....................................44 Appendix A. Pseudocode ............................................46
Top   ToC   RFC4712 - Page 3

1. Introduction

The Real-Time Application QoS Monitoring (RAQMON) Framework, as outlined by [RFC4710], extends the Remote Monitoring family of protocols (RMON) by defining entities such as RAQMON Data Sources RDS) and RAQMON Report Collectors (RRC) to perform various application monitoring in real time. [RFC4710] defines the relevant metrics for RAQMON monitoring carried by the common protocol data unit (PDU) used between a RDS and RRC to report QoS statistics. This memo contains a syntactical description of the RAQMON PDU structure. The following sections of this memo contain detailed specifications for the usage of TCP and SNMP to carry RAQMON information. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2. Transporting RAQMON Protocol Data Units

The RAQMON Protocol Data Unit (PDU) utilizes a common data format understood by the RDS and the RRC. A RAQMON PDU does not transport application data but rather occupies the place of a payload specification at the application layer of the protocol stack. As part of the specification, this memo also specifies the usage of TCP and SNMP as underlying transport protocols to carry RAQMON PDUs between RDSs and RRCs. While two transport protocol choices have been provided as options to chose from for RDS implementers, RRCs MUST implement the TCP transport and MAY implement the SNMP transport.

2.1. TCP as an RDS/RRC Network Transport Protocol

A transport binding using TCP is included within the RAQMON specification to facilitate reporting from various types of embedded devices that run applications such as Voice over IP, Voice over Wi-Fi, Fax over IP, Video over IP, Instant Messaging (IM), E-mail, software download applications, e-business style transactions, web access from wired or wireless computing devices etc. For many of these devices, PDUs and a TCP-based transport fit the deployment needs. The RAQMON transport requirements for end-to-end congestion control and reliability are inherently built into TCP as a transport protocol [RFC793].
Top   ToC   RFC4712 - Page 4
   To use TCP to transport RAQMON PDUs, it is sufficient to send the
   PDUs as TCP data.  As each PDU carries its length, the receiver can
   determine the PDU boundaries.

   The following section details the RAQMON PDU specifications.  Though
   transmitted as one Protocol Data Unit, a RAQMON PDU is functionally
   divided into two different parts: the BASIC part and application
   extensions required for vendor-specific extension [RFC4710].  Both
   functional parts follow a field carrying a SMI Network Management
   Private Enterprise code currently maintained by IANA
   http://www.iana.org/assignments/enterprise-numbers, which is used to
   identify the organization that defined the information carried in the
   PDU.

   A RAQMON PDU in the current version is marked as PDU Type (PDT) = 1.
   The parameters carried by RAQMON PDUs are shown in Figure 1 and are
   defined in section 5 of [RFC4710].

   Vendors MUST use the BASIC part of the PDU to report parameters pre-
   listed here in the specification for interoperability, as opposed to
   using the application-specific portion.  Vendors MAY also use
   application-specific extensions to convey application-, vendor-, or
   device-specific parameters not included in the BASIC part of the
   specification and explicitly publish such data externally to attain
   extended interoperability.
Top   ToC   RFC4712 - Page 5

2.1.1. The RAQMON PDU

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PDT = 1 |B| T |P|S|R| RC | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SMI Enterprise Code = 0 |Report Type = 0| RC_N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |flag +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Source Address {DA} | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver's Address (RA) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP Timestamp, most significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP Timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Application Name (AN) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Data Source Name (DN) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Receiver's Name (RN) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Session State ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Round-Trip End-to-End Network Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | One-Way End-to-End Network Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative Packet Loss | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative Application Packet Discard | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total # Application Packets sent |
Top   ToC   RFC4712 - Page 6
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Total # Application Packets received              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Total # Application Octets sent                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Total # Application Octets received               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Data Source Device Port Used  |  Receiver Device Port Used    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    S_Layer2   |   S_Layer3    |   S_Layer2    |   S_Layer3    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Source Payload |Receiver       | CPU           | Memory        |
   |Type           |Payload Type   | Utilization   | Utilization   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Session Setup Delay        |     Application Delay         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IP Packet Delay Variation     |   Inter arrival Jitter        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Packet Discrd |  Packet loss  |         Padding               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SMI Enterprise Code = "xxx"                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Report Type = "yyy"       | Length of Application Part    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               application/vendor specific extension           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            ...............                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            ...............                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            ...............                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SMI Enterprise Code = "abc"                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Report Type = "zzz"       | Length of Application Part    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               application/vendor specific extension           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            ...............                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1: RAQMON Protocol Data Unit
Top   ToC   RFC4712 - Page 7

2.1.2. The BASIC Part of the RAQMON Protocol Data Unit

A RAQMON PDU must contain the following BASIC part fields at all times: PDU type (PDT): 5 bits - This indicates the type of RAQMON PDU being sent. PDT = 1 is used for the current RAQMON PDU version defined in this document. basic (B): 1 bit - While set to 1, the basic flag indicates that the PDU has BASIC part of the RAQMON PDU. A value of zero is considered valid and indicates a RAQMON NULL PDU. trailer (T): 3 bits - Total number of Application-Specific Extensions that follow the BASIC part of RAQMON PDU. A value of zero is considered valid as many times as there is no application- specific information to add to the basic information. padding (P): 1 bit - If the padding bit is set, the BASIC part of the RAQMON PDU contains some additional padding octets at the end of the BASIC part of the PDU that are not part of the monitoring information. Padding may be needed in some cases, as reporting is based on the intent of a RDS to report certain parameters. Also, some parameters may be reported only once at the beginning of the reporting session, e.g., Data Source Name, Receiver Name, payload type, etc. Actual padding at the end of the BASIC part of the PDU is 0, 8, 16, or 24 bits to make the length of the BASIC part of the PDU a multiple of 32 bits Source IP version Flag (S): 1 bit - While set to 1, the source IP version flag indicates that the Source IP address contained in the PDU is an IPv6 address. Receiver IP version Flag (R): 1 bit - While set to 1, the receiver IP version flag indicates that the receiver IP address contained in the PDU is an IPv6 address. record count (RC): 4 bits - Total number of application records contained in the BASIC part of the PDU. A value of zero is considered valid but useless, with the exception of the case of a NULL PDU indicating the end of a RDS reporting session. length: 16 bits (unsigned integer) - The length of the BASIC part of the RAQMON PDU in units of 32-bit words minus one; this count includes the header and any padding.
Top   ToC   RFC4712 - Page 8
   DSRC: 32 bits - Data Source identifier represents a unique RAQMON
      reporting session descriptor that points to a specific reporting
      session between RDS and RRC.  Uniqueness of DSRC is valid only
      within a reporting session.  DSRC values should be randomly
      generated using vendor-chosen algorithms for each communication
      session.  It is not sufficient to obtain a DSRC simply by calling
      random() without carefully initializing the state.  One could use
      an algorithm like the one defined in Appendix A.6 in [RFC3550] to
      create a DSRC.  Depending on the choice of algorithm, there is a
      finite probability that two DSRCs from two different RDSs may be
      the same.  To further reduce the probability that two RDSs pick
      the same DSRC for two different reporting sessions, it is
      recommended that an RRC use parameters like Data Source Address
      (DA), Data Source Name (DN), and layer 2 Media Access Control
      (MAC) Address in the PDU in conjunction with a DSRC value.  It is
      not mandatory for RDSs to send parameters like Data Source Address
      (DA), Data Source Name (DN), and MAC Address in every PDU sent to
      RRC, but occasionally sending these parameters will reduce the
      probability of DSRC collision drastically.  However, this will
      cause an additional overhead per PDU.

      A value of zero for basic (B) bit and trailer (T) bits constitutes
      a RAQMON NULL PDU (i.e., nothing to report).  RDSs MUST send a
      RAQMON NULL PDU to RRC to indicate the end of the RDS reporting
      session.  A NULL PDU ends with the DSRC field.

   SMI Enterprise Code: 16 bits.  A value of SMI Enterprise Code = 0 is
      used to indicate the RMON-WG-compliant BASIC part of the RAQMON
      PDU format.

   Report Type: 8 bits - These bits are reserved by the IETF RMON
      Working Group.  A value of 0 within SMI Enterprise Code = 0 is
      used for the version of the PDU defined by this document.

      The BASIC part of each RAQMON PDU consists of Record Count Number
      (RC_N) and RAQMON Parameter Presence Flags (RPPF) to indicate the
      presence of appropriate RAQMON parameters within a record, as
      defined in Table 1.

   RC_N: 8 bits - The Record Count number indicates a sub-session within
      a communication session.  A value of zero is a valid record
      number.  The maximum number of records that can be described in
      one RAQMON Packet is 256.

   RAQMON Parameter Presence Flags (RPPF): 32 bits

      Each of these flags, while set, represents that this RAQMON PDU
      contains corresponding parameters as specified in Table 1.
Top   ToC   RFC4712 - Page 9
   +----------------+--------------------------------------------------+
   |  Bit Sequence  |    Presence/Absence of corresponding Parameter   |
   |     Number     |              within this RAQMON PDU              |
   +----------------+--------------------------------------------------+
   |        0       |             Data Source Address (DA)             |
   |                |                                                  |
   |        1       |               Receiver Address (RA)              |
   |                |                                                  |
   |        2       |                   NTP Timestamp                  |
   |                |                                                  |
   |        3       |                 Application Name                 |
   |                |                                                  |
   |        4       |               Data Source Name (DN)              |
   |                |                                                  |
   |        5       |                Receiver Name (RN)                |
   |                |                                                  |
   |        6       |               Session Setup Status               |
   |                |                                                  |
   |        7       |                 Session Duration                 |
   |                |                                                  |
   |        8       |       Round-Trip End-to-End Net Delay (RTT)      |
   |                |                                                  |
   |        9       |      One-Way End-to-End Network Delay (OWD)      |
   |                |                                                  |
   |       10       |              Cumulative Packets Loss             |
   |                |                                                  |
   |       11       |            Cumulative Packets Discards           |
   |                |                                                  |
   |       12       |         Total number of App Packets sent         |
   |                |                                                  |
   |       13       |       Total number of App Packets received       |
   |                |                                                  |
   |       14       |          Total number of App Octets sent         |
   |                |                                                  |
   |       15       |        Total number of App Octets received       |
   |                |                                                  |
   |       16       |           Data Source Device Port Used           |
   |                |                                                  |
   |       17       |             Receiver Device Port Used            |
   |                |                                                  |
   |       18       |              Source Layer 2 Priority             |
   |                |                                                  |
   |       19       |              Source Layer 3 Priority             |
   |                |                                                  |
   |       20       |           Destination Layer 2 Priority           |
   |                |                                                  |
   |       21       |           Destination Layer 3 Priority           |
   |                |                                                  |
Top   ToC   RFC4712 - Page 10
   |       22       |                Source Payload Type               |
   |                |                                                  |
   |       23       |               Receiver Payload Type              |
   |                |                                                  |
   |       24       |                  CPU Utilization                 |
   |                |                                                  |
   |       25       |                Memory Utilization                |
   |                |                                                  |
   |       26       |                Session Setup Delay               |
   |                |                                                  |
   |       27       |                 Application Delay                |
   |                |                                                  |
   |       28       |             IP Packet Delay Variation            |
   |                |                                                  |
   |       29       |               Inter arrival Jitter               |
   |                |                                                  |
   |       30       |           Packet Discard (in fraction)           |
   |                |                                                  |
   |       31       |             Packet Loss (in fraction)            |
   +----------------+--------------------------------------------------+

             Table 1: RAQMON Parameters and Corresponding RPPF

   Data Source Address (DA): 32 bits or 160 bits in binary
      representation - This parameter is defined in section 5.1 of
      [RFC4710].  IPv6 addresses are incorporated in Data Source Address
      by setting the source IP version flag (S bit) of the RAQMON PDU
      header to 1.

   Receiver Address (RA): 32 bits or 160 bits - This parameter is
      defined in section 5.2 of [RFC4710].  It follows the exact same
      syntax as Data Source Address but is used to indicate a Receiver
      Address.  IPv6 addresses are incorporated in Receiver Address by
      setting the receiver IP version flag (R bit) of the RAQMON PDU
      header to 1.

   Session Setup Date/Time (NTP timestamp): 64 bits - This parameter is
      defined in section 5.7 of [RFC4710] and represented using the
      timestamp format of the Network Time Protocol (NTP), which is in
      seconds [RFC1305].  The full resolution NTP timestamp is a 64-bit
      unsigned fixed-point number with the integer part in the first 32
      bits and the fractional part in the last 32 bits.

   Application Name: This parameter is defined in section 5.32 of
      [RFC4710].  The Application Name field starts with an 8-bit octet
      count describing the length of the text followed by the text
      itself using UTF-8 encoding.  Application Name field is a multiple
      of 32 bits, and padding will be used if necessary.
Top   ToC   RFC4712 - Page 11
      A Data Source that does not support NTP SHOULD set the appropriate
      RAQMON flag to 0 to avoid wasting 64 bits in the PDU.  Since the
      NTP time stamp is intended to provide the setup Date/Time of a
      session, it is RECOMMENDED that the NTP Timestamp be used only in
      the first RAQMON PDU after sub-session RC_N setup is completed, in
      order to use network resources efficiently.

   Data Source Name (DN): Defined in section 5.3 of [RFC4710].  The Data
      Source Name field starts with an 8-bit octet count describing the
      length of the text followed by the text itself.  Padding is used
      to ensure that the length and text encoding occupy a multiple of
      32 bits in the DN field of the PDU.  The text MUST NOT be longer
      than 255 octets.  The text is encoded according to the UTF-8
      encoding specified in [RFC3629].  Applications SHOULD instruct
      RDSs to send out the Data Source Name infrequently to ensure
      efficient usage of network resources as this parameter is expected
      to remain constant for the duration of the reporting session.

   Receiver Name (RN): This metric is defined in section 5.4 of
      [RFC4710].  Like Data Source Name, the Receiver Name field starts
      with an 8-bit octet count describing the length of the text,
      followed by the text itself.  The Receiver Name, including the
      length field encoding, is a multiple of 32 bits and follows the
      same padding rules as applied to the Data Source Name.  Since the
      Receiver Name is expected to remain constant during the entire
      reporting session, this information SHOULD be sent out
      occasionally over random time intervals to maximize success of
      reaching a RRC and also conserve network bandwidth.

   Session Setup Status: The Session (sub-session) Setup Status is
      defined in section 5.10 of [RFC4710].  This field starts with an
      8-bit length field followed by the text itself.  Session Setup
      Status is a multiple of 32 bits.

   Session Duration: 32 bits - The Session (sub-session) Duration metric
      is defined in section 5.9 of [RFC4710].  Session Duration is an
      unsigned integer expressed in seconds.

   Round-Trip End-to-End Network Delay: 32 bits - The Round-Trip End-
      to-End Network Delay is defined in section 5.11 of [RFC4710].
      This field represents the Round-Trip End-to-End Delay of sub-
      session RC_N, which is an unsigned integer expressed in
      milliseconds.

   One-Way End-to-End Network Delay: 32 bits - The One-Way End-to-End
      Network Delay is defined in section 5.12 of [RFC4710].  This field
      represents the One-Way End-to-End Delay of sub-session RC_N, which
      is an unsigned integer expressed in milliseconds.
Top   ToC   RFC4712 - Page 12
   Cumulative Application Packet Loss: 32 bits - This parameter is
      defined in section 5.20 of [RFC4710] as an unsigned integer,
      representing the total number of packets from sub-session RC_N
      that have been lost while this RAQMON PDU was generated.

   Cumulative Application Packet Discards: 32 bits - This parameter is
      defined in section 5.22 of [RFC4710] as an unsigned integer
      representing the total number of packets from sub-session RC_N
      that have been discarded while this RAQMON PDU was generated.

   Total number of Application Packets sent: 32 bits - This parameter is
      defined in section 5.17 of [RFC4710] as an unsigned integer,
      representing the total number of packets transmitted within sub-
      session RC_N by the sender.

   Total number of Application Packets received: 32 bits - This
      parameter is defined in section 5.16 of [RFC4710] and is
      represented as an unsigned integer representing the total number
      of packets transmitted within sub-session RC_N by the receiver.

   Total number of Application Octets sent: 32 bits - This parameter is
      defined in section 5.19 of [RFC4710] as an unsigned integer,
      representing the total number of payload octets (i.e., not
      including header or padding) transmitted in packets by the sender
      within sub-session RC_N.

   Total number of Application Octets received: 32 bits - This parameter
      is defined in section 5.18 of [RFC4710] as an unsigned integer
      representing the total number of payload octets (i.e., not
      including header or padding) transmitted in packets by the
      receiver within sub-session RC_N.

   Data Source Device Port Used: 16 bits - This parameter is defined in
      section 5.5 of [RFC4710] and describes the port number used by the
      Data Source as used by the application in RC_N session while this
      RAQMON PDU was generated.

   Receiver Device Port Used: 16 bits - This parameter is defined in
      section 5.6 of [RFC4710] and describes the receiver port used by
      the application to communicate to the receiver.  It follows same
      syntax as Source Device Port Used.

   S_Layer2: 8 bits - This parameter, defined in section 5.26 of
      [RFC4710], is associated to the source's IEEE 802.1D [IEEE802.1D]
      priority tagging of traffic in the communication sub-session RC_N.
      Since IEEE 802.1 priority tags are 3 bits long, the first 3 bits
      of this parameter represent the IEEE 802.1 tag value, and the last
      5 bits are padded to 0.
Top   ToC   RFC4712 - Page 13
   S_Layer3: 8 bits - This parameter, defined in section 5.27 of
      [RFC4710], represents the layer 3 QoS marking used to send packets
      to the receiver by this data source during sub-session RC_N.

   D_Layer2: 8 bits - This parameter, defined in section 5.28 of
      [RFC4710], represents layer 2 IEEE 802.1D priority tags used by
      the receiver to send packets to the data source during sub-session
      RC_N session if the Data Source can learn such information.  Since
      IEEE 802.1 priority tags are 3 bits long, the first 3 bits of this
      parameter represent the IEEE 802.1 priority tag value, and the
      last 5 bits are padded to 0.

   D_Layer3: 8 bits - This parameter is defined in section 5.29 of
      [RFC4710] and represents the layer 3 QoS marking used by the
      receiver to send packets to the data source during sub-session
      RC_N, if the Data Source can learn such information.

   Source Payload Type: 8 bits - This parameter is defined in section
      5.24 of [RFC4710] and specifies the payload type of the data
      source of the communication sub-session RC_N as defined in
      [RFC3551].

   Receiver Payload Type: 8 bits - This parameter is defined in section
      5.25 of [RFC4710] and specifies the receiver payload type of the
      communication sub-session RC_N as defined in [RFC3551].

   CPU Utilization: 8 bits - This parameter, defined in section 5.30 of
      [RFC4710], represents the percentage of CPU used during session
      RC_N from the last report until the time this RAQMON PDU was
      generated.  The CPU Utilization is expressed in percents in the
      range 0 to 100.  The value should indicate not only CPU
      utilization associated to a session RC_N but also actual CPU
      Utilization, to indicate a snapshot of the CPU utilization of the
      host running the RDS while session RC_N in progress.

   Memory Utilization: 8 bits - This parameter, defined in section 5.31
      of [RFC4710], represents the percentage of total memory used
      during session RC_N up until the time this RAQMON PDU was
      generated.  The memory utilization is expressed in percents 0 to
      100.  The Memory Utilization value should indicate not only the
      memory utilization associated to a session RC_N but the total
      memory utilization, to indicate a snapshot of end-device memory
      utilization while session RC_N is in progress.

   Session Setup Delay: 16 bits - The Session (sub-session) Setup Delay
      metric is defined in section 5.8 of [RFC4710] and expressed in
      milliseconds.
Top   ToC   RFC4712 - Page 14
   Application Delay: 16 bits - The Application Delay is defined in
      section 5.13 of [RFC4710] and is represented as an unsigned
      integer expressed in milliseconds.

   IP Packet Delay Variation: 16 bits - The IP Packet Delay Variation is
      defined in section 5.15 of [RFC4710] and is represented as an
      unsigned integer expressed in milliseconds.

   Inter-Arrival Jitter: 16 bits - The Inter-Arrival Jitter is defined
      in section 5.14 of [RFC4710] and is represented as an unsigned
      integer expressed in milliseconds.

   Packet Discard in Fraction: 8 bits - This parameter is defined in
      section 5.23 of [RFC4710] and is expressed as a fixed-point number
      with the binary point at the left edge of the field.  (That is
      equivalent to taking the integer part after multiplying the
      discard fraction by 256.)  This metric is defined to be the number
      of packets discarded, divided by the total number of packets.

   Packet Loss in Fraction: 8 bits - This parameter is defined in
      section 5.21 of [RFC4710] and is expressed as a fixed-point
      number, with the binary point at the left edge of the field.  The
      metric is defined to be the number of packets lost divided by the
      number of packets expected.  The value is calculated by dividing
      the total number of packets lost (after the effects of applying
      any error protection, such as Forward Error Correction (FEC)) by
      the total number of packets expected, multiplying the result of
      the division by 256, limiting the maximum value to 255 (to avoid
      overflow), and taking the integer part.

   padding: 0, 8, 16, or 24 bits - If the padding bit (P) is set, then
      this field may be present.  The actual padding at the end of the
      BASIC part of the PDU is 0, 8, 16, or 24 bits to make the length
      of the BASIC part of the PDU a multiple of 32 bits.

2.1.3. APP Part of the RAQMON Protocol Data Unit

The APP part of the RAQMON PDU is intended to accommodate extensions for new applications in a modular manner and without requiring a PDU type value registration. Vendors may design and publish application-specific extensions. Any RAQMON-compliant RRC MUST be able to recognize vendors' SMI Enterprise Codes and MUST recognize the presence of application- specific extensions identified by using Report Type fields. As represented in Figure 1, the Report Type and Application Length
Top   ToC   RFC4712 - Page 15
   fields are always located at a fixed offset relative to the start of
   the extension fields.  There is no need for the RRC to understand the
   semantics of the enterprise-specific parts of the PDU.

   SMI Enterprise Code: 32 bits - Vendors and application developers
      should fill in appropriate SMI Enterprise IDs available at
      http://www.iana.org/assignments/enterprise-numbers.  A non-zero
      SMI Enterprise Code indicates a vendor- or application-specific
      extension.

      RAQMON PDUs are capable of carrying multiple Application Parts
      within a PDU.

   Report Type: 16 bits - Vendors and application developers should fill
      in the appropriate report type within a specified SMI Enterprise
      Code.  It is RECOMMENDED that vendors publish application-specific
      extensions and maintain such report types for better
      interoperability.

   Length of the Application Part: 16 bits (unsigned integer) - The
      length of the Application Part of the RAQMON PDU in 32-bit words
      minus one, which includes the header of the Application Part.

   Application-dependent data: variable length - Application/
      vendor-dependent data is defined by the application developers.
      It is interpreted by the vendor-specific application and not by
      the RRC itself.  Its length must be a multiple of 32 bits and will
      be padded if necessary.

2.1.4. Byte Order, Alignment, and Time Format of RAQMON PDUs

All integer fields are carried in network byte order, that is, most significant byte (octet) first. This byte order is commonly known as big-endian. The transmission order is described in detail in [RFC791]. Unless otherwise noted, numeric constants are in decimal (base 10). All header data is aligned to its natural length, i.e., 16-bit fields are aligned on even offsets, 32-bit fields are aligned at offsets divisible by four, etc. Octets designated as padding have the value zero.

2.2. Securing RAQMON Session

The RAQMON session, initiated over TCP transport, between an RDS and an RRC carries monitoring information from an RDS client to the RRC, the collector. The RRC distinguishes between clients based on various identifiers used by the RDS to identify itself to the RRC
Top   ToC   RFC4712 - Page 16
   (Data Source Address and Data Source Name) and the RRC (Receiver's
   Address and Receiver's Name).

   In order to ensure integrity of the claimed identities of RDS and RRC
   to each other, authentication services are required.

   Subsequently, where protection from unauthorized modification and
   unauthorized disclosure of RAQMON data in transit from RDS to RRC is
   needed, data confidentiality and message integrity services will be
   required.  In order to prevent monitoring-misinformation due to
   session-recording and replay by unauthorized sources, replay
   protection services may be required.

   TLS provides, at the transport layer, the required authentication
   services through the handshake protocol and subsequent data
   confidentiality, message integrity, and replay protection of the
   application protocol using a ciphersuite negotiated during
   authentication.

   The RDS client authenticates the RRC in session.  The RRC optionally
   authenticates the RDS.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PDT = 1  |B|  T  |P|S|R|  RC   |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            DSRC                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  SMI Enterprise Code = 0      |Report Type =  |     RC_N      |
   |                               |        TLS_REQ|               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 2: RAQMON StartTLS Request - TLS_REQ

   The protection of a RAQMON session starts with the RDS client's
   StartTLS request upon successful establishment of the TCP session.
   The RDS sends the StartTLS request by transmitting the TLS_REQ PDU as
   in Figure 2.  This PDU is distinguished by TLS_REQ Report Type.

   Following this request, the client MUST NOT send any PDUs on this
   connection until it receives a StartTLS response.

   Other fields of the PDU are as specified in Figure 1.

   The flags field do not carry any significance and exist for
   compatibility with the generic RAQMON PDU.  The flags field in this
   version MUST be ignored.
Top   ToC   RFC4712 - Page 17
   When a StartTLS request is made, the target server, RRC, MUST return
   a RAQMON PDU containing a StartTLS response, TLS_RESP.  A RAQMON
   TLS_RESP is defined as follows:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PDT = 1  |B|  T  |P|S|R|  RC   |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            DSRC                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  SMI Enterprise Code = 0      |Report Type =  |     Result    |
   |                               |       TLS_RESP|               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 3: RAQMON StartTLS Response - TLS_RESP

   The RRC responds to the StartTLS request by transmitting the TLS_RESP
   PDU as in Figure 3.  This PDU is distinguished by TLS_RESP Report
   Type.

   The Result field is an octet containing the result of the request.
   This field can carry one of the following values:

   +-------+------------------+----------------------------------------+
   | Value |     Mnemonic     |                 Result                 |
   +-------+------------------+----------------------------------------+
   |   0   |        OK        |   Success.  The server is willing and  |
   |       |                  |         able to negotiate TLS.         |
   |   1   |      OP_ERR      |   Sequencing Error (e.g., TLS already  |
   |       |                  |              established).             |
   |   2   |     PROTO_ERR    |   TLS not supported or incorrect PDU   |
   |       |                  |                 format.                |
   |   3   |      UNAVAIL     |    TLS service problem or RRC server   |
   |       |                  |               going down.              |
   |   4   |     CONF_REQD    |    Confidentiality Service Required.   |
   |       |                  |                                        |
   |   5   | STRONG_AUTH_REQD |      Strong Authentication Service     |
   |       |                  |                Required.               |
   |   6   |     REFERRAL     |   Referral to a RRC Server supporting  |
   |       |                  |                  TLS.                  |
   +-------+------------------+----------------------------------------+

                                  Table 2

   Other fields of the PDU are as specified in Figure 1.
Top   ToC   RFC4712 - Page 18
   The server MUST return OP_ERR if the client violates any of the
   StartTLS operation sequencing requirements described in the section
   below.

   If the server does not support TLS (whether by design or by current
   configuration), it MUST set the resultCode to PROTO_ERR or to
   REFERRAL.  The server MUST include an actual referral value in the
   RAQMON REFER field if it returns a resultCode of referral.  The
   client's current session is unaffected if the server does not support
   TLS.  The client MAY proceed with RAQMON session, or it MAY close the
   connection.

   The server MUST return UNAVAIL if it supports TLS but cannot
   establish a TLS connection for some reason, e.g., if the certificate
   server not responding, if it cannot contact its TLS implementation,
   or if the server is in process of shutting down.  The client MAY
   retry the StartTLS operation, MAY proceed with RAQMON session, or MAY
   close the connection.

2.2.1. Sequencing of the Start TLS Operation

This section describes the overall procedures clients and servers MUST follow for TLS establishment. These procedures take into consideration various aspects of the overall security of the RAQMON connection including discovery of resulting security level.
2.2.1.1. Requesting to Start TLS on a RAQMON Association
The client MAY send the StartTLS request at any time after establishing an RAQMON (TCP) connection, except that in the following cases the client MUST NOT send a StartTLS request: o if TLS is currently established on the connection, or o if RAQMON traffic is in progress on the connection. The result of violating any of these requirements is a Result of OP_ERR, as described above in Table 2. If the client did not establish a TLS connection before sending any other requests, and the server requires the client to establish a TLS connection before performing a particular request, the server MUST reject that request with a CONF_REQD or STRONG_AUTH_REQD result. The client MAY send a Start TLS extended request, or it MAY choose to close the connection.
Top   ToC   RFC4712 - Page 19
2.2.1.2. Starting TLS
The server will return an extended response with the resultCode of success if it is willing and able to negotiate TLS. It will return other resultCodes, documented above, if it is unable. In the successful case, the client, which has ceased to transfer RAQMON PDUs on the connection, MUST either begin a TLS negotiation or close the connection. The client will send PDUs in the TLS Record Protocol directly over the underlying transport connection to the server to initiate TLS negotiation [TLS].
2.2.1.3. TLS Version Negotiation
Negotiating the version of TLS or SSL to be used is a part of the TLS Handshake Protocol, as documented in [TLS]. The reader is referred to that document for details.
2.2.1.4. Discovery of Resultant Security Level
After a TLS connection is established on a RAQMON connection, both parties MUST individually decide whether or not to continue based on the security assurance level achieved. Ascertaining the TLS connection's assurance level is implementation dependent and is accomplished by communicating with one's respective local TLS implementation. If the client or server decides that the level of authentication or confidentiality is not high enough for it to continue, it SHOULD gracefully close the TLS connection immediately after the TLS negotiation has completed Section 2.2.2.1. The client MAY attempt to Start TLS again, MAY disconnect, or MAY proceed to send RAQMON session data, if RRC policy permits.
2.2.1.5. Server Identity Check
The client MUST check its understanding of the server's hostname against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks. Matching is performed according to these rules: o The client MUST use the server dnsNAME in the subjectAltName field to validate the server certificate presented. The server dnsName MUST be part of subjectAltName of the server. o Matching is case-insensitive.
Top   ToC   RFC4712 - Page 20
   o  The "*" wildcard character is allowed.  If present, it applies
      only to the left-most name component.

      For example, *.example.com would match a.example.com,
      b.example.com, etc., but not example.com.  If more than one
      identity of a given type is present in the certificate (e.g., more
      than one dNSName name), a match in any one of the set is
      considered acceptable.

   If the hostname does not match the dNSName-based identity in the
   certificate per the above check, automated clients SHOULD close the
   connection, returning and/or logging an error indicating that the
   server's identity is suspect.

   Beyond the server identity checks described in this section, clients
   SHOULD be prepared to do further checking to ensure that the server
   is authorized to provide the service it is observed to provide.  The
   client MAY need to make use of local policy information.

   We also refer readers to similar guidelines as applied for LDAP over
   TLS [RFC4513].

2.2.1.6. Client Identity Check
Anonymous TLS authentication helps establish a TLS RAQMON session that offers o server-authentication in course of TLS establishment and o confidentiality and replay protection of RAQMON traffic, but o no protection against man-in-the-middle attacks during session establishment and o no protection from spoofing attacks by unauthorized clients. The server MUST authenticate the RDS client when deployment is susceptible to the above threats. This is done by requiring client authentication during TLS session establishment. In the TLS negotiation, the server MUST request a certificate. The client will provide its certificate to the server and MUST perform a private-key-based encryption, proving it has the private key associated with the certificate. As deployments will require protection of sensitive data in transit, the client and server MUST negotiate a ciphersuite that contains a bulk encryption algorithm of appropriate strength.
Top   ToC   RFC4712 - Page 21
   The server MUST verify that the client's certificate is valid.  The
   server will normally check that the certificate is issued by a known
   CA, and that none of the certificates on the client's certificate
   chain are invalid or revoked.  There are several procedures by which
   the server can perform these checks.

   The server validates the certificate by the Distinguished Name of the
   RDS client entity in the Subject field of the certificate.

   A corresponding set of guidelines will apply to use of TLS-PSK modes
   [TLS-PSK] using pre-shared keys instead of client certificates.

2.2.1.7. Refresh of Server Capabilities Information
The client MUST refresh any cached server capabilities information upon TLS session establishment, such as prior RRC state related to a previous RAQMON session based on another DSRC. This is necessary to protect against active-intermediary attacks, which may have altered any server capabilities information retrieved prior to TLS establishment. The server MAY advertise different capabilities after TLS establishment.

2.2.2. Closing a TLS Connection

2.2.2.1. Graceful Closure
Either the client or server MAY terminate the TLS connection on an RAQMON session by sending a TLS closure alert. This will leave the RAQMON connection intact. Before closing a TLS connection, the client MUST wait for any outstanding RAQMON transmissions to complete. This happens naturally when the RAQMON client is single-threaded and synchronous. After the initiator of a close has sent a closure alert, it MUST discard any TLS messages until it has received an alert from the other party. It will cease to send TLS Record Protocol PDUs and, following the receipt of the alert, MAY send and receive RAQMON PDUs. The other party, if it receives a closure alert, MUST immediately transmit a TLS closure alert. It will subsequently cease to send TLS Record Protocol PDUs and MAY send and receive RAQMON PDUs.
Top   ToC   RFC4712 - Page 22
2.2.2.2. Abrupt Closure
Either the client or server MAY abruptly close the entire RAQMON session and any TLS connection established on it by dropping the underlying TCP connection. It MAY be possible for RRC to send RDS a disconnection notification, which allows the client to know that the disconnection is not due to network failure. However, this message is not defined in this version.


(page 22 continued on part 2)

Next Section