One document matched: draft-siddiqui-rmonmib-raqmon-tcpsip-00.txt
RMONMIB WG Anwar Siddiqui
Internet Draft Avaya Labs
Expires: January, 2005 Eugene Glovinsky
BMC Software
Mahfuzur Rahman
Panasonic
Bin Hu
Motorola
Yong Kim
Broadcom
July 1, 2004
Alternate transport bindings for Real-time Application Quality of
Service Monitoring (RAQMON) PDU
<draft-siddiqui-rmonmib-raqmon-tcpsip-00.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other intellectual property right (IPR) claims
of which he or she is aware have been or will be disclosed, and any
of which he or she becomes aware will be disclosed, in accordance
with Section 6 of RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or made obsolete by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
With the growth of the Internet and advancements in embedded
technologies, smart IP devices such as IP phones, Cell Phones, Video
desktop stations, Pagers, Instant Messaging Devices, PDAs, Networked
Appliances, Wireless Hand-held devices and various other computing
devices have become an integral part of our day-to-day operations.
Siddiqui, et al. Expires January, 2005 [Page 1]
Internet Draft tcpsip July 1, 2004
Enterprise as well as service providers have requirements to monitor
these end devices for various application level session quality.
[RAQMON-FRAMEWORK], [RAQMON PDU], and [RAQMON MIB] define
specifications to monitor end devices in real time. Even though SNMP
binding [RAQMON PDU] to transport Protocol Data Units (PDU) from
RAQMON Data Source (RDS) to RAQMON Report Collector (RRC) could be
sufficient for many deployment scenarios, an alternate transport
binding to carry RAQMON PDUs within RAQMON specification is also
required to facilitate real time reporting from these types of
embedded devices. This memo provides such different alternative
methods to carry RAQMON PDUs over other transport protocols and
discusses the options. A portion of this memo is taken out of
[RAQMON PDU] and has been gathered here to generate further
discussion.
Table of Contents
1. Introduction.................................................3
2. RAQMON PDU Transported Over TCP..............................4
2.1. Basic Part of RAQMON Protocol Data Unit....................7
2.2. APP Part of RAQMON Protocol Data Unit.....................14
2.3. Byte Order, Alignment, and Time Format of RAQMON PDUs.....15
2.4. Port Assignment...........................................15
3. Transporting RAQMON Protocol Data Units using SIP...........15
3.1. SIP Event Package Definition..............................17
3.1.1. Event Package Name.......................................17
3.1.2. SUBSCRIBE Bodies.........................................17
3.1.3. Subscription Duration....................................17
3.1.4. NOTIFY Bodies............................................17
3.1.5. Metric Definitions.......................................17
3.1.6. RAQMON Event Package Format Example......................18
3.1.7. An Event Flow Example Between RDS and RRC................20
4. Congestion Safe RAQMON Operation............................21
5. Normative References........................................21
6. Informative References......................................21
7. Contributions...............................................23
8. Appendix....................................................23
9. Security Considerations.....................................24
10. IANA Considerations.........................................24
11. Authors Addresses...........................................25
12. IPR Disclosure..............................................25
13. Full Copyright Statement....................................26
14. Acknowledgement:............................................26
Siddiqui, et al. Expires January, 2005 [Page 2]
Internet Draft tcpsip July 1, 2004
1. Introduction
The Real-Time Application QoS Monitoring (RAQMON) allows end devices
and applications to report QoS statistics in real-time. Many real-
time applications as well as non-real time applications managed
within the RMON family of specifications [RAQMON-FRAMEWORK] can
report application level QoS statistics in real-time over a SNMP
transport protocol. Other alternate transport binding is also
required to carry RAQMON PDUs from RDS to RRC within RAQMON
specification to facilitate real time reporting from these embedded
devices. This memo proposes such alternative methods.
The informational model defined in [RAQMON-FRAMEWORK] defines a
RAQMON Protocol Data Unit (PDU) which includes a common data format
understood by RDS and 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. This
memo covers definitions of syntactical PDU structure and use case
scenarios of transmission of such RAQMON PDUs over two specific
transport protocols namely TCP and SIP. Both transport bindings
complies with RAQMON specifications outlined in [RAQMON-FRAMEWORK],
[RAQMON-PDU], and [RAQMON-MIB]. UDP as a transport protocol has been
specifically removed as an option from the memo since it fails to
provide end-to-end congestion control. Various other transport
protocols such as DCCP, SCTP can also be used but were not
considered within the scope of this specification.
The RAQMON Framework [RAQMON-FRAMEWORK] provides the RAQMON
functional architecture, RAQMON entity definitions, and behavior of
various RAQMON entities and definition of various parameters carried
within the RAQMON PDU.
The RAQMON PDU [RAQMON-PDU] memo provides mapping of the RAQMON
informational modem over SNMP and use case scenarios of transmission
of such PDUs over Simple Network Management Protocol (SNMP).
The RAQMON MIB [RAQMON-MIB] memo describes the Management
Information Base (MIB) for use with the SNMP protocol in the
Internet community. The document proposes an extension to the Remote
Monitoring MIB [RFC2819] to accommodate RAQMON solutions.
Though transmitted as one Protocol Data Unit, a RAQMON PDU is
functionally divided into two different parts namely Basic Part and
Application extensions required for vendor specific extension. Both
functional parts trail SMI Network Management Private Enterprise
Codes and currently maintained by IANA
http://www.iana.org/assignments/enterprise-numbers.
Siddiqui, et al. Expires January, 2005 [Page 3]
Internet Draft tcpsip July 1, 2004
BASIC Part of RAQMON PDU: The basic part of the RAQMON PDU trails
the SMI Network Management Private Enterprise Code 0 - reserved by
convention for use by the IETF RMON Working Group. The RAQMON PDU
basic part offers an entry-type (a.k.a. "Name") from a pre-defined
list of QoS parameters defined in table 1 and allows applications to
fill in appropriate values for those parameters. Application
developers also have the flexibility to report only a sub-set of the
parameters listed in table 1 as discussed in later sections.
Application Part of RAQMON PDU: Application and vendor specific
extensibility of RAQMON PDU is provided by Application part of the
RAQMON PDU to convey application-, vendor-, device- specific
parameters for future use. Additional parameters can be defined by
the application developers within payload of the APP part of the PDU
as Type Length Value (TLV) tuples. Application part of the RAQMON
PDU trails behind the SMI Network Management Private Enterprise
Codes of the vendor found in
http://www.iana.org/assignments/enterprise-numbers. Such application
specific extensions should be maintained and published by the
application vendor. RAQMON PDUs are also capable of carrying
multiple Application Parts within a PDU that trails multiple SMI
Network Management Private Enterprise Codes of the vendor.
The following sections of this memo contain detailed RAQMON PDU
specifications and usage of TCP and SIP to carry a RAQMON PDU.
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. RAQMON PDU Transported Over TCP
RAQMON PDUs defined in this section gets transmitted from a RDS to
RRC over TCP. Choice of TCP as a transport protocol supports end-
to-end congestion control and reliability to RAQMON Framework. A
RAQMON PDU in the current version is marked as PDU Type (PDT) = 1.
Parameters carried by RAQMON PDUs as shown in figure 1 and their
usages are defined in sub section 5 of [RAQMON-FRAMEWORK]. These
parameters are defined and measured by reference to existing IETF,
ITU and other standards organizations' documents.
Vendors SHOULD use the Basic part of the PDU to report statistics
pre-listed here in the specification, which will ensure basic
interoperability between multiple vendors and application
developers. Vendors SHOULD also use application specific extension
to convey application-, vendor-, device- etc. specific parameters
not included in the Basic part of the specification and publish such
data externally to attain extended interoperability.
Siddiqui, et al. Expires January, 2005 [Page 4]
Internet Draft tcpsip July 1, 2004
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |PDT = 1|B| T |P|I| RC | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = 0 | Report Type = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RC_N | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| One Way End-to-End Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative Packet Loss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Packets sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Packets received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Octets sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Octets received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port Used | Receiver Port Used |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S_Layer2 | S_Layer3 | S_Layer2 | S_Layer3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Source Payload |Reciver Payload| CPU | Memory |
|Type | Type | Utilization | Utilization |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Setup Delay | Inter arrival Jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Siddiqui, et al. Expires January, 2005 [Page 5]
Internet Draft tcpsip July 1, 2004
| Padding | Packet loss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
version (V) : 2 bits - Identifies the version of RAQMON. The number
of this version is 1.
PDU type (PDT): 4 bits - This indicates the type of RAQMON PDU being
sent. PDT = 1 is used for current RAQMON PDU version.
basic (B): 1 bit - While set to 1, basic flag indicates that the PDU
has Basic part of the RAQMON PDU. A value of zero is considered to
be valid as it may constitute a RAQMON NULL PDU.
trailer (T) : 3 bits - Total number of Application Specific
Extension that trails the BASIC Part of RAQMON PDU. A value of zero
is considered to be valid as it may constitute a RAQMON NULL PDU.
padding (P): 1 bit - If the padding bit is set, BASIC Part of RAQMON
PDU contains some additional padding octets at the end of the Basic
Part of the PDU which are not part of the monitoring information as
padding may be needed by some applications as reporting is based on
the intent of 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, Pay Load type etc. Actual
padding at the end of the Basic part of the PDU, is either 0,8, 16
or 24 bits to make the basic part of the PDU multiple of 32 bits
long.
IP version (I): 1 bit - While set to 1, IP Version Flag indicates
that IP addresses contained in the PDU are IP version 6 compatible.
Siddiqui, et al. Expires January, 2005 [Page 6]
Internet Draft tcpsip July 1, 2004
record count (RC): 4 bits - Total number of records contained in the
Basic part of the PDU. A value of zero is considered to be valid but
useless.
length: 16 bits - The length of the Basic Part of the RAQMON PDU in
32-bit words minus one which includes the header and any padding.
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 [17] to create a DSRC. Depending
on the choice of algorithm, there is a finite probability that two
DSRCS from two different RDSs may be same. To further reduce the
probability that two RDSs pick the same DSRC for two different
reporting session, it is recommended that an RRC use parameters like
Data Source Address (DA), Data Source Name (DN), MAC Address in the
PDU in conjunction with a DSRC value. Though it is not mandatory for
RDSs to send parameters like Data Source Address (DA), Data Source
Name (DN), MAC Address in the every PDU sent to RRC, but sending
these parameters occasionally will reduce the probability of DSRC
collision drastically. However this will cause an additional
overhead per PDU.
A RAQMON PDU must contain V, PDT, B, T, P, I, RC, length and DSRC
fields at all times. A value of zero for basic (B) bit and trailer
(T) bits set constitutes a RAQMON NULL PDU (i.e. nothing to report).
RDSs MUST send a RAQMON NULL PDU to RRC to indicate end of RDS
reporting session. All other parameters listed in the PDU described
below are optionally used when RDSs have some information to send to
RRC.
2.1. Basic Part of RAQMON Protocol Data Unit
SMI Enterprise Code: 16 bits. A value of SMI Enterprise Code = 0 is
used to indicate RMON WG compliant Basic part of the RAQMON PDU
format. The basic Part of the RAQMON PDU must trail behind the SMI
Enterprise Code = 0 to ensure interoperability.
Siddiqui, et al. Expires January, 2005 [Page 7]
Internet Draft tcpsip July 1, 2004
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |PDT = 1|B| T |P|I| RC | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = 0 | Report Type = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RC_N | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - RAQMON Parameter Presence Flag in RAQMON PDU
Report Type: 16 bits - These bits are reserved by the IETF RMON Work
Group. A value of 0 within SMI Enterprise Code = 0 is used for this
version of the PDU.
Basic part of Each RAQMON PDU consists of Record Count Number (RC_N)
and RAQMON Parameter Presence Flags (RPPF) to indicate presence of
appropriate RAQMON parameters within a record as defined in table 1.
RC_N: 4 bits - Record Count number to which the information in this
record pertains. Record Count number indicates a sub-session within
a communication session. A value of zero is a valid record number.
Maximum number of records that can be described in one RAQMON Packet
is 16 (i.e. 0000 - 1111).
RAQMON Parameter Presence Flags (RPPF): 28 bits
Each of these flags while set represent that this RAQMON PDU
contains corresponding parameters as specified in table 1.
Sequence Number Presence/Absence of corresponding
Parameter within this RAQMON PDU
1 Data Source Address (DA)
2 Receiver Address (RA)
3 NTP Timestamp
4 Application Name
5 Data Source Name (DN)
6 Receiver Name (RN)
7 Session Setup Status
8 Session Duration
9 End-to-End Delay (RTT)
0 End-to-End Delay (OWD)
1 Cumulative Packet Loss
Siddiqui, et al. Expires January, 2005 [Page 8]
Internet Draft tcpsip July 1, 2004
2 Total number of Packets sent
3 Total number of Packets received
4 Total number of Octets sent
5 Total number of Octets received
6 Source Port Used
7 Receiver Port Used
8 S_Layer2
9 S_Layer3
0 D_Layer2
1 D_Layer3
2 Source Payload Type
3 Receiver Payload Type
4 CPU Utilization
5 Memory Utilization
6 Session Setup Delay
7 Inter arrival Jitter
8 Packet loss (in fraction)
Table 1: RAQMON Parameters and corresponding RPPF
Data Source Address (DA): 32 bits or 160 bits - This metrics is
defined in section 5.1 of [RAQMON-FRAMEWORK]. The standard [RFC
3291] octet string representation is used to represent end device's
numeric address on the interface used for the communication session.
The standard representation of an IP Version 4 address is "dotted
decimal", also known as dotted quad. 135.8.45.178 is an example of a
valid Data Source Address. IP version 6 addresses are incorporated
in Data Source Address by setting the IP version flag (I bit) of the
RAQMON PDU header to 1.
Receiver Address (RA): 32 bits or 160 bits - This metrics is defined
in section 5.2 of [RAQMON-FRAMEWORK]. Follows exact same syntax as
Data Source Address but used to indicate a Receiver's Address.
Data Source Name (DN): - This metrics is defined in section 5.3 of
[RAQMON-FRAMEWORK]. The Data Source Name field starts with an 8-bit
octet count describing the length of the text and the text itself.
Note that the text can be no longer than 255 octets. The text is
encoded according to the UTF-2 encoding specified in Annex F of ISO
standard 10646 [ISO10646],[UNICODE]. This encoding is also known as
UTF-8 or UTF-FSS. It is described in "File System Safe UCS
Transformation Format (FSS_UTF)", X/Open Preliminary Specification,
Document Number P316 and Unicode Technical Report #4. US-ASCII is a
Siddiqui, et al. Expires January, 2005 [Page 9]
Internet Draft tcpsip July 1, 2004
subset of this encoding and requires no additional encoding. The
presence of multi-octet encoding is indicated by setting the most
significant bit of a character to a value of one. Text is not null
terminated because some multi-octet encoding include null octets.
Data Source Name is terminated by one or more null octets, the first
of which is interpreted as to denote the end of the string and the
remainder as needed to pad until the next 32-bit boundary.
Applications should instruct a RDS to send out parameters not too
frequently 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 metrics is defined in section 5.4 of
[RAQMON-FRAMEWORK]. Like Data Source Name, the Receiver Name field
starts with an 8-bit octet count describing the length of the text
and the text itself. The Receiver Name is multiple of 32 bits.
Follows the same padding rules as applies to Data Source Name. As
Data Source Name and Receiver's Name are contiguous, i.e., items are
not individually padded to a 32-bit boundary. Since the Receiver
name is expected to remain constant during entire reporting
sessions, this information should be sent out occasionally over
random time intervals to maximize success of reaching a RRC and also
conserve network bandwidth.
Source Port Used: 16 bits - This metrics is defined in section 5.5
of [RAQMON-FRAMEWORK]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 Port Used: 16 bits - This metrics is defined in section 5.6
of [RAQMON-FRAMEWORK], and describes the receiver port used by the
application to communicate to the receiver. Follows same syntax as
Source Port Used.
Session Setup Date/Time (NTP timestamp): 64 bits - This metrics is
defined in section 5.7 of [RAQMON-FRAMEWORK] represented using the
timestamp format of the Network Time Protocol (NTP), which is in
seconds [RFC 1305]. 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. In some fields
where a more compact representation is appropriate, only the middle
32 bits are used; that is, the low 16 bits of the integer part and
the high 16 bits of the fractional part. The high 16 bits of the
integer part must be determined independently.
Siddiqui, et al. Expires January, 2005 [Page 10]
Internet Draft tcpsip July 1, 2004
A Data Source that has no notion of wallclock or time SHOULD set the
appropriate RAQMON flag to 0 to avoid wasting 64 bits in the PDU.
Since NTP time stamp is intended to provide Date/Time of a session,
it is recommended that the NTP Timestamp be used only in the first
RAQMON packet to use network resources efficiently. However such a
recommendation is context sensitive and should be enforced as deemed
necessary by each application environment.
Session Setup Delay: 16 bits - Session Setup Delay metrics is
defined in section 5.8 of [RAQMON-FRAMEWORK] and expressed in
milliseconds.
Session Duration: 32 bits - Session Setup Delay metrics is defined
in section 5.9 of [RAQMON-FRAMEWORK]. Session Duration from session
RC_N is an unsigned integer expressed in seconds.
Session Setup Status: - Session Setup Status is defined in section
5.10 of [RAQMON-FRAMEWORK]. This field starts with an 8-bit octet
count describing the length of the text and the text itself. Session
Setup Status is multiple of 32 bits.
Round Trip End-to-End Delay: 32 bits - Round Trip End-to-End Delay
is defined in section 5.11 of [RAQMON-FRAMEWORK]. This field
represents Round Trip End-to-End Delay of session RC_N which is an
unsigned Integer expressed in the order of milliseconds.
One Way End-to-End Delay: 32 bits - One Way End-to-End Delay is
defined in section 5.12 of [RAQMON-FRAMEWORK]. This field represents
One Way End-to-End Delay of sub session RC_N which is an unsigned
Integer expressed in the order of milliseconds.
Inter-Arrival Jitter: 16 bits - Inter-Arrival Jitter is defined in
section 5.13 of [RAQMON-FRAMEWORK] expressed in milliseconds.
Total number of Application Packets received: 32 bits - This
parameter is defined in section 5.14 of [RAQMON-FRAMEWORK] as an
unsigned integer representing total number of packets transmitted
within sub session RC_N by the receiver.
Total number of Application Packets sent: 32 bits - This parameter
is defined in section 5.15 of [RAQMON-FRAMEWORK] as an unsigned
integer representing total number of packets transmitted within sub
session RC_N by the sender.
Siddiqui, et al. Expires January, 2005 [Page 11]
Internet Draft tcpsip July 1, 2004
Total number of Application Octets received: 32 bits - This
parameter is defined in section 5.16 of [RAQMON-FRAMEWORK] as
unsigned integer representing total number of payload octets (i.e.,
not including header or padding) transmitted in packets by the
receiver within sub session RC_N.
Total number of Application Octets sent: 32 bits - This parameter is
defined in section 5.17 of [RAQMON-FRAMEWORK] as unsigned integer
representing total number of payload octets (i.e., not including
header or padding) transmitted in packets by the sender within sub
session RC_N.
Cumulative Application Packet Loss: 32 bits - This parameter is
defined in section 5.18 of [RAQMON-FRAMEWORK] as unsigned integer
representing the total number of packets from sub session RC_N that
have been lost while this RAQMON PDU was generated.
Packet Loss in Fraction: 8 bits - This parameter is defined in
section 5.19 of [RAQMON-FRAMEWORK] 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 loss fraction by 256.) This metrics is defined to
be the number of packets lost divided by the number of packets
expected.
Source Payload Type: 8 bit - This parameter is defined in section
5.20 of [RAQMON-FRAMEWORK] is 8-bit field specifies the payload type
of data source of communication sub session RC_N per definition of
[RFC 3550].
Receiver Payload Type: 8 bit - This parameter is defined in section
5.21 of [RAQMON-FRAMEWORK] is 8-bit field specifies receiver payload
type of communication sub session RC_N.
S_Layer2: 8 bits - This parameter defined in section 5.22 of
[RAQMON-FRAMEWORK] is a 8-bit field associated to source's IEEE
802.1p values of communication sub session RC_N. Since IEEE 802.1p
value is 3 bits, the first 3 bits of this parameter represents IEEE
802.1p value and the last 5 bits are padded to 0.
Siddiqui, et al. Expires January, 2005 [Page 12]
Internet Draft tcpsip July 1, 2004
S_Layer3: 8 bits - This parameter defined in section 5.23 of
[RAQMON-FRAMEWORK] is a 8-bit field which represents 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.24 of
[RAQMON-FRAMEWORK] is a 8-bit field which represents layer 2
priorities 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.1p value is 3 bits, the first 3 bits of
this parameter represents IEEE 802.1p value and the last 5 bits are
padded to 0.
D_Layer3: 8 bits - This parameter defined in section 5.25 of
[RAQMON-FRAMEWORK] is a 8-bit field which represents 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.
CPU Utilization: 8 bits - This parameter defined in section 5.26 of
[RAQMON-FRAMEWORK] represents the percentage of CPU used during
session RC_N up until the time this RAQMON PDU was generated. CPU
Utilization value should indicate not only CPU Utilization
associated to a session RC_N but also actual CPU Utilization, to
indicate a snapshot of end device Memory Utilization while session
RC_N in progress.
Memory Utilization: 8 bits - This parameter defined in section 5.27
of [RAQMON-FRAMEWORK] represents the percentage of total memory used
during session RC_N up until the time this RAQMON PDU was generated.
Memory Utilization value should indicate not only Memory Utilization
associated to a session RC_N but also actual Memory Utilization, to
indicate a snapshot of end device Memory Utilization while session
RC_N in progress.
Siddiqui, et al. Expires January, 2005 [Page 13]
Internet Draft tcpsip July 1, 2004
Application Name: - This parameter defined in section 5.28 of
[RAQMON-FRAMEWORK]. The Application Name fielld starts with an 8-bit
octet count describing the length of the text and the text itself.
Application Name field is multiple of 32 bits.
padding: 0, 8, 16 or 24 bits - As described earlier in this section
that if the padding bit (P) is set , the actual padding at the end
of the Basic part of the PDU is either 0,8, 16 or 24 bits to make
the basic part of the PDU multiple of 32 bits long.
2.2. APP Part of RAQMON Protocol Data Unit
The APP part of the RAQMON PDU is intended for experimental use as
new applications and new features are developed, without requiring
PDU type value registration.
Vendors are responsible for designing RDSs with appropriate SMI
Enterprise Code and publishing application specific extensions. Any
RAQMON compliant RRC MUST be able to recognize vendors SMI
Enterprise Code and Report Type, and MUST recognize the presence
Application specific extensions that trail behind vendors specific
SMI Enterprise Code and Report Type. 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 here
http://www.iana.org/assignments/enterprise-numbers. A Non-Zero SMI
Enterprise Code MUST be treated as a vendor or application specific
extension.
RAQMON PDUs are capable of carrying multiple Application Parts
within a PDU that trails multiple SMI Network Management Private
Enterprise Codes of the vendor.
Report Type: 16 bits - Vendors and Application developers should
fill in 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 - The length of the
Application Part of the RAQMON PDU in 32-bit words minus one which
includes the header of the Application Part.
Siddiqui, et al. Expires January, 2005 [Page 14]
Internet Draft tcpsip July 1, 2004
application-dependent data: variable length - Application/vendor-
dependent data to be defined by the application developers. It is
interpreted by the vendor specific application and not by the RRC
itself. It must be a multiple of 32 bits long.
2.3. 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.4. Port Assignment
Applications using RAQMON Framework requires a single fixed port.
Port numbers 7XXX have been registered with IANA for use as the
default port for RAQMON PDUs over TCP. Hosts that run multiple
applications may use this port as an indication to have used RAQMON
or provision a separate TCP port as part of provisioning RAQMON RDS
and RAQMON Collector.
The particular port number was chosen to lie in the range above 5000
to accommodate port number allocation practice within the Unix
operating system, where privileged processes can only use port
numbers below 1024 and port numbers between 1024 and 5000 are
automatically assigned by the operating systems.
3. Transporting RAQMON Protocol Data Units using SIP
This section outlines the usage of SIP [RFC3261] as a transport
protocol to carry RAQMON PDUs by defining a SIP event package
[RFC3265] as a solution. An event package named "raqmon" is defined
in this document along with some example call flows and RAQMON PDU
is represented as an xml document within the SIP notification to any
subscriber that is properly authorized to access such data. A third
party could subscribe to the participant to receive notifications of
RAQMON PDU transported using the NOTIFY method. The SUBSCRIBE
request from the RRC or any third party can use any of the set of
standard SIP authentication mechanisms to authorize the third party.
In addition, the reports transported using NOTIFY can use TLS or
S/MIME to secure the transport of the report data. In an environment
outlined above, the RRC will act as a subscriber to RAQMON events
and RDS will act as a notifier.
Siddiqui, et al. Expires January, 2005 [Page 15]
Internet Draft tcpsip July 1, 2004
Using SIP as a transport protocol to carry RAQMON PDUs has several
benefits. SIP is an existing IETF protocol and it always has been an
inherent objective of the RAQMON Framework to re-use existing
application level transport protocols to maximize the usage of
existing installation as well as to avoid transport protocol level
complexities in the design process. Furthermore, the usage of SIP
allows RAQMON to leverage SIP's NAT/Firewall traversal and
congestion solutions as well, which will solve a deployment
challenge for RAQMON.
During the establishment of the subscription, the RRC could request
the type and frequency of RAQMON reports as well. The event package
could also define the rate limitations and can be requested by the
RRC and thus can further manage network congestion.
The subscription could either be for a particular dialog, in which
the subscription would expire at the termination of the RAQMON
reporting session. The RRC could then subscribe to the dialog
package to receive notifications whenever the endpoint had a new
reporting session to report about, thus providing the third party
the information related to the session which SHOULD be sufficient
enough to make a decision as to whether to subscribe to the RAQMON
report package for this particular dialog.
Alternatively, the subscription could be temporally time bound in
which the RRC would receive notifications from all RAQMON dialogs
until the subscription expired.
A disadvantage of SIP based event notification mechanism is that the
endpoints must manage the subscription and support SIP events.
Furthermore not all end devices outlined in the introduction of the
memo will support SIP.
Siddiqui, et al. Expires January, 2005 [Page 16]
Internet Draft tcpsip July 1, 2004
3.1. SIP Event Package Definition
3.1.1. Event Package Name
This document defines a SIP Event Package as defined in RFC 3265.
The event-package token name for this package is: "raqmon"
OPEN ISSUE: Should RMON WG collaborate with SIPPING WG to define a
SIP Event package that accommodates RAQMON xml document within the
message body?
3.1.2. SUBSCRIBE Bodies
No SUBSCRIBE bodies are described by this specification.
3.1.3. Subscription Duration
Subscriptions to this event package MAY range from minutes to weeks.
Subscriptions in hours or days are more typical and are RECOMMENDED.
The default subscription duration for this event package is 24
hours.
3.1.4. NOTIFY Bodies
RAQMON report could be sent out periodically over time or in an
adhoc manner as deemed necessary by the application. As mentioned
above, like other SIP event packages, RAQMON event package could
also be defined for rate limitations.
To cover situations such as call quality degradation, no threshold
reporting kind of events are defined within the raqmon event package
as it is defined in [sipping-johnston] since such functionality can
be better achieved within RAQMON specification by creating SNMP
Traps and Alarms in RRC and by incorporating such functionality
within Enterprise Management environment or operators OSS systems.
The following syntax specification uses the augmented Backus-Naur-
Form (BNF) [RFC2234]
OPEN ISSUE: The message body should probably be a MIME type.
3.1.5. Metric Definitions
See [RAQMON FRAMEWORK] for a full description of these metrics.
Siddiqui, et al. Expires January, 2005 [Page 17]
Internet Draft tcpsip July 1, 2004
3.1.6. RAQMON Event Package Format Example
RRC --> RDS
------------
SUBSCRIBE sip:alice@example.com SIP/2.0
To: Alice <sip:alice@example.com>
From: <sip:collector@example.com>;tag=78923
Date: Mon, 28 June 2004 03:55:06 GMT
Call-Id: k3l43id034kevnx7334s
CSeq: 4 SUBSCRIBE
Contact:<sip:collector@bangladesh.example.com>
Event: raqmon
Expires: 3600
Accept: application/raqmon-pdu+xml
Content-Length: 0
RDS --> RRC
----------
200 OK sent from RDS to RRC as per RFC 3261
RDS --> RRC
----------
NOTIFY sip:user@userphone.example.com SIP/2.0
From: <sip:alice@example.com>;tag=4442
To: <sip:collector@example.com>;tag=78923
Date: Mon, 28 June 2004 03:59:09 GMT
Call-Id: k3l43id034kevnx7334s
CSeq: 20 NOTIFY
Contact: <sip:alice@ipphone.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Event: raqmon
Accept: application/sdp, message/sipfrag
Subscription-State: active;expires=3600
Content-Type:application/raqmon-pdu+xml
Content-Length: ..
<?xml version="1.0" encoding="UTF-8"?>
<raqmonpdu xmlns="urn:ietf:params:xml:ns:rmpdu"
xmlns:raqmon="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:rmpdu rmpdu.xsd"
dsrc="12345">
Siddiqui, et al. Expires January, 2005 [Page 18]
Internet Draft tcpsip July 1, 2004
<smi enterpriseCode="0">
<rc_n id="1">
<ntp>14587393</ntp>
<da>1.2.3.4</da>
<ra>2.3.4.5</ra>
<jitter type="inter-arrival">1234</jitter>
<jitter type="absolute">sdfsdf</jitter>
</rc_n>
<rc_n id="2">
...
</rc_n>
...
</smi>
<smi enterpriseCode="1000">
<extension>
[...]
</extension>
</smi>
</raqmonpdu>
Open issue: XML Schema will be defined as an RMON WG effort.
RRC --> RDS
----------
200 OK sent from RRC to RDS as per RFC 3261
Siddiqui, et al. Expires January, 2005 [Page 19]
Internet Draft tcpsip July 1, 2004
3.1.7. An Event Flow Example Between RDS and RRC
This section shows a simple flow between a RDS and RRC to transport
a RAQMON PDU using SIP event package. Provisioning RRCs and RDSs is
beyond the scope of the RAQMON Specification [RAQMON-FRAMEWORK] and
hence the flows assume that the RAQMON report collector is notified
by the SIP registrar when a new User Agent that runs on the embedded
devices registers which supports the event package.
Alice (RDS) Proxy/Registrar RRC Bob
| | | |
| | | |
| REGISTER Allow-Event:raqmon F1 | |
|------------------->| | |
| 200 OK F2 | | |
|<-------------------| | |
| | SUBSCRIBE Event:raqmon F3 |
| |<-------------------| |
| SUBSCRIBE Event:raqmon F4 | |
|<-------------------| | |
| 200 OK F5 | | |
|------------------->| | |
| | 200 OK F6 | |
| |------------------->| |
| INVITE F7 | | |
|------------------->| | |
| | INVITE F8 | |
| |---------------------------------------->|
| | 200 OK F9 | |
| |<----------------------------------------|
| 200 OK F10 | | |
|<-------------------| | |
| ACK F11 | | |
|------------------->| | |
| | ACK F12 | |
| |---------------------------------------->|
| RTP | | |
|<============================================================>|
| RTCP | | |
|<============================================================>|
| NOTIFY Event:raqmon F17 | |
|------------------->| | |
| | NOTIFY Event:raqmon F18 |
| |------------------->| |
| | 200 OK F19 | |
| |<-------------------| |
| 200 OK F20 | | |
|<-------------------| | |
| NOTIFY Event:raqmon F21 | |
|------------------->| | |
| | NOTIFY Event:raqmon F22 |
| |------------------->| |
| | 200 OK F23 | |
| |<-------------------| |
| 200 OK F24 | | |
|<-------------------| | |
| | | |
| BYE F25 | | |
|------------------->| BYE F26 | |
| |---------------------------------------->|
| | 200 OK F27 | |
| |<----------------------------------------|
| 200 OK F28 | | |
Siddiqui, et al. Expires January, 2005 [Page 20]
Internet Draft tcpsip July 1, 2004
|<-------------------| | |
| NOTIFY Event:raqmon F29 | |
|------------------->| | |
| | NOTIFY Event: raqmon F30 |
| |------------------->| |
| | 200 OK F31 | |
| |<-------------------| |
| 200 OK F32 | | |
|<-------------------| | |
Figure 3. RAQMON PDU sent within a SIP Notification during a
communication session
4. Congestion Safe RAQMON Operation
RAQMON PDU can be transmitted over multiple transport protocols. A
RAQMON PDU allows the usage of TCP as transport and hence congestion
safety is inherently achieved by TCP congestion control mechanism.
RAQMON PDU transported over SIP also enjoys SIP congestion safety
attributes. Implementers MUST follow section 3.0 of [RAQMON-
FRAMEWORK] guidelines that outlines measures that MUST be taken to
use RAQMON in congestion safe manner.
5. Normative References
RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC2119] Bradner, S.,"Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M. and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
6. Informative References
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] H. Schulzrinne, "RTP Profile for Audio and Video
Conferences with Minimal Control" RFC 3550, July 2003.
Siddiqui, et al. Expires January, 2005 [Page 21]
Internet Draft tcpsip July 1, 2004
[RFC1305] Mills, D., "Network Time Protocol Version 3", RFC 1305,
March 1992.
[RFC1034] Mockapetris, P., "Domain Names - Concepts and
Facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, October 1989.
[RFC1597] Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de
Groot, "Address Allocation for Private Internets", RFC
1597, March 1994.
[RFC2679] G. Almes, S.kalidindi and M.Zekauskas, "A One-way Delay
Metric for IPPM", RFC 2679, September 1999
[RFC2680] G. Almes, S.kalidindi and M.Zekauskas, "A One-way Packet
Loss Metric for IPPM", RFC 2680, September 1999
[RFC2681] G. Almes, S.kalidindi and M.Zekauskas, "A Round-Trip
Delay Metric for IPPM", RFC 2681, September 1999
[ISO10646] International Standards Organization, "ISO/IEC DIS
10646-1:1993information technology -- universal
multiple-octet coded character set (UCS) -- part I:
Architecture and basic multilingual plane," 1993.
[UNICODE] The Unicode Consortium, The Unicode Standard New York,
New York:Addison-Wesley, 1991.
[IEEE802.1D] Information technology-Telecommunications and
information exchange between systems--Local and
metropolitan area networks-Common Specification a--Media
access control (MAC) bridges:15802-3: 1998 (ISO/IEC)
[ANSI/IEEE Std 802.1D, 1998 Edition]
[RFC1349] P. Almquist, "Type of Service in the Internet Protocol
Suite", RFC 1349, July 1992
[RFC1812] F. Baker, "Requirements for IP Version 4 Routers"
RFC1812, June 1995
[RFC2474] K. Nicholas, S. Blake, F. Baker and D. Black, "Definition
of the Differentiated Services Field (DS Field) in the
IPv4 and IPv6 Headers", RFC2474, December 1998
Siddiqui, et al. Expires January, 2005 [Page 22]
Internet Draft tcpsip July 1, 2004
[RFC2475] S. Blake, D. Black, M. Carlson, E.Davies, Z.Wang and
W.Weiss, "An Architecture for Differentiated Services"
RFC2475, December 1998
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RAQMON-FRAMEWORK] A. Siddiqui, D.Romascanu, and E. Golovinsky,
"Framework for Real-time Application Quality of
Service Monitoring (RAQMON)", Internet-Draft,
draft-ietf-rmonmib-raqmon-framework-05.txt,
September 2003
[sipping-johnston] Alan Johnston, H. Sinnreich, A. Clark, A.
Pendleton, "RTCP Summary Report Delivery to
Third Parties", draft-johnston-sipping-rtcp-
summary-02.txt, February 15, 2004
7. Contributions
The authors would like to thank Bill Walker and Joseph Mastroguilio
for their discussions. Authors also acknowledge that [sipping-
johnston] had an influence on shaping some of the ideas covered
within this memo but Much of the proposal here was inspired by
[sipping-johnston] but significantly modified to fit RAQMON
framework needs.
8. Appendix
The implementation notes included in Appendix are for informational
purposes only and are meant to clarify the RAQMON specification.
Pseudo code for RDS & RRC
We provide examples of Psuedo code for aspects of RDS and RRC. There
may be other implementation methods that are faster in particular
operating environments or have other advantages.
Siddiqui, et al. Expires January, 2005 [Page 23]
Internet Draft tcpsip July 1, 2004
RDS:
when (session starts} {
report.identifier = session.endpoints, session.starttime;
report.timestamp = 0;
while (session in progress) {
wait interval;
report.statistics = update statistics;
report.curtimestamp += interval;
if encryption required
report_data = encrypt(report, encrypt
parameters);
else
report_data = report;
raqmon_pdu = header, report_data;
send raqmon-pdu;
}
}
RRC:
listen on raqmon port
when ( raqmon_pdu received ) {
decrypt raqmon_pdu.data if needed
if report.identifier in database
if report.current_time_stamp > last update
update session statistics from report.statistics
else
discard report
}
9. Security Considerations
[RAQMON-FRAMEWORK] memo outlined a detailed threat model associated
to RAQMON and some security considerations taken into account within
RAQMON specification to alleviate those threats. For TCP
implementation, TLS will be used to provide security. SIP security
guidelines will be followed for SIP Event Notification.
Open issue: threats specific to the respective transports and
possible solution will be worked as a wg item.
10. IANA Considerations
This memo introduces a port 7XXX for usage of TCP as transport
protocol at http://www.iana.org/numbers.html as specified in Section
3.1.
Siddiqui, et al. Expires January, 2005 [Page 24]
Internet Draft tcpsip July 1, 2004
11. Authors Addresses
Anwar A. Siddiqui
Avaya Labs
307 Middletown Lincroft Road
Lincroft, New Jersey 07738
USA
Tel: +1 732 852-3200
E-mail: anwars@avaya.com
Eugene Golovinsky
BMC Software
2101 CityWest Blvd.
Houston, Texas 77042
USA
Tel: +1 713 918-1816
Email: eugene_golovinsky@bmc.com
Mahfuzur Rahman
Panasonic Digital Networking Lab
Two Research Way
Princeton, NJ 08540
Tel: +1 609 734 7332
Email: mahfuz@research.panasonic.com
Bin Hu
Motorola Inc.
805 east Middlefield Road
Mountain View CA 94043
Tel: +1 650 318 3201
Email: bhu@Motorola.com
Yongbum "Yong" Kim
Broadcom
3151 Zanker Road
San Jose, CA 95134
Tel: +1 408 501 7800
E-mail: ybkim@broadcom.com
12. IPR Disclosure
By submitting this Internet-Draft, we certify that any applicable
patent or other intellectual property right (IPR) claims of which we
am aware have been disclosed, and any of which we become aware will
be disclosed, in accordance with RFC 3668.
Siddiqui, et al. Expires January, 2005 [Page 25]
Internet Draft tcpsip July 1, 2004
13. Full Copyright Statement
Copyright (C) The Internet Society
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTORS, THE ORGANIZATIONS THEY
REPRESENT OR ARE SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11.
Copies of IPR disclosures made to the IETF secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line repository at
http://www.ietf.org/ipr. The IETF invites any interested party to
bring to its attention any copyrights, patents or patent
applications, or other proprietary rights which may cover technology
that may be required to practice this standard. Please address the
information to the IETF at ietf-ipr@ietf.org.
14. Acknowledgement:
The Internet Society currently provides funding for the RFC Editor
function.
Siddiqui, et al. Expires January, 2005 [Page 26]
| PAFTECH AB 2003-2026 | 2026-04-24 10:36:15 |