Internet DRAFT - draft-jian-ipv6-meaheader
draft-jian-ipv6-meaheader
IPv6 Working Group Jian Zhang
Hongfei Chen
Internet Draft Huawei Techonologies
Expires: October 2006 April 7, 2006
IPv6 measurement header
draft-jian-ipv6-meaheader-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other 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
BCP 79.
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 obsoleted 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
This Internet-Draft will expire on October 7, 2006.
Jian et al. Expires October 7, 2006 [Page 1]
Internet-Draft meaheader April 2006
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract
The purpose of this document is to introduce a measurement header.
Measurement header is a new type of IPv6 extended header used for
network measurement. The information needed by measurement carried in
measurement header. The parameters can be calculated based on these
information.
Conventions used in this document
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 RFC-2119.
Table of Contents
1. Introduction................................................3
2. Application scenario.........................................3
2.1. Scenario 1: One-way measurement.........................3
2.2. Scenario 2: Two-way measurement.........................4
2.3. Scenario 3: High layer protocol measurement.............4
3. Measurement header..........................................5
3.1. Format.................................................5
3.2. Measurement Options.....................................6
3.2.1. Measurement Options Format.........................7
3.2.2. Pad1..............................................7
3.2.3. PadN..............................................8
3.2.4. Entry Time Stamp...................................8
3.2.5. Exit Time Stamp....................................9
4. IANA considerations........................................10
5. Security Considerations.....................................10
6. References.................................................11
6.1. Normative References...................................11
6.2. Informative References.................................11
Author's Addresses............................................11
Intellectual Property Statement................................12
Disclaimer of Validity........................................12
Copyright Statement...........................................12
Acknowledgment................................................13
Jian et al. Expires October 7, 2006 [Page 2]
Internet-Draft meaheader April 2006
1. Introduction
This document describes a measurement header for IPv6 specification.
Measurement header is an IPv6 extended header used by network
performance measurement. This document also defines some measurement
options used to carry measurement information. Some application
scenarios that measurement header can be used are described.
2. Application scenario
2.1. Scenario 1: One-way measurement
One-way measurement is an important method to assess the performance
of IP network. The performance parameters, such as IP packet delay,
IP packet delay variation and so on, are used to assess the status of
network. In the traditional measurement methodology, delay is
calculated by t2, the time that packet arrives destination node,
minus t1, the time that packet leaves source node. They are got from
source node and destination node by complex protocol and special
packets. For IPv6 with measurement header, source node records the
time stamp (t1) when sends measurement packet, and destination node
records the time stamp (t2) when receives the measurement packet. The
delay of packet can be directly calculated by t2 minus t1.
In the measurement, source node increases the sequence of measurement
header. If the sequence is not continuum or disorder, then there may
be packets lost or disorder in the network.
Test packets with Measurement Header
----------------------------------------->
IPv6 Network
-------------------------
Source Node | | Destination Node
-------- | | --------
| | | | | |
| |------| |------| |
-------- | | --------
| |
-------------------------
Figure 1: Scenario 1
Jian et al. Expires October 7, 2006 [Page 3]
Internet-Draft meaheader April 2006
2.2. Scenario 2: Two-way measurement
Two-way performance of network is important for some applications,
such as voice/video message, transactions and so on. When performing
two-way measurement, source node records time stamp and sends request
measurement packet. When received the request packet, destination
node records the time stamp when the packet was received, copies the
time stamp in request packet to reply packet, records time stamp when
the packet was sent, and sends the reply packet to source node.
Source node records time stamp of reply packet. The delay for total
and segments can be calculated by t2 (entry time stamp) minus t1
(exit time stamp).
Request packets with Measurement Header
----------------------------------------->
Ack Packets with Measurement Header
<-----------------------------------------
IPv6 Network
-------------------------
Source Node | | Destination Node
-------- | | --------
| | | | | |
| |------| |------| |
-------- | | --------
| |
-------------------------
Figure 2: Scenario 2
2.3. Scenario 3: High layer protocol measurement
Using IPv6 Measurement Header, it is convenience to measure IP
performance. It can also measure high layer protocol performance,
such as TCP, UDP, FTP, DHCP, HTTP and so on, worked together with
high layer protocols. It can simplify the measurement of high layer
protocols by inserted the measurement header into high layer
protocols packets. High layer protocol can calculate the performance
parameters based on the information carried in measurement header.
Jian et al. Expires October 7, 2006 [Page 4]
Internet-Draft meaheader April 2006
3. Measurement header
3.1. Format
The measurement header is identified by a Next Header value in the
immediately preceding header. The value should be assigned by IANA.
The measurement header has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto | Header Len | MH Type |I|O| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. Message Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Measurement Header format.
Payload Proto
8-bit selector. Identifies the type of header immediately
following the Measurement Header. Uses the same values as the IPv6
Next Header field [IPv6].
Header Len
8-bit unsigned integer, representing the length of the Measurement
Header in units of 8 octets, excluding the first 8 octets. The
length of the Measurement Header MUST be a multiple of 8 octets.
MH Type
8-bit selector. Identifies the particular measurement message in
question. An unrecognized MH Type field MUST be discard silently.
Current values are specified as follow:
o 0 - unidirectional measurement message
o 1 - request message of bi-directional measurement
Jian et al. Expires October 7, 2006 [Page 5]
Internet-Draft meaheader April 2006
o 2 - reply message of bi-directional messurement
I flag
o 0 - don't record the time stamp that the packet entry the
interface.
o 1 - record the time stamp that the packet entry the interface.
O flag
o 0 - don't record the time stamp that the packet exits the
interface.
o 1 - record the time stamp that the packet exits the interface.
Reserved
6-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Sequence
A 16-bit unsigned integer used by receiving node to sequence
request measurement message and by the sending node to match a
returned reply measurement message with this request message.
Message Data
A variable length field containing the data specific to the
indicated measurement header type and flags.
3.2. Measurement Options
Measurement messages can include zero or more measurement options.
This allows optional fields that may not be needed in every use of a
particular Measurement Header, as well as future extensions to the
format of the messages. Such options are included in the message data
field of the message itself, after the fixed portion of the message
data.
The presence of measurement options will be indicated by the Header
Len of the Measurement Header.
Jian et al. Expires October 7, 2006 [Page 6]
Internet-Draft meaheader April 2006
3.2.1. Measurement Options Format
Measurement options use a type-length-value (TLV) format as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Option Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Measurement Options TLV format.
Option Type
8-bit identifier of the type of measurement option. When processing a
Measurement Header containing an option for which the Option Type
value is not recognized by the receiver, the receiver MUST quietly
ignore and skip over the option, correctly handling any remaining
options in the message.
Option Length
8-bit unsigned integer, representing the length in octets of the
measurement option, not including the Option Type and Option Length
fields.
Option Data
A variable length field that contains data specific to the option.
3.2.2. Pad1
The Pad1 option has format as follows:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type = 0 |
+-+-+-+-+-+-+-+-+
Figure 5: Pad1 option format
NOTE! The format of the Pad1 option is a special case - it has
neither Option Length nor Option Data fields. The Pad1 option is used
to insert one octet of padding in the Measurement Options area of a
Measurement Header. If more than one octet of padding is required,
the PadN option, described next, should be used rather than multiple
Pad1 options.
Jian et al. Expires October 7, 2006 [Page 7]
Internet-Draft meaheader April 2006
3.2.3. PadN
The PadN option has format as follow:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Type = 1 | Option Length | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Figure 6: PadN option format
The PadN option is used to insert two or more octets of padding in
the Measurement Options area of a measurement message. For N octets
of padding, the Option Length field contains the value N-2, and the
Option Data consists of N-2 zero-valued octets. PadN Option data MUST
be ignored by the receiver.
3.2.4. Entry Time Stamp
Entry Time Stamp has format as follow:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Type = 2 | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Recorded IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Time Stamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Entry Time Stamp Option Format
Entry Time Stamp option is used to record the time when the device
has received the packet from link.
Recorded IPv6 Address is a unicast routable IPv6 address identified
the device that processed this packet. This address should be
identical with the address in Exit Time Stamp Option.
Jian et al. Expires October 7, 2006 [Page 8]
Internet-Draft meaheader April 2006
Time Stamp Option is the time that the packet has been received by
the device. The time stamp follows the format defined in [NTP]. It is
a 64-bit unsigned fixed-point number, in seconds relative to 0h on 1
January 1900. The integer part is in the first 32 bits and the
fraction part in the last 32 bits.
3.2.5. Exit Time Stamp
Exit Time Stamp has format as follow:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Type = 3 | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Recorded IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Time Stamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Exit Time Stamp Option Format
Exit Time Stamp option is used to record the time when the device
forwards the packet to link.
Recorded IPv6 Address is a unicast routable IPv6 address identified
the device that processed this packet. This address should be
identical with the address in Entry Time Stamp Option.
Time Stamp Option is the time that the packet forwards to link by the
device. The time stamp follows the format defined in [NTP]. It is a
64-bit unsigned fixed-point number, in seconds relative to 0h on 1
January 1900. The integer part is in the first 32 bits and the
fraction part in the last 32 bits.
If the end-to-end delay needs to be calculated, the source node
should record Exit Time Stamp Option, and the destination node should
record the Entry Time Stamp Option. The end-to-end delay can be
Jian et al. Expires October 7, 2006 [Page 9]
Internet-Draft meaheader April 2006
calculated by destination Entry Time Stamp minus source Exit Time
Stamp.
4. IANA considerations
IANA services are required for this document. The values for new
measurement header and measurement options must be assigned from the
IPv6 [IPv6] numbering space.
5. Security Considerations
IPv6 already contains mechanism for security. As a result, the
vulnerabilities of the new measurement header defined in this
document are similar to those that already exist for IPv6.
Measurement header only provides a basic instrument used for IPv6
network performance measurement. This document does not provide any
methodology used for IPv6 network performance measurement. The
security need to be considered by the measurement methodology using
the measurement options.
Jian et al. Expires October 7, 2006 [Page 10]
Internet-Draft meaheader April 2006
6. References
6.1. Normative References
[IPv6] Stephen E. Deering. and Robert M. Hinden. "Internet
Protocol, Version 6 (IPv6) Specification", RFC 2460, Cisco
Systems, Inc., December 1998.
[NTP] David L. Mills. "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305,
March 1992.
[IPDV] Carlo Demichelis. and Philip Chimento. "IP Packet Delay
Variation Metric for IP Performance Metrics (IPPM)", RFC
3393, November 2002.
[NPM] Vilho Raisanen. and Glenn Grotefeld. "Network performance
measurement with periodic streams", RFC 3432, November 2002.
[OWAMP] Stanislav Shalunov. and Benjamin Teitelbaum. "One-way
Active Measurement Protocol (OWAMP) Requirements", RFC 3763,
April 2004.
[FIPM] Vern Paxson and Guy Almes. "Framework for IP Performance
Metrics", RFC 2330, May 1998.
[IPPM] Jamshid Mahdavi. and Vern Paxson. "IPPM Metrics for
Measuring Connectivity", RFC 2678, September 1999.
6.2. Informative References
[Y.1540] "Internet protocol data communication service - IP packet
transfer and availability performance parameters", ITU-T,
12/2002
Author's Addresses
Jian Zhang
Huawei Technologies Co., LTD.
No. 3 Xinxi Road, Shangdi,
HaiDian District,
Beijing City,
The P.R.China
Email: hwzhj@huawei.com
Jian et al. Expires October 7, 2006 [Page 11]
Internet-Draft meaheader April 2006
HongFei Chen
Huawei Technologies Co., LTD.
No. 3 Xinxi Road, Shangdi,
HaiDian District,
Beijing City,
The P.R.China
Email: chenhongfei@huawei.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
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 IPR 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 that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS 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.
Copyright Statement
Copyright (C) The Internet Society (2006).
Jian et al. Expires October 7, 2006 [Page 12]
Internet-Draft meaheader April 2006
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jian et al. Expires October 7, 2006 [Page 13]
