idnits 2.17.1 draft-yin-tsvwg-ipflow-pathtrace-ps-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3811 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-ietf-intarea-flow-label-balancing-02 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Y. Yin 3 Internet-Draft S. Jiang 4 Intended status: Informational G. Yan 5 Expires: April 24, 2014 Huawei Technologies Co., Ltd 6 October 21, 2013 8 IP Flow Path Trace Requirements 9 draft-yin-tsvwg-ipflow-pathtrace-ps-01 11 Abstract 13 This document describes the requirements of IP flow path trace. 14 Network administrators need to get the real IP flow path information, 15 of which a specific IP flow goes through heterogeneous network 16 environments. It is also desired for more information relevant to 17 the IP flow path. Based on the information, network administrators 18 can locate possible faults of the network quickly or optimize network 19 resource for better network performance. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 24, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 57 3. Function Requirement for a new IP Flow Path Trace Mechanism . 4 58 3.1. Requirement for path trace across heterogeneous network 59 environments . . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. IP flow based path trace requirements . . . . . . . . . . 4 61 3.3. Required information relevant to path . . . . . . . . . . 5 62 3.4. Security requirements . . . . . . . . . . . . . . . . . . 6 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 66 7. Informative References . . . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 At present, the Internet Service Providers (ISPs) provides a wide 72 variety of services, such as Internet access, lease line, mobile, 73 Next Generation Network (NGN), Virtual Private Network (VPN), etc. 74 Different service has different quality requirements and the ISPs 75 make the Service Level Agreement (SLA) contracts with customers for 76 each service. So when service failure or decline in the quality of 77 service happens, the service provider's network administrator must 78 locate reasons in the shortest time. 80 The current ISP networks may actually be constructed by heterogeneous 81 network technologies, such as native IP, Multi-Protocol Label 82 Switching (MPLS, [RFC3031]), Pseudo-Wire Emulation Edge to Edge 83 (PWE3, [RFC3985]), Virtual Private Lan Service (VPLS, [RFC4762]), 84 Layer 2 VPN (L2VPN, [RFC4664]), Layer 3 VPN (L3VPN, [RFC4364]), 85 tunnels (such as IPinIP [RFC1853], Generic Packet Tunneling - GRE 86 [RFC2473], etc.), translation, etc. The above mentioned IP services 87 may be delivered across these heterogeneous network environments. 89 To locate the network fault quickly, IETF has defined the 90 corresponding ping and trace functions for each network technology, 91 independently. They are IP ping/trace using Internet Control Message 92 Protocol (ICMP) [RFC0792], LSP ping/trace [RFC4379], PW ping/trace, 93 [RFC5085], [RFC6073], etc. 95 However, none of these technologies are able to gather the trace 96 information of all these heterogeneous network environments. 98 Although trace packets, such as ICMP packets, can traverse these 99 heterogeneous network environments, it does not record information 100 regarding to these heterogeneous intermediate devices at all. Giving 101 the fact, that many of current packets would transmit more than one 102 network environments, it is still difficult trace the complete end- 103 to-end paths. 105 Another issue of these ping/trace functions is path replicability. 106 Most of these current ping/trace mechanisms are based on the triple 107 of {source IP address, destination IP address, IP protocol number}. 108 However, there are many Link Aggregation (LAG) or Equal-Cost Multi- 109 Path (ECMP) scenarios in current networks; and many of network 110 devices select forwarding interfaces based on the result of hash 111 calculation on the quintuple {source IP address, destination IP 112 address, source port number, destination port number, IP protocol 113 number}. There are other load balancing algorithm, such as 114 [I-D.ietf-intarea-flow-label-balancing][], which based on the triple 115 of {source IP address, destination IP address, flow label} in IPv6. 116 Therefore, the path traced by these ping/trace mechanisms may not be 117 replicable by the IP flows at all. In other word, it is common that 118 the real IP flows go through different paths from the result these 119 ping/trace functions. 121 Furthermore, these current ping/trace mechanisms only provide very 122 simple information of path, mainly the addresses of intermediate 123 nodes only. It is far from sufficient information to determine the 124 network fault and make dynamic adjustment based on it. More 125 information, such as link bandwidth, link congestion, etc., is 126 desired if a better path trace mechanism was going to be designed. 128 With the above mentioned issues of current ping/trace mechanisms, 129 this document describes requirements for a new path trace mechanism. 130 If all these requirements were met, network administrators should be 131 able to easily get the real path information which a specific IP 132 service flow goes through in the heterogeneous network environments, 133 and also can get many more information regarding to intermediate 134 devices and links. Based on the information, network administrators 135 can locate the possible faults of the network quickly and may 136 optimize network resources better to provide better network 137 performance for their customers. . 139 2. Conventions Used in This Document 140 L2VPN Layer-2 Virtual Private Networks 141 L3VPN Layer-3 Virtual Private Networks 142 VRF Virtual Routing and Forwarding 143 LAG Link Aggregation 144 ECMP Equal-Cost Multi-Path 146 3. Function Requirement for a new IP Flow Path Trace Mechanism 148 3.1. Requirement for path trace across heterogeneous network 149 environments 151 A new IP flow path trace mechanism should be able to traverse 152 heterogeneous network environments and gather the path information of 153 intermediate devices and links. The heterogeneous network 154 environments include native IPv4, native IPv6, MPLS, PWE3, VPLS, 155 L2VPN, L3VPN, tunnels, translation, etc. 157 The new IP flow path trace mechanism should trace an end-to-end path 158 or paths, no matter what intermediate network environment may go 159 through. It should gather the information, described in Section 3.3, 160 and return them to the initiating node, which is normally the source 161 of the end-to-end path. 163 The trace function may be trigger by a remote network manage device 164 through a management protocol and the trace result may be 165 automatically report back to this remote network manage device. 166 However, it is independent from the requirements of the IP flow path 167 trace mechanism. 169 3.2. IP flow based path trace requirements 171 Many IP services are managed based on IP flow. Between two giving 172 nodes, there may be more than one IP flows and each IP flow may take 173 different path, because the triple {source IP address, destination IP 174 address, IP protocol number} are not sufficient to decide the path. 176 One of the purposes of the required new IP flow path trace mechanism 177 is to trace the real path, which a specific IP service goes through. 178 This would enable the network administrator to manage the network 179 resource on this specific path in order to provide the best 180 performance. 182 Therefore, the new required path trace requirements should be IP flow 183 based. With a giving IP flow information, which is identified by the 184 quintuple {source IP address, destination IP address, source port 185 number, destination port number, IP protocol number} or triple 186 {source IP address, destination IP address, flow label} in IPv6, the 187 new IP flow path trace mechanism should trace its end-to-end path or 188 all possible paths. 190 3.3. Required information relevant to path 192 This section describes the information is desired when a new IP flow 193 path trace mechanism is designed. 195 o Intermediate node information: the identification information of 196 each node which the specific IP flow goes through in the network. 197 The information may be IP address, Router ID or MPLS LSR ID of 198 each node. 200 o Incoming interface and outgoing interface information: the 201 incoming interface information and outgoing interface information 202 of each node which the specific IP flow goes through in the 203 network. The information must include the interface's IP address 204 and may include interface name information. 206 o MPLS label information: the MPLS forwarding label information if 207 the flow goes through MPLS network. The information should 208 include the incoming label and the outgoing label information of 209 the LSP. If VRF or PW are used to bear the IP flow, the 210 information should include the incoming label and the outgoing 211 label information for the VRF and PW. 213 o Link bandwidth information: the link bandwidth information of the 214 incoming interface and outgoing interface of each node which the 215 IP flow goes through in the network. The information should 216 include the total bandwidth and the current bandwidth usage ratio. 218 o Link congestion information: the link congestion information of 219 the incoming interface and outgoing interface of each node which 220 the IP flow goes through in the network. The information should 221 include the indication of congestion or not, further, usage 222 information of the Quality of Service (QoS) queue which IP flow 223 belongs to. 225 o LAG&ECMP information: if outgoing interface is LAG or exist ECMP, 226 the system must be able to accurately determine the load balance 227 forwarding choice of the real IP, and also should get the LAG or 228 ECMP number information. 230 o Tunnel information: the information whether the IP Flow is 231 tunneled and the information regarding to the tunnel. It may 232 include the intermediate devices the tunnel transmits over. 234 o Translation information: the information how the IP flow has been 235 translated by a translation intermediate devices. It should 236 include the mapping information from original address and port to 237 translated address and port. 239 o More information: more path trace information may be extended in 240 the future so that more information relevant to IP flow path can 241 be gathered. 243 3.4. Security requirements 245 o Anti-DDOS (Distributed Denial of Service) 246 An attacker can launch a number of tracing processes to the 247 network nodes, resulting in DDOS attacks. So the network node 248 should implement flow control for the messages of the new tracing 249 function to avoid the attack. 251 o Prevention of Network Information Spying Attack 252 The tracing function may enable an attacker to collect the 253 information of the network, including topology, bandwidth, usage 254 rate, etc. There must mechanisms to prevent such a threat and 255 system information leak. 257 4. Security Considerations 259 The Section 3.4 presents the security consideration/requirements for 260 a solution that design to meet the IP flow path trace requirements. 262 5. IANA Considerations 264 This draft does not request any IANA action. 266 6. Acknowledgements 268 The authors wish to acknowledge the important contributions of 269 Zhenbin Li and Mach Chen. 271 This document was produced using the xml2rfc tool [RFC2629]. 273 7. Informative References 275 [I-D.ietf-intarea-flow-label-balancing] 276 Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6 277 Flow Label for Server Load Balancing", draft-ietf-intarea- 278 flow-label-balancing-02 (work in progress), October 2013. 280 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 281 RFC 792, September 1981. 283 [RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. 285 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 286 IPv6 Specification", RFC 2473, December 1998. 288 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 289 June 1999. 291 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 292 Label Switching Architecture", RFC 3031, January 2001. 294 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 295 Edge (PWE3) Architecture", RFC 3985, March 2005. 297 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 298 Networks (VPNs)", RFC 4364, February 2006. 300 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 301 Label Switched (MPLS) Data Plane Failures", RFC 4379, 302 February 2006. 304 [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 305 Private Networks (L2VPNs)", RFC 4664, September 2006. 307 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 308 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 309 RFC 4762, January 2007. 311 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 312 Connectivity Verification (VCCV): A Control Channel for 313 Pseudowires", RFC 5085, December 2007. 315 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 316 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 318 Authors' Addresses 320 Yuanbin Yin 321 Huawei Technologies Co., Ltd 322 Q15, Huawei Campus, No.156 Beiqing Road 323 Hai-Dian District, Beijing, 100095 324 P.R. China 326 Email: yinyuanbin@huawei.com 327 Sheng Jiang 328 Huawei Technologies Co., Ltd 329 Q14, Huawei Campus, No.156 Beiqing Road 330 Hai-Dian District, Beijing, 100095 331 P.R. China 333 Email: jiangsheng@huawei.com 335 Gang Yan 336 Huawei Technologies Co., Ltd 337 Q15, Huawei Campus, No.156 Beiqing Road 338 Hai-Dian District, Beijing, 100095 339 P.R. China 341 Email: yangang@huawei.com