TSVWG L. Zhu Internet-Draft Huawei Technologies Intended status: Informational H. Zhang Expires: April 18, 2013 X. Gong BUPT October 15, 2012 Tunnel Congestion Exposure draft-zhang-tsvwg-tunnel-congestion-exposure-00 Abstract At present, tunneling technology has been widely applied in VPN, mobile communication network, IPv6 over IPv4, Mobile IP, multi-point delivery, and other fields. In the E2E link, there may already have been an effective congestion control mechanism, but we SHOULD also do traffic management in the tunnel to improve the performance of the entire network. Because of the particularity of the scenario of the tunnel, the existing E2E traffic management mechanism cannot be directly be deployed (e.g. VPN, IPv6 over IPv4 etc). In these cases, this document focuses on how to expose the congestion while the feedback mechanism is left for later study. This document describes the problem of identifying congestion in a tunnel segment of an end-to-end flow. A basic tunnel congestion exposure model is then described, followed by three example scenarios which use the basic model to derive tunnel congestion. Finally, a general solution that can be applied to IP-in-IP tunnels is described. 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 18, 2013. Copyright Notice Zhu, et al. Expires April 18, 2013 [Page 1] Internet-Draft Tunnel Congestion Exposure October 2012 Copyright (c) 2012 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Zhu, et al. Expires April 18, 2013 [Page 2] Internet-Draft Tunnel Congestion Exposure October 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Document Overview . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 4. Basic Model . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 10 5.1. VPN Scenario . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Mobile Scenario . . . . . . . . . . . . . . . . . . . . . 11 5.3. IPv6 over IPv4 Scenario . . . . . . . . . . . . . . . . . 12 6. The General Solution . . . . . . . . . . . . . . . . . . . . . 13 6.1. Statement of Requirements . . . . . . . . . . . . . . . . 13 6.2. The General Procedure . . . . . . . . . . . . . . . . . . 14 7. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Normative Reference . . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Zhu, et al. Expires April 18, 2013 [Page 3] Internet-Draft Tunnel Congestion Exposure October 2012 1. Introduction This document mainly describes four issues. Firstly, this document describes the problem concerning congestion in the tunnel. At present, tunneling technology has been widely applied in, VPN, mobile communication network, IPv6 over IPv4, Mobile IP, multi-point delivery, and other fields. In this case, relying on end-to-end congestion management alone to deal with the congestion problem in the tunnel brings many drawbacks and seriously affects the performance of the entire network. Secondly, this document proposes a basic tunnel congestion exposure model. In the model, the ingress and the egress of the tunnel are two dominant nodes which have the ability to handle admission, flow control and policy control. In the basic model, in order to achieve a real-time understanding of the congestion status of the tunnel, the amount of tunnel congestions is fed back to the ingress of the tunnel using the tunnel encapsulation protocol signals. It's helpful for the ingress to achieve a real-time congestion status of the entire tunnel, and it also provides the possibility of using policy or flow control mechanisms to further reduce congestion in the local tunnel portion. Thirdly, this document introduces three example scenarios where the proposed basic model can be applied. Finally, this document presents a general solution. The general solution includes a statement of requirements and general procedures. 1.1. Document Overview The main section in this document is the basic model described in chapter 4. A tunnel congestion exposure model is presented in the chapter. The model is relatively simple, but it can be used to sufficiently expose the tunnel congestion. Chapter 3 gives the general process of tunnel transmission and presents two major problems related to the tunnel congestion. Three scenarios are given in Chapter 5 that use the basic model. Chapter 6 introduces a general solution. Chapter 7 states a further study plan. 2. Conventions and Terminology Zhu, et al. Expires April 18, 2013 [Page 4] Internet-Draft Tunnel Congestion Exposure October 2012 2.1. Conventions 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 [RFC2119]. Table 1 recaps the names of the ECN codepoints [RFC3168]. +------------------+----------------+---------------------------+ | Binary codepoint | Codepoint name | Meaning | +------------------+----------------+---------------------------+ | 00 | Not-ECT | Not ECN-capable transport | | 01 | ECT(1) | ECN-capable transport | | 10 | ECT(0) | ECN-capable transport | | 11 | CE | Congestion experienced | +------------------+----------------+---------------------------+ Table 1: Recap of Codepoints of the ECN Field [RFC3168] 2.2. Terminology Further terminology used within this document: o Tunnel: A tunnel is just a special type of connection across a network. o Encapsulation: The process of adding control information as it passes through the layered model. o Encapsulator: The tunnel endpoint function that adds an outer IP header to tunnel a packet, the encapsulator is considered as the "ingress" of the tunnel. o Decapsulator: The tunnel endpoint function that removes an outer IP header from a tunnelled packet, the decapsulator is considered as the "egress" of the tunnel. o Outer header: The header added to encapsulate a tunneled packet. o Inner header: The header encapsulated by the outer header. o E2E: End to End o VPN: Virtual Private Network is a technology for using the Internet or another intermediate network to connect computers to isolated remote computer networks that would otherwise be inaccessible. Zhu, et al. Expires April 18, 2013 [Page 5] Internet-Draft Tunnel Congestion Exposure October 2012 3. Problem Statement Tunneling technology is one way to transmit data between different networks by using the Internet infrastructure. The tunnel can transmit the frames or packets of different protocols as its payload. The frames or packets are re-encapsulated using new headers of the tunneling protocol. The new header provides the routing information so that the encapsulated payload data can be transmitted through the public Internet. As soon as being transmitted to the endpoint of network (egress), the data will be de-encapsulated and forwarded to its final destination. In the IP network, there are three typical encapsulation protocols: IP Encapsulation within IP [RFC2003]; Minimal Encapsulation within IP [RFC2004]; Generic Routing Encapsulation (GRE) [RFC1701]. As an example, the format of GRE encapsulation is shown in Figure 1. +------------------------+ | IP | | (payload Protocol) | +------------------------+ | GRE | |(Encapsulation Protocol)| +------------------------+ | IP | | (Transport Protocol) | +------------------------+ Figure 1: GRE encapsulation format At present, tunneling technology is widely used in computer networks. It MAY be used to transport IPv4 in IPv6 networks and vice versa during the two protocols coexistence period. In Mobile IP, by introducing tunnels, a mobile node can communicate with its correspondent node using a fixed address (home address) at any time and place. In addition, tunneling technology has also played an important role in virtual private network (VPN), multi-point delivery, and mobile communication networks. We perceive two problems related to congestion and tunneling technology in IP and mobile communication networks. Consider the following situation: data packets need to be transmitted end-to-end over an ECN-enabled transport and part of this includes a tunnel segment. Zhu, et al. Expires April 18, 2013 [Page 6] Internet-Draft Tunnel Congestion Exposure October 2012 The ingress, the egress and the intermediate nodes of the tunnel are ECN-enabled. At the egress of the tunnel, the data packets are de- capsulated, peeled off the transport protocol in outer header, and then the inner packets are forwarded to the destination endpoint. In this case, it is useful to specify the behaviors of the encapsulation and de-capsulation; otherwise the following problems may occur: o The packet congestion inside the tunnel cannot be indicated; o E2E path congestion information may be lost. For these two problems, RFC3168, RFC4301 and RFC6040 have presented some descriptions and specifications to all IP in IP tunnels. The core idea is: o Set the ECN bits as ECT(0)/ECT(1) at the ingress in order to inform the interior router to perform mark operations and indicate congestion events inside the tunnel; o Perform "copy-to-copy" operations at the ingress and egress of the tunnel, so that the congestion information of the arriving packet or inside the tunnel can be forwarded to the final endpoint instead of being lost. In the mobile communication network, end-user IP traffic maybe forwarded over multiple tunnel segments before it reaches the router that handles subscriber policy, charging etc. Congestion over these tunnel segments contribute to the overall congestion experienced E2E. In the tunnel protocol deployment scenarios, we may use other methods, for example, out of-band signaling, to report the congestion information to NE (Network Element) which has the mechanisms to manage congestion based on per user policies or other flow control mechanisms. However, tunnel congestion information should not be overlooked. In the E2E link, there may already have been an effective congestion control mechanism, but we SHOULD also do traffic management in the tunnel to improve the performance of the entire network. Because of the particularity of the scenario of the tunnel, the existing E2E traffic management mechanism cannot be directly be deployed (e.g. VPN, IPv6 over IPv4 etc). In these cases, this document focuses on how to expose the congestion while the feedback mechanism is left for later study. Zhu, et al. Expires April 18, 2013 [Page 7] Internet-Draft Tunnel Congestion Exposure October 2012 The following assumptions are made in this document: o Firstly, both payload and transport protocols are IP in this document, i.e., we consider only IP-in-IP tunnels; o Secondly, the intermediate nodes within the tunnels, for example, the routers are ECN-enabled; o Finally, no changes are made to the ECN mechanism. 4. Basic Model According to the general tunnel transmission process, this section introduces the abstract of the tunnel transmission and outlines a tunnel congestion exposure model as shown in Figure 2: ,-----------. TUNNEL ,-----------. | Ingress |==========================================| Egress | | | | | | ,---------------Congestion-Indication------------------. | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ,-----------. '\ | | | | | |____________| |____________| \ | | | | | | Outer Header(IP Layer) Data Flow \ |+----+----+| |+----v----+| | | \||Feedback || ||Collector|| |(Congested)| /|+---------+| |+---------+| | Router |--Outer-CE-Signals--> Meter || | |____________| |____________ / |+---------+| | | | | |/ | | | | `-----------' ' | | | |==========================================| | `-----------' `-----------' Figure 2: Tunnel Congestion Exposure Basic Model This basic model MAY contain the following components: Ingress, Egress, Collector, Feedback and Meter. By and large, the ingress and egress of the tunnel are gateway devices. In terms of the egress, it can calculate the amount of congestion and feed back the congestion information to the ingress. The collector is able to receive the congestion information which is Zhu, et al. Expires April 18, 2013 [Page 8] Internet-Draft Tunnel Congestion Exposure October 2012 fed back from the egress. It MAY also have admission control and flow control functions. General practice can be as follows: At the egress, a module named meter can be added. The module records the outer header CE codepoint packets reaches the egress independently, and MAY need to estimate the congestion level inside the tunnel. In addition, a congestion information feedback module, called feedback, is also needed to be added. The feedback module is used to control the congestion information feedback. The feedback of the congestion information can be done via the extension of the encapsulation protocol of the tunnel. A collector module for receiving the feedback congestion information from the egress SHOULD be added. The collector can be distributed in the ingress or other network elements that have the capability of handling the congestion (such as the PDN-GW in the mobile communication network described in section 5.2). Furthermore, some modules related with the congestion policy process can be added. However, no descriptions concerning this aspect are given in this document for the time being. In this model, the tunnel is an IP-in-IP tunnel. Both the entry and egress of the tunnel are ECN-enabled and the intermediate routers in the tunnel path are also ECN-enabled. +---------------+ +-------------+ | Ingress | | Egress | +-------+-------+ +------+------+ | | | Record the congestion | | | | |<-------------Send Back Congestion---------------+ | | | | Settle the congestion | | | Figure 3: the general process of the congestion feedback Figure 3 demonstrates the general process of the congestion information feedback. The general method to feed back the congestion information is to do Zhu, et al. Expires April 18, 2013 [Page 9] Internet-Draft Tunnel Congestion Exposure October 2012 some extensions to the encapsulation protocol messages. The details of the feedback process may differ in terms of the encapsulation protocols of the tunnel, but the general process is as shown in Figure 3. 5. Example Scenarios This chapter presents three scenarios based on the basic model described in the previous chapter. This chapter focuses on two aspects. On the one hand, it describes the process of tunnel congestion exposure for each scenario, and on the other hand it stresses the significance of congestion exposure. 5.1. VPN Scenario .---. .---. ( ) ( ) / \ / \ ( VPN 1 ) ( VPN 1 ) \ +--+ +--+ / ( |CE| |CE| ) .--+--+ +--+--. \ / \ (--------------------) / \ ( ) / +--+ ( ) +--+ |PE|---( IP Network )---|PE| +--+ ( ) +--+ /| ( ) |\ / | (--------------------) | \ / | | \ .--+--+ |===============================| +--+--. ( |CE| | VPN Tunnel | |CE| ) / +--+ +--+ \ ( VPN 2 ) ( VPN 2 ) \ / \ / ( ) ( ) .---. .---. Figure 4: VPN Scenario Figure 4 is a simplified VPN multi-instance model. A VPN tunnel is established between two PEs. Before creating the VPN tunnel, the routing in the network between two PEs has been configured (e.g., in large networks, the BGP routing protocol is generally used). CEs are Zhu, et al. Expires April 18, 2013 [Page 10] Internet-Draft Tunnel Congestion Exposure October 2012 connected to the networks where the users locate. Both ends of the CE devices are located respectively in the VPN instance 1 (VPN 1) and VPN instance 2 (VPN 2). CE and PE are defined as follows: o CE (Customer Edge): User network edge devices, which have interfaces directly to the SP (Service Provider) networks. A CE can be a switch and can also be a host. Usually, the CE cannot sense the presence of the VPN and it does not need to support the VPN features. o PE (Provider Edge): IP network edge devices, which are connected to CEs directly. In the VPN network, all processing of VPN instances is on the PEs. In this scenario, the VPN Tunnel is the object drawing our attention. The two PEs are the powerful nodes that acting as the entry and egress of the tunnel, receiving and sending back the congestion information. The PEs can also do more operations of the traffic management. The process is almost the same as that of the basic model. 5.2. Mobile Scenario Figure 5 is the scenario in the EPS (Evolved Packet System), where two PMIP tunnels exist, i.e., PMIP tunnel between eNodeB and the S-GW, and between the S-GW and the PDN-GW. In this scenario, we can just expose the congestion information of the backhaul tunnel segment (Note: It is an assumption that core network has extremely low possibility of congestion). With the extensive use of mobile communication network and variable traffic rate per user, backhaul network congestion problems get more unpredictable. If the congestion information in the backhaul network can be exposed, the PDN-GW MAY reuse the exposed congestion information to do flow control, which is helpful to improve the performance of the entire network and enhance the user experience. There are significant differences between this scenario and the VPN scenario. o First of all, the congestion information is reported to PDN-GW rather than the ingress. o Secondly, no congestion feedback exists in the backhaul network in both the uplink and downlink. Zhu, et al. Expires April 18, 2013 [Page 11] Internet-Draft Tunnel Congestion Exposure October 2012 o In addition, the object which is used to reporting the tunnel congestion information (PDN-GW) and the module used to record the congestion information are not in the same tunnel section. \|/ | | +-|------+ +--------+ PMIP +--------+ +--+ | | Tunnel1 | | Tunnel2 | | |UE|--(RAN)--| eNodeB |===========| S-GW |=============| PDN-GW | +--+ | | Backhaul | | Core | | +--------+ +--------+ +--------+ Figure 5: Mobile Scenario In this scenario, the processing in the uplink and downlink SHOULD be distinguished. The general process is as follows: o The egress records the congestion information according to the description in the basic model. o In the uplink direction, the egress is S-GW. Therefore, the S-GW will report congestion information to the PDN-GW using the PMIP messages. o In the down-link direction, the egress is the eNodeB. The eNodeB feeds back the congestion information to the S-GW first using the PMIP messages. Then the S-GW transfers the congestion information to the PDN-GW. 5.3. IPv6 over IPv4 Scenario The tunnel used to connect IPv6 isolated islands in an IPv4 network is called IPv6 over IPv4 tunnel. In the early stage of the transition from the IPv4 Internet to the IPv6 Internet, the IPv4 networks have been well deployed while the IPv6 networks are isolated network islands spread around the world. Using a dedicated line to connect these isolated IPv6 islands is not economical obviously. The usual practice is to use tunneling technology. By using the tunneling technology to create a tunnel in the IPv4 network, the IPv6 islands can be interconnected through the IPv4 networks. This is similar to the deployment of VPNs in the IP networks through the tunneling technology. Zhu, et al. Expires April 18, 2013 [Page 12] Internet-Draft Tunnel Congestion Exposure October 2012 .----. +--------+ ( ) +--------+ | | / IPv4 \ | | |Gateway1| ( Network ) |Gateway2| | | TUNNEL \ / | | +---|----+==============(======)===============+----|---+ | .----. | | | | | | | | | .---. .---. ( ) ( ) / IPv6 \ / IPv6 \ ( Network ) ( Network ) \ / \ / ( ) ( ) .---. .---. Figure 6: IPv6 over IPv4 Scenario In this scenario, the two gateways, namely Gateway1 and Gateway2, perform admission control. They are the endpoints of the connection to the two IPv6 isolated islands and serve as the ingress and egress of the tunnel. It can be seen from above, the specific congestion exposure mechanisms are consistent with the basic model. The congestion information is exposed at the ingress, we can use the congestion information to do a lot of significant things. 6. The General Solution 6.1. Statement of Requirements o All tunnels are IP-in-IP type. o Tunnel path supports the ECN mechanism--that is, the ingress, the egress and intermediate nodes are ECN enabled. o The tunnel is configured to support feedback congestion information. o A powerful device exists in the tunnel which is used for processing the congestion information. Zhu, et al. Expires April 18, 2013 [Page 13] Internet-Draft Tunnel Congestion Exposure October 2012 6.2. The General Procedure o In case of congestion, network element (ingress and egress of the tunnel, intermediate routers etc.) performs marking operations on packets according to AQM algorithm. o The egress of the tunnel calculates congestion information by recording the number of congestion and total package periodically. o The egress of the tunnel feeds back congestion information to the functional traffic management entity (such as: the ingress of the tunnel). In the tunnel, if the transport protocol is UDP, the congestion information is fed back by extending signaling of the encapsulation protocol. In this step, the encapsulation signaling SHOULD be extended. For example, in the IPSec tunnel, the IPSec signaling messages should be extended which are used for sending back the congestion information to the collector module. o Congestion information receiving object (functional entity executing flow management) disposes congestion information when the congestion threshold level is reached. Here, we can define the different congestion levels according to the actual situations or requirements. For the simplest condition, we can divide the congestion conditions into three types: the high congestion, moderate congestion, and low-grade congestion. This process involves things like collecting congestion information, making policy control based on the congestion information and etc. 7. Next Steps At present, this document focuses on how to expose the tunnel congestion to the ingress of the tunnel which has flow control and policy control functions etc. In this document, a basic model for congestion exposure is proposed, a general solution is introduced, and several scenarios for applying the basic model are described. However, no excessive details are given. In the following versions, more details and processes of the tunnel congestion exposure will be introduced. Which type of congestion information and how to use the information will also be discussed. In the near future, more than one document will be used to describe these practices. 8. Security Considerations TBD Zhu, et al. Expires April 18, 2013 [Page 14] Internet-Draft Tunnel Congestion Exposure October 2012 9. IANA Considerations This document includes no request to IANA. 10. Acknowledgments The authors would like to thank Wendong Wang, Li Yuhong and Xirong Que for their technical guidances towards to this draft. The authors would like to thank their colleagues for their sincerely help and comments when drafting this document. 11. References 11.1. Normative Reference [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, November 2010. 11.2. Informative References [3GPP.23.203] 3GPP, "Policy and charging control architecture", 3GPP TS 23.203 10.7.0 , June 2012. [3GPP.23.402] 3GPP, "Architecture enhancements for non-3GPP accesses", 3GPP TS 23.402 V11.3.0 , June 2012. [3GPP.29.274] 3GPP, "Technical Specification Group Core Network and Terminals; 3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunneling Protocol for Control plane (GTPv2-C)", 3GPP TS 29.274 V11.2.0 , March 2012. Zhu, et al. Expires April 18, 2013 [Page 15] Internet-Draft Tunnel Congestion Exposure October 2012 [I-D.ietf-conex-abstract-mech] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) Concepts and Abstract Mechanism", draft-ietf-conex-abstract-mech-05 (work in progress), July 2012. [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. Authors' Addresses Lei Zhu Huawei Technologies Huawei Building, Q20 No.156 Beiqing Rd.Z-park Haidian District, Beijing 100095 P. R. China Email: lei.zhu@huawei.com Huabing Zhang Beijing University of Posts and Telecommunications Xitucheng road 10 Haidian District, Beijing 100876 P. R. China Email: zhanghb29@gmail.com Xiangyang Gong Beijing University of Posts and Telecommunications Xitucheng road 10 Haidian District, Beijing 100876 P. R. China Email: xygong@bupt.edu.cn Zhu, et al. Expires April 18, 2013 [Page 16]