Network Working Group Y. Kikuchi
Internet-Draft Kochi University of Technology
Intended status: Informational S. Matsushima
Expires: January 8, 2008 Softbank Telecom Corp.
K. Nagami
Intec Netcore Inc.
S. Uda
Japan Advanced Institute of
Science and Technology
July 07, 2007
Quality Measurement Requirements for Tunneling Protocols
draft-kikuchi-tunnel-measure-req-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 January 8, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Kikuchi, et al. Expires January 8, 2008 [Page 1]
Internet-Draft draft-kikuchi-tunnel-measure-req-01.txt July 2007
Abstract
This draft describes the necessary requirements to passively measure
the quality of end-to-end tunnels and to monitor them via applicable
ways. This feature is crucial for Service Providers (SPs),
especially, who provide transports to users using tunnels.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. Service Model . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. General Requirements . . . . . . . . . . . . . . . . . . . . . 6
4.1. Active vs. Passive . . . . . . . . . . . . . . . . . . . . 6
4.2. Quality Evaluation . . . . . . . . . . . . . . . . . . . . 6
4.3. Getting Quality Information . . . . . . . . . . . . . . . 6
4.4. Overhead Consideration . . . . . . . . . . . . . . . . . . 7
5. Requirements with Sequence Numbering . . . . . . . . . . . . . 8
5.1. Indication of Sequence Number . . . . . . . . . . . . . . 8
5.2. Field Length . . . . . . . . . . . . . . . . . . . . . . . 8
6. An Example . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Kikuchi, et al. Expires January 8, 2008 [Page 2]
Internet-Draft draft-kikuchi-tunnel-measure-req-01.txt July 2007
1. Introduction
This draft describes the necessary requirements to passively measure
the quality of end-to-end tunnels passively and to monitor them via
some applicable ways. In this document, tunnel refers to the various
technologies used to provide networks or datalinks virtually.
Examples of tunneling are GRE [2], IP Encapsulation within IP (IPIP)
[3], and Pseudo Wire Emulation Edge-to-Edge (PWE3) [4].
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 the measurement and
monitoring of a network, which is helpful when TSPs want to know the
quality of their traffic through tunnels. Therefore, measurement and
monitoring standards need to be defined.
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 [1].
Kikuchi, et al. Expires January 8, 2008 [Page 3]
Internet-Draft draft-kikuchi-tunnel-measure-req-01.txt July 2007
2. Service Model
Figure 1 shows that TSP X provides a transport between user A and
user B using a tunnel. The users construct 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 ........ *--- 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. Typically users are not able to identify the path details,
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.
In addition, TSPs may be able to provide better transports when the
TSPs have several 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.
TSPs provide simplified and virtual transports by hiding the
underlying layers from the users. The users are able to reduce the
cost of operation and management because they need not maintain the
underlying layers. The reachability maintenance and the quality
management are served as TSPs' communication services.
There must be a Service Level Agreement (SLA) in the contract between
a TSP and its user. The SLA specifies the level that the TSP must
maintain, which is a set of measurable characteristics such as the
total unavailable time in a month, maximum out-of-sequence rates and
some qualities for real time applications.
Kikuchi, et al. Expires January 8, 2008 [Page 4]
Internet-Draft draft-kikuchi-tunnel-measure-req-01.txt July 2007
3. Motivations
TSPs need to know the quality of their tunnels in order to know
whether the tunnels are in a normal state or not. The measured
quality could be an important information to trace down the cause of
the trouble when an applications is not working properly. Without
the necessary information, it is difficult for TSPs to determine
whether problems come from the user, the TSP itself, or the ISPs.
TSPs also need to know the tunnels' quality when they have multiple
tunnels to serve transports. TSPs may be able to serve appropriate
transports to users by selecting better quality tunnels. In
addition, the TSPs may be able to distribute the load of a transport
to different path tunnels.
The tunnel quality measurement is specially needed by TSPs because
they have SLAs to their customers. They must be aware of the status
of underlying tunnels well and must report it as an evidence of
quality for the users. This is the reason why the quality should be
measured not for regular traffic in general but for tunnel traffic.
Kikuchi, et al. Expires January 8, 2008 [Page 5]
Internet-Draft draft-kikuchi-tunnel-measure-req-01.txt July 2007
4. General Requirements
This section describes each requirement necessary to measure end-to-
end tunnel quality for TSPs.
4.1. Active vs. Passive
There are two ways to measure the quality of a 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 traffic packets to measure quality.
From the TSPs point of view, passive measurement SHOULD be supported.
SLAs should refer to the users' packets themselves, therefore, the
measurement should be determined passively rather than actively.
On the other hand, it is not necessary to let the protocol have a
quality measurement function with active measurement. TSPs can
construct the active measurement method independently from the target
protocol. A typical example is PING, which uses Internet Control
Message Protocol (ICMP) [5].
4.2. Quality Evaluation
The standard that define a passive measurement of a tunnelling
protocol MUST contain two items, one is `WHAT' type of quality the
protocol measure, and the other is `HOW' the protocol evaluate the
quality.
It is REQUIRED to detect whether the packets in a tunnel are in-
sequence or out-of-sequence. It SHOULD measure loss, duplication and
reordering. It MAY support to measure delay and/or jitter of
packets' arrivals of a tunnel.
It is RECOMMENDED to disable the measurement function for avoiding
the measurement overhead in case when TSPs need not to measure the
tunnel quality. See also the discussion in the section Section 4.4.
4.3. Getting Quality Information
Tunneling protocols MUST support monitoring when the protocols have
quality measurement functions. The protocol MUST define how to
monitor the result of the quality measurement of tunnels, such as
SNMP [6]. In addition, it MAY modify parameters used in the
measurement mechanisms by TSPs' operators. Moreover, it MAY notify
exceptional situations and illegal operations to the operators.
Kikuchi, et al. Expires January 8, 2008 [Page 6]
Internet-Draft draft-kikuchi-tunnel-measure-req-01.txt July 2007
4.4. Overhead Consideration
Protocol designers SHOULD take into account the computing and space
costs of the implementations where the standard defines the
measurement and monitoring. This includes overhead of traffic
transmission, which may reflect the cost of equipment introductions
and operational expenses. The designers SHOULD not adopt non-
scalable mechanisms and SHOULD pay particular attention to resource
consumption sensitive protocols such as mobile protocols.
The types of overheads are as follows.
o the space of additional information in protocol header,
o the time of sending and receiving the information above, and
o the computing resources for quality measurement implemented in
routers.
We should adopt a simplified determination in some cases when both a
precise complex determination and a simpler one exist. For example,
when we do not need a precise state but rather an approximation of
the degree of the difference from the normal operation.
Kikuchi, et al. Expires January 8, 2008 [Page 7]
Internet-Draft draft-kikuchi-tunnel-measure-req-01.txt July 2007
5. Requirements with Sequence Numbering
Some tunnelling protocols have sequence number fields in the header.
It is easy for the protocols with sequence numbers to introduce some
of those functions above by watching the continuity. A simple method
is proposed in [7]. In this section, we describes the requirements
for such the protocols.
5.1. Indication of Sequence Number
The protocol MUST indicate whether sequence numbering is enabled or
not.
There are two ways to indicate whether the sequence numbers are
enabled or not. One is to prepare an indication field in the header
independent from the sequence number field.
The other is to indicate a special sequence number, typically 0,
meaning disabled. In this case, the measurement process needs
additional steps on wrapping sequence number overflow because the
sequence number will skip 0 that does not seem continuous even if the
tunnel packets are still in-sequence.
5.2. Field Length
The length of sequence number field SHOULD be long enough according
to the transmission speed. Otherwise, the period of a lap of the
sequence number becomes too short and the reliability of the
measurement decreases.
For example, the algorithm may determine packets loss as reordering,
when there is a set of burst packets loss in case of the path change.
It is necessary to determine whether a burst packet loss occurred or
if it was simply the 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 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 packets. Thus, if an insufficiently long
field creates overhead for protocols that are sensitive to resource
consumption. The sequence number field length should be considered
as a tradeoff between bandwidth efficiency and quality assurance.
Kikuchi, et al. Expires January 8, 2008 [Page 8]
Internet-Draft draft-kikuchi-tunnel-measure-req-01.txt July 2007
6. An Example
In this section, we discuss about an existing protocol to apply the
requirement above. In an extreme case, IPIP does not have any extra
field on encapsulation, therefore it is difficult to measure traffics
passively. However many tunnelling protocols have some information
in their headers such as GRE [8].
If a protocol has a sequence number field, it is easy to determine
the tunnel is in-sequence or not. Moreover, it can recognize the
reason such as loss, duplication and reordering. Because GRE has
sequence numbers in their headers, they are possible to measure the
qualities.
If there is a timestamp in the header of a tunnelling protocol, even
the timestamps might be synchronized to a reference clock, it can
measure delay and jitter. For example, because GRE does not have
such a feature, neither delay nor jitter can be measured.
The GRE standard defines the sequence number field only for egress
internal processing, which allows to discard out-of-sequence packets
and/or to align the sequence with buffering. It should define how to
get the quality information because there is no mechanism to inform
the upper layer.
About the overheads of the quality measurement of GRE tunnels,
firstly it needs 32bits sequence number field in the GRE header.
Secondly at least 4 32bits registers per tunnel are required in the
GRE egress. The computing cost are in O(n) if the algorithm
illustrated in [7] is adapted where n is the number of tunnels.
Kikuchi, et al. Expires January 8, 2008 [Page 9]
Internet-Draft draft-kikuchi-tunnel-measure-req-01.txt July 2007
7. Security Considerations
Fraud sequence numbers and time stamps cause the measurement process
to become disorganized. This discussion boils down to the issues of
the header protection.
Kikuchi, et al. Expires January 8, 2008 [Page 10]
Internet-Draft draft-kikuchi-tunnel-measure-req-01.txt July 2007
Appendix A. Acknowledgements
The authors would like to thank for helpful discussions in TEReCo
research project sponsored in part by the ministry of internal
affairs and communications Japan (SCOPE 072309007).
Kikuchi, et al. Expires January 8, 2008 [Page 11]
Internet-Draft draft-kikuchi-tunnel-measure-req-01.txt July 2007
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[2] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[3] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[4] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge
(PWE3) Architecture", RFC 3985, March 2005.
[5] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
September 1981.
[6] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for
Describing Simple Network Management Protocol (SNMP) Management
Frameworks", STD 62, RFC 3411, December 2002.
[7] Kikuchi, Y., "One-way Passive Measurement of End-to-End
Quality", draft-kikuchi-passive-measure-00 (work in progress),
July 2007.
[8] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000.
Kikuchi, et al. Expires January 8, 2008 [Page 12]
Internet-Draft draft-kikuchi-tunnel-measure-req-01.txt July 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.
1-9-1 Higashi-Shinbashi
Minato-ku, Tokyo
JP
Email: satoru@ft.solteria.net
NAGAMI Ken'ichi
Intec Netcore Inc.
1-3-3 Shin-suna
Koto-ku, Tokyo
JP
Phone: +81-3-5565-5069
Email: nagami@inetcore.com
UDA Satoshi
Japan Advanced Institute of Science and Technology
Email: zin@jaist.ac.jp
Kikuchi, et al. Expires January 8, 2008 [Page 13]
Internet-Draft draft-kikuchi-tunnel-measure-req-01.txt July 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 January 8, 2008 [Page 14]