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]