Network Working Group Y. Kikuchi
Internet-Draft Kochi University of Technology
Expires: August 30, 2007 S. Matsushima
Softbank Telecom Corp.
K. Nagami
Intec Netcore Inc.
S. Uda
Japan Advanced Institute of
Science and Technology, Hokuriku
N. Ogashiwa
Network Oriented Software Inc.
February 26, 2007
Quality Measurement Requirements for Tunneling Protocols
draft-kikuchi-tunnel-measure-req-00.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 August 30, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Kikuchi, et al. Expires August 30, 2007 [Page 1]
Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007
Abstract
This draft describes requirements to measure end-to-end qualities of
tunnels passively and to monitor them via Simple Network Management
Protocol (SNMP) [1]. This feature is necessary for Service Providers
(SPs), especially, who provide transports to users using tunnels. In
addition, the draft shows an example to measure Generic Routing
Encapsulation (GRE) [2] [3] tunnels.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. Service Model . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Active vs. Passive . . . . . . . . . . . . . . . . . . . . 6
4.2. Quality Evaluation . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Indication of Sequence Number . . . . . . . . . . . . 6
4.2.2. Field Length Condideration . . . . . . . . . . . . . . 7
4.2.3. Quality Measurement . . . . . . . . . . . . . . . . . 7
4.3. Getting Quality Information . . . . . . . . . . . . . . . 8
4.4. Overhead Consideration . . . . . . . . . . . . . . . . . . 8
5. Implementation . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Counters and Functions . . . . . . . . . . . . . . . . . . 9
5.2. Measurement Algorithm . . . . . . . . . . . . . . . . . . 10
5.2.1. Algorithm Behavior . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17
7. Normative References . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Kikuchi, et al. Expires August 30, 2007 [Page 2]
Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007
1. Introduction
This draft describes requirements to measure end-to-end qualities of
tunnels passively and to monitor them via SNMP. In this document,
tunnel means various technologies in order to provide networks or
datalinks virtually. Examples of tunneling are GRE, IP Encapsulation
within IP (IPIP) [4], Pseudo Wire Emulation Edge-to-Edge (PWE3) [5],
and so on.
Measuring end-to-end quality of tunnels is necessary for Transport
Service Providers (TSPs) who provide transport to users using
tunnels. However, the standards do not define measurement and
monitoring when TSPs want to know quality of their traffic through
tunnels. Therefore, we must define standards for these.
1.1. Requirements notation
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 [6].
Kikuchi, et al. Expires August 30, 2007 [Page 3]
Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007
2. Service Model
Figure 1 shows that TSP X provides a transport between user A and
user B using a tunnel. The users make an application over the
transport. The TSP may apply two or more tunnels to provide one
transport.
USER A USER B
| |
+ ................... Application .................. +
| |
LAN A ---* ... Transport by TSP X (e.g. GRE) ... *--- LAN B
| |
--- ISP 1 --- ISP 2 --- ... --- ISP n ---
Figure 1: A Service Model of TSP
TSPs provide a reachability of IP datagrams or layer 2 frames to
users. The users are not able to know about the details of the path,
that is the sequence of transit ISPs, under the transport because the
tunnel eliminates the path so that the users must recognize that both
ends of the transport as a neighbor. The reachability maintenance
and the quality management are served as TSPs' communication
services.
TSPs provide simplified and virtual transports by hiding the
underlying layers to the users. The users are able to reduce the
cost of operation and management because they need not maintain the
underlying layers. In addition, TSPs may be able to provide better
transports when the users would have some tunnels via different
paths. Furthermore, TSPs may be able to provide protocols needed by
the users even if there are no such protocols served by the ISPs.
Kikuchi, et al. Expires August 30, 2007 [Page 4]
Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007
3. Motivations
TSPs need to know the quality of their tunnels in order to know
whether the tunnels are in the normal state or not. It could be an
important material to trace down the cause of the trouble when the
applications is not working properly. Without the information, it is
difficult for TSP to determine whether the problem come from user,
TSP itself, or ISP.
TSPs need to know the tunnels' quality when they have multiple
tunnels to serve transports. The TSPs may be able to serve
appropriate transports to users by selecting better quality tunnels.
using better tunnels based on the quality. In addition, the TSPs may
be able to distribute the load of the transports to the tunnels over
different paths.
Kikuchi, et al. Expires August 30, 2007 [Page 5]
Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007
4. Requirements
This section describes each requirement to measure end-to-end quality
of tunnel for TSPs.
4.1. Active vs. Passive
There are two ways to measure a quality of tunnel, one is active and
the other is passive. Active measurement uses additional probing
packets to determine the quality of the channel. Passive measurement
uses the tunnel packets to measure.
From the TSPs point of view, passive measurement SHOULD be supported,
because TSPs want to measure the tunnel quality for management of
contracts with their customers. Service Level Agreement (SLA) in the
contracts should describe maximum out-of-sequence rate such as loss,
duplicate and reordering. SLA should refer the users' packets
themselves, therefore, the measurement should be determined passively
rather than actively. The protocols that support passive measurement
are Real Time Protocol (RTP) [7], GRE and PWE3, which have sequence
numbers in their headers.
On the other hand, it is not necessary to let the protocol have
quality measurement function in active measurement. In this case,
TSPs MAY construct the active measurement method independently from
the target protocol. The typical example is PING that uses Internet
Control Message Protocol (ICMP) [8].
4.2. Quality Evaluation
In the standards of GRE and PWE3 that have sequence number field in
header, sequence numbers are defined to be used on receivers'
processing. The receivers may discard and/or buffer packets
according to loss, duplicate and reordering based on sequence
numbering. However, there is no definition to determine the quality
of tunnels and for monitoring by TSPs and users.
Therefore, it is necessary to define how we use sequence numbers in
the standards. The definition SHOULD contain two items, one is what
quality the protocols measure, and the other is how the protocols
evaluate the quality.
4.2.1. Indication of Sequence Number
There are two ways to indicate whether the sequence numbers are
enabled or not. Tunneling protocol SHOULD support the indication
either sequencing is enabled or not.
Kikuchi, et al. Expires August 30, 2007 [Page 6]
Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007
One is to prepare an indication field in the header independent from
the sequence number field. GRE is an example of this.
The other is to indicate a special sequence number, typically 0,
meaning disabled. In this case, we need an additional process on
wrapping sequence number overflow because the number will skip 0 that
does not seem continuous even the tunnel packets are still in-
sequence.
4.2.2. Field Length Condideration
The length of sequence number field should be long enough to the
transmission speed. Otherwise, the period of a lap of the sequence
number become short so that the reliability of the measurement will
go down. For example, the algorithm may determine as reordering even
if there is a burst packet loss in case of the path change.
It is necessary to determine whether a burst packet loss is happened
or an arrival of a very past packet when the difference of the
sequence numbers between two continuous packets is very large. The
typical technique is to use a half of the representable maximum
value. This is simple and adequate if the field is long enough.
However, the existence of the sequence number field generates more
amount of transmission. Thus, in the circumstance of insufficiently
long field makes overhead for protocols that are sensitive to
resource consumption. The sequence number field length should be
consider about tradeoff between bandwidth efficiency and quality
assurance.
4.2.3. Quality Measurement
It is REQUIRED to detect whether packets in a tunnel are in-sequence
or out-of-sequence. It is easy for protocols with sequence numbers
to introduce such a function by watching the continuity. Moreover,
it is REQUIRED to monitor quantity of irregular packets i.e. loss,
duplicate and reordering. A simple method will be showed in
Section 5.
Measuring the packet arrival delay and/or jitter of a tunnel MAY be
required. In this requirement, timestamp that synchronized to
reference clock would exist as sequence number field. In current
protocol, RTP and PWE3 have such functions, however GRE does not so
that neither delay nor jitter can be measured.
Kikuchi, et al. Expires August 30, 2007 [Page 7]
Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007
4.3. Getting Quality Information
Tunneling protocols SHOULD support not only quality measurement but
also monitoring. However GRE and PWE3 use sequence numbers only for
internal processing.
The result of the quality measurement of tunnels MUST be monitored by
TSPs and users. In addition, it is needed to modify some parameters
used in the measurement mechanisms. Moreover, it may be needed to
notify on irregular occasions and illegal operations. These
functions SHOULD be defined as standard MIBs in SNMP.
4.4. Overhead Consideration
We should consider the computing and space costs of the
implementations where the standard defines the measurement and
monitoring. These are overhead of traffic transmission, which may
reflect the cost of equipment introductions and operational expenses.
We should not adopt non-scalable mechanisms. we should pay much
attention especially for resource consumption sensitive protocols
e.g. mobile protocols.
The types of overheads are following.
o the space of sequence number in protocol header,
o the space of counters and registers implemented in routers,
o the computing resources for quality measurement, and so on.
We should adopt a simplified determination in some cases when there
are a precise complex determination and a simpler one. For example,
we do not need a precise state but also an approximation of the
degree of the difference from the normal operation.
Kikuchi, et al. Expires August 30, 2007 [Page 8]
Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007
5. Implementation
We will illustrate an example of the quality measurement mechanism of
GRE in accordance with the discussion above. The headers of GRE
packets can contain sequence numbers. We will show an algorithm to
determine the quality, i.e. loss, duplicate and reordering, of a GRE
tunnel while the receive side of the tunnel observes the sequence
numbers.
We make the following assumptions to simplify the situation.
o Each S bit of the packets in a tunnel is always 1, which is the
indication flag of sequence number validity.
o Each K bit is always 0 that means the key field is unused so that
we do not distinguish any flow in the tunnel.
o The parameter OUTOFORDER_TIMER and MAX_PERFLOW_BUFFER are both 0
that means all the buffering on the receiving side is disabled.
Note that according to the standard of GRE[3] we should discard
packets that are not in-sequence.
5.1. Counters and Functions
We need the following counters for each receiving side of GRE tunnel.
o recvcnt: maintains the number the successive packet should have
o losscnt: the number of loss of packets
o duplcnt: the number of packet duplications
o reodcnt: the number of reordering packets
The counters above are unsigned 32bit integer and initialized by 0.
Note that recvcnt is slightly different from GRE standard[3] because
the initial value should be (2**32)-1 in the standard.
The value of the counters above SHOULD be obtained by SNMP R/O MIB.
The counters MAY be resettable by SNMP R/W MIB.
This algorithm uses three following functions.
o measure: invoked by the reception of packets; the algorithm itself
o raise: pass the packet to the higher layer
Kikuchi, et al. Expires August 30, 2007 [Page 9]
Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007
o discard: drop the packet
5.2. Measurement Algorithm
This algorithm determines a receiving packet is whether normal or not
while comparison of a counter "recvcnt" with the sequence number of
the packet named "seqno". The basic idea consists of the following
conditions.
1. if recvcnt and seqno are same then "in-sequence",
2. else if seqno is just a predecessor of recvcnt then "duplicate";
3. otherwise if seqno proceed then "loss" else "reordering".
In detail, GRE receivers can measure the quality by the following
C-like codes.
measure(packet_t packet)
{
unsigned int seqno;
seqno = packet->header->seqno; // get seq # from header
if (seqno == recvcnt) { // no problem
recvcnt++;
raise(packet);
return;
} elsif (seqno+1 == recvcnt) { // same seq # as predecessor
duplcnt++;
discard(packet);
return;
}
signed int diff;
diff = (signed int)(seqno - recvcnt);
if (diff > 0) { // loss (future packet)
losscnt += diff;
recvcnt = seqno;
} else { // reordering (past packet)
reodcnt++;
}
discard(packet);
return;
}
Figure 2
Kikuchi, et al. Expires August 30, 2007 [Page 10]
Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007
5.2.1. Algorithm Behavior
The following diagrams show behaviors of the algorithm on receiving
out_of_sequence packets. Figure 4 shows the legend of flow diagram
here. Left and right sides are a sender and receiver of a GRE tunnel
respectively. Time flows upper to lower in the diagrams. This
illustrates a normal transmission with the sequence number n.
time sender receiver
| | |
| n | | n 0 0 0
| |----[seq #: n]----->|
| n+1 | | n+1 0 0 0
| | |
V V V
Figure 3
Figure 4, Figure 5 and Figure 6 show simple cases such as loss,
duplicates and reordering packets respectively.
Kikuchi, et al. Expires August 30, 2007 [Page 11]
Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007
[reodcnt]................
[duplcnt].............. :
[losscnt]............ : :
: : :
[recvcnt]......... : : :
........[sendcnt] : : : :
: : : : :
: : : : :
: : : : :
| |
0 | | 0 0 0 0
|------------------->|
1 | | 1 0 0 0
|------------------->|
2 | | 2 0 0 0
|-----> !LOST! |
3 | |
|------------------->|
4 | | 4 1 0 0
|-----> !LOST! |
5 | |
|-----> !LOST! |
6 | |
|------------------->|
7 | | 7 3 0 0
| |
V V
Figure 4
Kikuchi, et al. Expires August 30, 2007 [Page 12]
Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007
[reodcnt]................
[duplcnt].............. :
[losscnt]............ : :
: : :
[recvcnt]......... : : :
........[sendcnt] : : : :
: : : : :
| |
0 | | 0 0 0 0
|------------------->|
1 | | 1 0 0 0
|-------!DUP!------->|
| \ | 2 0 0 0
| \-------->|
2 | | 2 0 1 0
|------------------->|
3 | | 3 0 1 0
|-------!DUP!------->|
4 | \ | 4 0 1 0
| !DUP!------>|
| \ | 4 1 2 0
| \------>|
| | 4 1 3 0
|------------------->|
5 | | 5 1 3 0
| |
V V
Figure 5
Kikuchi, et al. Expires August 30, 2007 [Page 13]
Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007
[reodcnt]................
[duplcnt].............. :
[losscnt]............ : :
: : :
[recvcnt]......... : : :
........[sendcnt] : : : :
: : : : :
| |
0 | | 0 0 0 0
|------------------->|
1 | | 1 0 0 0
|-------\ |
2 | \ |
|---------\--------->|
3 | \ | 3 1 0 0
| \------->|
| | 3 1 0 1
|------------------->|
4 | | 4 1 0 1
|-------\ |
5 | \ |
|------\ \ |
6 | \ \ |
|--------\--\------->|
7 | \ \ | 7 3 0 1
| \ \----->|
| \ | 7 3 0 2
| \------>|
| | 7 3 0 3
| |
V V
Figure 6
Figure 7 and Figure 8 show cases in a little bit complex situations.
Figure 7 shows that the algorithm can not distinguish a combination
of duplication and loss from a reordering. Compare the flow to
former of Figure 6.
Kikuchi, et al. Expires August 30, 2007 [Page 14]
Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007
[reodcnt]................
[duplcnt].............. :
[losscnt]............ : :
: : :
[recvcnt]......... : : :
........[sendcnt] : : : :
: : : : :
| |
0 | | 0 0 0 0
|------------------->|
1 | | 1 0 0 0
|-----!DUP!-->!LOST! |
2 | \ |
|---------\--------->|
3 | \ | 3 1 0 0
| \------->|
| | 3 1 0 1
| |
V V
Figure 7
Figure 8 shows that the algorithm interprets it reordering when a
duplicated packet does not come just in succession. There is no
storage to hold all the information of packet arrivals in order to
make the measurement overhead light instead of accuracy.
[reodcnt]................
[duplcnt].............. :
[losscnt]............ : :
: : :
[recvcnt]......... : : :
........[sendcnt] : : : :
: : : : :
| |
0 | | 0 0 0 0
|------------------->|
1 | | 1 0 0 0
|------!DUP!-------->|
2 | \ | 2 0 0 0
|----------\-------->|
3 | \ | 3 0 0 0
| \------>|
| | 3 0 0 1
V V
Figure 8
Kikuchi, et al. Expires August 30, 2007 [Page 15]
Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007
6. Security Considerations
Fraud sequence numbers cause measurement into a muddle. This
discussion boils down to the issues of the header protection.
Kikuchi, et al. Expires August 30, 2007 [Page 16]
Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007
Appendix A. Acknowledgements
The authors would like to thank for helpful discussions in TEReCo
research project: Traffic Engineering for Regional Communities,
Japan.
Kikuchi, et al. Expires August 30, 2007 [Page 17]
Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007
7. Normative References
[1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for
Describing Simple Network Management Protocol (SNMP) Management
Frameworks", STD 62, RFC 3411, December 2002.
[2] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[3] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000.
[4] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[5] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge
(PWE3) Architecture", RFC 3985, March 2005.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[7] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[8] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
September 1981.
Kikuchi, et al. Expires August 30, 2007 [Page 18]
Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007
Authors' Addresses
KIKUCHI Yutaka
Kochi University of Technology
306B Research Collaboration Center
185 Miyanokuchi, Tosayamada-cho
Kami-shi, Kochi 782-0003
JP
Email: yu@kikuken.org
MATSUSHIMA Satoru
Softbank Telecom Corp.
NAGAMI Ken'ichi
Intec Netcore Inc.
UDA Satoshi
Japan Advanced Institute of Science and Technology, Hokuriku
OGASHIWA Nobuo
Network Oriented Software Inc.
Kikuchi, et al. Expires August 30, 2007 [Page 19]
Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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 CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Kikuchi, et al. Expires August 30, 2007 [Page 20]