Operations Area Y. Yin
Internet Draft S. Jiang
Intended status: Informational G. Yan
Expires: January 16, 2014 Huawei Technologies
July 15, 2013
IP Flow Path Trace Requirements
draft-yin-tsvwg-ipflow-pathtrace-ps-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 16, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Yin, et al. Expires January 16 2014 [Page 1]
Internet-Draft draft-yin-tsvwg-ipflow-pathtrace-ps July 2013
Abstract
This document describes the requirements of IP flow path trace.
Network administrators need to get the real IP flow path information,
of which a specific IP flow goes through heterogeneous network
environments. It is also desired for more information relevant to
the IP flow path. Based on the information, network administrators
can locate possible faults of the network quickly or optimize
network resource for better network performance.
Table of Contents
Abstract ....................................................... 2
1. Introduction ................................................ 3
2. Conventions Used in This Document ............................ 4
3. Function Requirement for a new IP Flow Path Trace Mechanism ... 4
3.1. Requirement for path trace across heterogeneous network
environments ................................................ 4
3.2. IP flow based path trace requirements ................... 5
3.3. Required information relevant to path ................... 5
3.4. Security requirements ................................... 6
4. Security Considerations ...................................... 7
5. IANA Considerations ......................................... 7
6. Acknowledgments ............................................. 7
7. References .................................................. 7
7.1. Informative References .................................. 7
Author's Addresses ............................................. 8
Yin, et al. Expires January 16, 2014 [Page 2]
Internet-Draft draft-yin-tsvwg-ipflow-pathtrace-ps July 2013
1. Introduction
At present, the Internet Service Providers (ISPs) provides a wide
variety of services, such as internet, lease line, mobile, Next
Generation Network (NGN), Virtual Private Network (VPN), etc.
Different service has different quality requirements and the ISPs
make the Service Level Agreement (SLA) contracts with customers for
each service. So when service failure or decline in the quality of
service happens, the service provider's network administrator must
locate reasons in the shortest time.
The current ISP networks may actually be constructed by
heterogeneous network technologies, such as native IP, Multi-
Protocol Label Switching (MPLS, [RFC3031]), Pseudo-Wire Emulation
Edge to Edge (PWE3, [RFC3985]), Virtual Private Lan Service (VPLS,
[RFC4762]), Layer 2 VPN (L2VPN, [RFC4664]), Layer 3 VPN (L3VPN,
[RFC4364]), tunnels (such as IPinIP [RFC1853], Generic Packet
Tunneling - GRE [RFC2473], etc.), translation, etc. The above
mentioned IP services may be delivered across these heterogeneous
network environments.
To locate the network fault quickly, IETF has defined the
corresponding ping and trace functions for each network technology,
independently. They are IP ping/trace using Internet Control Message
Protocol (ICMP) [RFC792], LSP ping/trace [RFC4379], PW ping/trace,
[RFC5085], [RFC6073], etc.
However, none of these technologies are able to gather the trace
information of all these heterogeneous network environments.
Although trace packets, such as ICMP packets, can traverse these
heterogeneous network environments, it does not record information
regarding to these heterogeneous intermediate devices at all. Giving
the fact, that many of current packets would transmit more than one
network environments, it is still difficult trace the complete end-
to-end paths.
Another issue of these ping/trace functions is path replicability.
Most of these current ping/trace mechanisms are based on the triple
of {source IP address, destination IP address, IP protocol number}.
However, there are many Link Aggregation (LAG) or Equal-Cost Multi-
Path (ECMP) scenarios in current networks; and many of network
devices select forwarding interfaces based on the result of hash
calculation on the quintuple {source IP address, destination IP
address, source port number, destination port number, IP protocol
number}. There are other load balancing algorithm, such as
[I-D.ietf-intarea-flow-label-balancing], which based on the triple
Yin, et al. Expires January 16, 2014 [Page 3]
Internet-Draft draft-yin-tsvwg-ipflow-pathtrace-ps July 2013
of {source IP address, destination IP address, flow label} in IPv6.
Therefore, the path traced by these ping/trace mechanisms may not be
replicable by the IP flows at all. In other word, it is common that
the real IP flows go through different paths from the result these
ping/trace functions.
Furthermore, these current ping/trace mechanisms only provide very
simple information of path, mainly the addresses of intermediate
nodes only. It is far from sufficient information to determine the
network fault and make dynamic adjustment based on it. More
information, such as link bandwidth, link congestion, etc., is
desired if a better path trace mechanism was going to be designed.
With the above mentioned issues of current ping/trace mechanisms,
this document describes requirements for a new path trace mechanism.
If all these requirements were met, network administrators should be
able to easily get the real path information which a specific IP
service flow goes through in the heterogeneous network environments,
and also can get many more information regarding to intermediate
devices and links. Based on the information, network administrators
can locate the possible faults of the network quickly and may
optimize network resources better to provide better network
performance for their customers.
2. Conventions Used in This Document
L2VPN Layer-2 Virtual Private Networks
L3VPN Layer-3 Virtual Private Networks
VRF Virtual Routing and Forwarding
LAG Link Aggregation
ECMP Equal-Cost Multi-Path
3. Function Requirement for a new IP Flow Path Trace Mechanism
3.1. Requirement for path trace across heterogeneous network
environments
A new IP flow path trace mechanism should be able to traverse
heterogeneous network environments and gather the path information
of intermediate devices and links. The heterogeneous network
environments include native IPv4, native IPv6, MPLS, PWE3, VPLS,
L2VPN, L3VPN, tunnels, translation, etc.
Yin, et al. Expires January 16, 2014 [Page 4]
Internet-Draft draft-yin-tsvwg-ipflow-pathtrace-ps July 2013
The new IP flow path trace mechanism should trace an end-to-end path
or paths, no matter what intermediate network environment may go
through. It should gather the information, described in section 3.3,
and return them to the initiating node, which is normally the source
of the end-to-end path.
The trace function may be trigger by a remote network manage device
through a management protocol and the trace result may be
automatically report back to this remote network manage device.
However, it is independent from the requirements of the IP flow path
trace mechanism.
3.2. IP flow based path trace requirements
Many IP services are managed based on IP flow. Between two giving
nodes, there may be more than one IP flows and each IP flow may take
different path, because the triple {source IP address, destination
IP address, IP protocol number} are not sufficient to decide the
path.
One of the purposes of the required new IP flow path trace mechanism
is to trace the real path, which a specific IP service goes through.
This would enable the network administrator to manage the network
resource on this specific path in order to provide the best
performance.
Therefore, the new required path trace requirements should be IP
flow based. With a giving IP flow information, which is identified
by the quintuple {source IP address, destination IP address, source
port number, destination port number, IP protocol number} or triple
{source IP address, destination IP address, flow label} in IPv6, the
new IP flow path trace mechanism should trace its end-to-end path or
all possible paths.
3.3. Required information relevant to path
This section describes the information is desired when a new IP flow
path trace mechanism is designed.
Intermediate node information: the identification information of each
node which the specific IP flow goes through in the network. The
information may be IP address, Router ID or MPLS LSR ID of each
node.
Incoming interface and outgoing interface information: the incoming
interface information and outgoing interface information of each
node which the specific IP flow goes through in the network. The
Yin, et al. Expires January 16, 2014 [Page 5]
Internet-Draft draft-yin-tsvwg-ipflow-pathtrace-ps July 2013
information must include the interface's IP address and may
include interface name information.
MPLS label information: the MPLS forwarding label information if the
flow goes through MPLS network. The information should include the
incoming label and the outgoing label information of the LSP. If
VRF or PW are used to bear the IP flow, the information should
include the incoming label and the outgoing label information for
the VRF and PW.
Link bandwidth information: the link bandwidth information of the
incoming interface and outgoing interface of each node which the
IP flow goes through in the network. The information should
include the total bandwidth and the current bandwidth usage ratio.
Link congestion information: the link congestion information of the
incoming interface and outgoing interface of each node which the
IP flow goes through in the network. The information should
include the indication of congestion or not, further, usage
information of the Quality of Service (QoS) queue which IP flow
belongs to.
LAG&ECMP information: if outgoing interface is LAG or exist ECMP, the
system must be able to accurately determine the load balance
forwarding choice of the real IP, and also should get the LAG or
ECMP number information.
Tunnel information: the information whether the IP Flow is tunneled
and the information regarding to the tunnel. It may include the
intermediate devices the tunnel transmits over.
Translation information: the information how the IP flow has been
translated by a translation intermediate devices. It should
include the mapping information from original address and port to
translated address and port.
More information: more path trace information may be extended in the
future so that more information relevant to IP flow path can be
gathered.
3.4. Security requirements
Anti-DDOS (Distributed Denial of Service)
An attacker can launch a number of tracing processes to the
network nodes, resulting in DDOS attacks. So the network node
Yin, et al. Expires January 16, 2014 [Page 6]
Internet-Draft draft-yin-tsvwg-ipflow-pathtrace-ps July 2013
should implement flow control for the messages of the new tracing
function to avoid the attack.
Prevention of Network Information Spying Attack
The tracing function may enable an attacker to collect the
information of the network, including topology, bandwidth, usage
rate, etc. There must mechanisms to prevent such a threat and
system information leak.
4. Security Considerations
The Section 3.4 presents the security consideration/requirements for
a solution that design to meet the IP flow path trace requirements.
5. IANA Considerations
This draft does not request any IANA action.
6. Acknowledgments
The authors wish to acknowledge the important contributions of
Zhenbin Li and Mach Chen.
7. References
7.1. Informative References
[RFC792] Postel, J., "Internet Control Message Protocol", RFC 792,
September 1981.
[RFC1853] RFC 1853 ASCII, PDF IP in IP Tunneling W. Simpson October
1995.
[RFC2473] RFC 2473 ASCII, PDF Generic Packet Tunneling in IPv6
Specification A. Conta, S. Deering December 1998.
[RFC3031] E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3985] S. Bryant, and P. Pate "Pseudo Wire Emulation Edge-to-Edge
(PWE3) Architecture", RFC 3985. March 2005.
[RFC4364] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
Yin, et al. Expires January 16, 2014 [Page 7]
Internet-Draft draft-yin-tsvwg-ipflow-pathtrace-ps July 2013
[RFC4379] K. Kompella, G. Swallow, "Detecting Multi-Protocol Label
Switched (MPLS) Data Plane Failures", RFC 4379, February
2006.
[RFC4664] L. Andersson, Ed. and E. Rosen, Ed., "Framework for Layer
2 Virtual Private Networks (L2VPNs)", RFC 4664, September
2006.
[RFC4762] M. Lasserre, Ed. and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling ", RFC 4762, January 2007.
[RFC5085] T. Nadeau, Ed., C. Pignataro, Ed., "Pseudowire Virtual
Circuit Connectivity Verification (VCCV): A Control
Channel for Pseudowires", RFC 5085, December 2007.
[RFC6073] L. Martini, C. Metz, T. Nadeau, M. Bocci,M. Aissaoui,
"Segmented Pseudowire", RFC 6073, January 2011
[I-D.ietf-intarea-flow-label-balancing]
B. Carpenter, S. Jiang, and W. Tarreau, "Using the IPv6
Flow Label for Server Load Balancing", working in progress,
May 2013.
Author's Addresses
Yuanbin Yin
Huawei Technologies Co., Ltd
Huawei Q15 Building, No.156 Beiqing Rd.,
Hai-Dian District 100095
Email: yinyuanbin@huawei.com
Sheng Jiang
Huawei Technologies Co., Ltd
Huawei Q14 Building, No.156 Beiqing Rd.,
Hai-Dian District 100095
Email: jiangsheng@huawei.com
Gang Yan
Huawei Technologies Co., Ltd
Huawei Q15 Building, No.156 Beiqing Rd.,
Hai-Dian District 100095
Email: yangang@huawei.com
Yin, et al. Expires January 16, 2014 [Page 8]