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 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 From: ;tag=78923 Date: Mon, 28 June 2004 03:55:06 GMT Call-Id: k3l43id034kevnx7334s CSeq: 4 SUBSCRIBE Contact: 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: ;tag=4442 To: ;tag=78923 Date: Mon, 28 June 2004 03:59:09 GMT Call-Id: k3l43id034kevnx7334s CSeq: 20 NOTIFY Contact: 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: .. Siddiqui, et al. Expires January, 2005 [Page 18] Internet Draft tcpsip July 1, 2004 14587393 1.2.3.4 2.3.4.5 1234 sdfsdf ... ... [...] 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]