Network Working Group M. Bocci Internet Draft M. Aissaoui Alcatel-Lucent L. Martini Cisco Expires: May 2008 November 12, 2007 Pseudowire Emulation MPLS PSN Congestion Status Bit draft-bocci-martini-pwe3-psn-congestion-bit-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 12, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Bocci & Martini Expires May 2008 [Page 1] Internet-Draft PWE3 Congestion Status Bit November 2007 Draft-ietf-pwe3-congestion-frmwk-00.txt [2] describes requirements for a PE providing a PWE3 service to take action if congestion is detected in the underlying PSN. This draft provides a control plane mechanism to enable a downstream PE detecting congestion to signal that congestion state to an upstream PE so that it may take appropriate action on its PWs. Conventions used in this document 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 RFC-2119 [1]. Table of Contents 1. Introduction 2 2. Scope 3 3. Reference Model 3 4. PSN Congestion Detection Mechanisms 4 5. PSN Congestion Signaling Procedures 5 6. Prevention of Congestion State Oscillation. 5 7. Congestions Status Bit 6 8. IANA Considerations 6 9. Security Considerations 6 10. Acknowledgments 7 11. References 7 1. Introduction [2] provides requirements and a framework for congestion control for pseudowires. Many pseudowire types transport traffic, which does not behave in a manner similar to TCP when there is congestion in the underlying PSN. That is, they carry traffic such as TDM that does not automatically reduce its rate when congestion occurs. TCP/IP, on the other hand, will reduce its rate and sources will adjust to a sending rate that allows the control plane of the PSN to continue to function. There is a requirement for pseudowires to support a mechanism by which the ingress PE to a PWE3 service can take action to prevent its pseudowires from congesting the PSN. However, although a number of methods to enable an egress PE to detect congestion exist (see [2]), there is to-date no method for communicating that congestion state to the ingress PE. Bocci & Martini Expires May 12, 2008 [Page 2] Internet-Draft PWE3 Congestion Status Bit November 2007 This draft presents extensions to PW status signalling to achieve this. PW status signalling is used because it uses a reliable channel between the PEs; if the PSN is so congested that PW status messages are lost, then LDP hello messages will also be lost. This will cause the PE to declare the link down and the PWs to be released. A PE detecting congestion sends a PSN Congestion status notification to the ingress peer PE for the PW on which congestion is detected. The PE receiving this notification can then take relevant action on the offending PWs, such as releasing the PW or throttling the rate of the PW. 2. Scope This draft describes a congestion notification mechanism where congestion is detected by an egress PE and congestion control actions on PWs are performed by an ingress PE. The draft assumes that each PW or PW segment is established using the PW control protocol [5]. 3. Reference Model PSN1 AC +----+ +----+ AC +-----+ | | PE1|==================| PE2| | +-----+ | |----------|............PW1.............|----------| | | CE1 | | | | | | | | CE2 | | |----------|............PW2.............|----------| | +-----+ | |==================| | | +-----+ ^ +----+ +----+ | ^ | PE1 PE2 | | | CE1 CE2 Figure 1 PWE3 reference Architecture Figure 1 shows the PWE3 reference architecture, derived from [RFC3985]. Traffic from CE1 to CE2 enters the PSN via PE1 (the ingress PE). For the sake of the description in this draft, we assume that congestion occurs in PSN1 as a result of traffic on one or more PWs between PE1 and PE2. PE2 (the egress PE) detects congestion in PSN1 and signals Bocci & Martini Expires May 12, 2008 [Page 3] Internet-Draft PWE3 Congestion Status Bit November 2007 this congestion state to PE1 (the ingress PE). PE1 can then take actions on the PWs to mitigate congestion, as described in [2]. The reference architecture for multi-segment PWs is shown in Figure 2. |<------Multi-Segment Pseudowire------>| | PSN PSN | | |<-Tunnel->| |<-Tunnel->| | V V 1 V V 2 V V +----+ +-----+ +----+ +----+ |TPE1|===========|SPE1 |==========|TPE2| +----+ | |------|..... PW.Seg't1.........PW.Seg't3.....|-------| | | CE1| | | | | | | | |CE2 | | |------|..... PW.Seg't2.........PW.Seg't4.....|-------| | +----+ | |===========| |==========| | | +----+ +----+ +-----+ +----+ Figure 2 Reference Model for MS-PWs Congestion occurring in PSN1 for traffic from CE1 to CE2 will be detected by SPE1, while congestion occurring in PSN2 will be detected by TPE2. In either case, the detected congestion state needs to be communicated to the ingress T-PE so that appropriate actions can be taken. 4. PSN Congestion Detection Mechanisms The protocol described in this draft relies on mechanisms for detecting PSN congestion specified in [2]. At least one of these mechanisms MUST be used. Bocci & Martini Expires May 12, 2008 [Page 4] Internet-Draft PWE3 Congestion Status Bit November 2007 5. PSN Congestion Signaling Procedures Consider the case where congestion occurs in PSN1 for packets traveling from PE1 to PE2. This is detected by PE2 using one of the mechanisms described in [2]. At the onset of this congestion, or when PE2 determines that PSN congestion is imminent, PE2 MUST send a PW status message with the PSN Congestion bit set. The status message MAY be sent as a wildcard notification message to each ingress PE for which the egress PE has detected at least one PW in congestion state. On receipt of the status message, PE1 (the ingress PE) MUST implement congestion control on PWs that are destined for PE2. The precise details of the mechanisms used are outside the scope of this draft. When PE1 detects that congestion in PSN1 has ceased, it MUST send a PW status message to PE1 with the PSN Congestion bit cleared. On receipt of a PW status message with the PSN congestion bit cleared, PE1 MAY cease applying congestion control to PWs destined for PE2. However, there may be some benefit to introducing a random delay to this cessation in order to prevent the PWs immediately re-congesting PSN1. This mechanism is described in Section 6. Similar procedures apply to MS-PWs. An egress T-PE or S-PE detecting PSN congestion sends a PW status message with the PSN congestion bit set to its peer S-PE or T-PE in the upstream direction. This T-PE or S- PE MAY also insert a PW switching TLV [4] with the prefix set to indicate to an upstream T-PE or S-PE the location of the congestion. An S-PE receiving a PW status message relays it to the upstream segment irrespective of the state of the PSN Congestion bit, as described in [segment-pw]. The S-PE MAY also apply congestion control to PWs locally where it represents a policy control point between PSNs. A T-PE receiving a PW status message with the PSN Congestion bit set MUST apply congestion control to the affected PWs, as described as for SS- PWs described above. 6. Prevention of Congestion State Oscillation. The application of PW congestion control may enable the PSN to return to the un-congested state, causing the egress PE to signal no congestion to the ingress PE. However, the PSN may rapidly re-congest if the ingress PE immediately returns all of the PWs to their pre- Bocci & Martini Expires May 12, 2008 [Page 5] Internet-Draft PWE3 Congestion Status Bit November 2007 congestion sending rate, or immediately re-establishes all PWs which were released in order to prevent congestion. In order to prevent such congestion state oscillations occurring, an ingress PE should introduce a per-PW random delay between receiving the PW status message with the PSN Congestion bit cleared, and returning each PW to its pre-congestion state (or allowing a PW that was released to be re-established as in the case of constant bit rate PW types). However it is highly desirable that the PE use a network bandwidth control method similar to the method used by TCP which gradually increases the window size until it experiences a dropped packet. In the case of a PW type that can be policed, or shaped to a specific network utilization bandwidth, the PW SHOULD, whenever possible be shaped to a much smaller network bandwidth utilization. When the congestion status bit is cleared, the PE can gradually increase the PW network bandwidth utilization until either it returns to the required full speed, or it starts to experience congestion again. More details of this procedure will be explained in a subsequent version of this document. 7. Congestions Status Bit The PE/T-PE/S-PE nodes indicate to each other the congestion state of the intervening PSN using this bit. 0x00000TBD When the bit is set, it represents "PSN Congestion" When the bit is cleared, it represents "No PSN Congestion" 8. IANA Considerations IANA needs to allocate the bit "0x00000TBD" to mean "PSN Congestion Status" in the PW status registry. 9. Security Considerations This draft introduces no new security considerations above those in [RFC3985] and [MS-ARCH]. Bocci & Martini Expires May 12, 2008 [Page 6] Internet-Draft PWE3 Congestion Status Bit November 2007 10. Acknowledgments The authors gratefully acknowledge the input of Dimitri Papadimitriou. 11. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Bryant et al; "Pseudowire Congestion Control Framework"; draft-ietf-pwe3-congestion-frmwk-00.txt ; February 2007 [3] Bryant, S. and Pate, P. (Editors), "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005 [4] Martini et al, "Segmented Pseudo Wire", Internet Draft, draft- ietf-pwe3-segmented-pw-05.txt, July 2007 [5] Martini et al; Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP); RFC 4447; April 2006 Author's Addresses Matthew Bocci Alcatel-Lucent Email: matthew.bocci@Alcatel-lucent.co.uk Mustapha Aissaoui Alcatel-Lucent Email: Mustapha.aissaoui@Alcatel-lucent.com Luca Martini Cisco Email: lmartini@cisco.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed Bocci & Martini Expires May 12, 2008 [Page 7] Internet-Draft PWE3 Congestion Status Bit November 2007 to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Bocci & Martini Expires May 12, 2008 [Page 8]