conex Lei. zhu Internet-Draft Huawei Technologies Intended status: Informational June 30, 2010 Expires: January 1, 2011 Requirements of Localised Congestion Notification draft-lei-ecn-localised-congestion-notification-00 Abstract This document introduces analyzes of ECN(Explicit Congestion Notification)in case of congestion of local links. 3GPP adopts and specifies shared channel for multiple user equipments in a cell. Other last mile access systems (e.g. xDSL access and Frame Relay access) have to handle congestion since bandwidth multiplexing is most likely considered for reducing unnecessary cost. Therefore, congestion in access network is to inform user equipments in case of traffic congestion utilizing congestion notification concepts and similar mechanisms. 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 1, 2011. Copyright Notice Copyright (c) 2010 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 zhu Expires January 1, 2011 [Page 1] Internet-Draft Localised ECN June 2010 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 Expires January 1, 2011 [Page 2] Internet-Draft Localised ECN June 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 zhu Expires January 1, 2011 [Page 3] Internet-Draft Localised ECN June 2010 1. Introduction ECN [RFC3168], a proposed standard document, defines the ECN field in the IP header, and specifies the semantics for the code points for the ECN field. These are all unicast protocols which negotiate the use of ECN during the initial connection establishment handshake (supporting incremental deployment, and checking if ECN marked packets pass all middleboxes on the path). Basically, ECN is an end to end solution involving endpoints and intermediate entities in the transport path. The ECN solution requires that terminals and intermediate nodes (e.g. router and firewall) in the path to support ECN functions. Otherwise, the whole solution does not fulfill the requirements to mechanisms of ECN. The ECN also updates the definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers with optional ECN fields. The ECN mechanism originally includes the associations with congestion control and avoidance algorithms of TCP [RFC0793]. The problem is that this end to end solution highly relies on the supports of intermediate node in the path. Since, there exist some middleboxes (firewalls, load balancers, or intrusion detection systems) in the Internet that either drop a TCP SYN packet configured to negotiate ECN, or respond with a RST. Besides the congestion appears in backbones of Tier 1 or Tier 2 service providers, the most of traffic congestion seem happen in access network due to a lot of reasons. For example, the ADSL multiplexer is likely to multiplex traffic, but multiplexer would not avoid congestion in particular periods (e.g. rush hour of transportation system). Another example is 3GPP LTE architecture which specifies shared logic channel in particular cell with very high capacity. However, even though terminals use low class traffic (e.g the traffic class only insure best effort service.), the capacity of the shared channel could be exhausted by applications which generates huge number of traffic. In general, some problems could happy or have appeared in network, all indicate that the congestion of access network is likely critical issue to usages of congestion notifications in next generation networks. 2. Terminology 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]. zhu Expires January 1, 2011 [Page 4] Internet-Draft Localised ECN June 2010 3. Requirements In this section, the author tries to introduce requirements of localized ECN mechanism. The goals of localized ECN are: a. Provide a locolized congestion notification mechanism extending the scope of ECN solution to notify congestion only happened in access network; b. The localized ECN mechanism should support notification of congestion at access network in spite of intermediate supports in the whole path; c. The localized congestion notification mechanism should be compliant with the ECN solution, and support the back compatibility to ECN solution. Therefore, the concluded requirements are, the localized ECN mechanism: a. MUST be able to notify congestion of access network to the local senders which contributes to the uplink congestion. b. MUST be able to notify congestion of access network to the local receivers which receive data contributing to the downlink congestion. c. MUST be able to notify the uplink congestion and downlink congestion of access network to senders and receivers. 4. Security Considerations TBD 5. IANA Considerations There have been no IANA considerations so far in this document. 6. Acknowledgments TBD zhu Expires January 1, 2011 [Page 5] Internet-Draft Localised ECN June 2010 7. Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [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. Author's Address Lei Zhu Huawei Technologies Huawei Building, Xinxi Road No.3 Haidian District, Beijing 100085 P. R. China Phone: +86-10-82836301 Email: Lei.zhu@huawei.com zhu Expires January 1, 2011 [Page 6]