Internet Engineering Task Force Y. Yin Internet-Draft S. Jiang Intended status: Informational G. Yan Expires: April 24, 2014 Huawei Technologies Co., Ltd October 21, 2013 IP Flow Path Trace Requirements draft-yin-tsvwg-ipflow-pathtrace-ps-01 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. 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 April 24, 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 Yin, et al. Expires April 24, 2014 [Page 1] Internet-Draft Flow Path Trace Requirements October 2013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 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 . . . . . . . . . . 4 3.3. Required information relevant to path . . . . . . . . . . 5 3.4. Security requirements . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. Informative References . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction At present, the Internet Service Providers (ISPs) provides a wide variety of services, such as Internet access, 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) [RFC0792], 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. Yin, et al. Expires April 24, 2014 [Page 2] Internet-Draft Flow Path Trace Requirements October 2013 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 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 Yin, et al. Expires April 24, 2014 [Page 3] Internet-Draft Flow Path Trace Requirements October 2013 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. 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 Yin, et al. Expires April 24, 2014 [Page 4] Internet-Draft Flow Path Trace Requirements October 2013 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. o 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. o 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 information must include the interface's IP address and may include interface name information. o 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. o 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. o 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. o 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. o 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. Yin, et al. Expires April 24, 2014 [Page 5] Internet-Draft Flow Path Trace Requirements October 2013 o 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. o 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 o 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 should implement flow control for the messages of the new tracing function to avoid the attack. o 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. Acknowledgements The authors wish to acknowledge the important contributions of Zhenbin Li and Mach Chen. This document was produced using the xml2rfc tool [RFC2629]. 7. Informative References [I-D.ietf-intarea-flow-label-balancing] Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6 Flow Label for Server Load Balancing", draft-ietf-intarea- flow-label-balancing-02 (work in progress), October 2013. [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. Yin, et al. Expires April 24, 2014 [Page 6] Internet-Draft Flow Path Trace Requirements October 2013 [RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture", RFC 3985, March 2005. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006. [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007. [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007. [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. Authors' Addresses Yuanbin Yin Huawei Technologies Co., Ltd Q15, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: yinyuanbin@huawei.com Yin, et al. Expires April 24, 2014 [Page 7] Internet-Draft Flow Path Trace Requirements October 2013 Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: jiangsheng@huawei.com Gang Yan Huawei Technologies Co., Ltd Q15, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: yangang@huawei.com Yin, et al. Expires April 24, 2014 [Page 8]