idnits 2.17.00 (12 Aug 2021) /tmp/idnits24406/draft-bocci-martini-pwe3-psn-congestion-bit-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 316. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 292. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 299. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 305. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 12, 2007) is 5297 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC3985' on line 243 -- Looks like a reference, but probably isn't: 'MS-ARCH' on line 243 == Unused Reference: '3' is defined on line 258, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ietf-pwe3-congestion-frmwk-00 ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-congestion-frmwk (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 3985 (ref. '3') == Outdated reference: draft-ietf-pwe3-segmented-pw has been published as RFC 6073 ** Obsolete normative reference: RFC 4447 (ref. '5') (Obsoleted by RFC 8077) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Bocci 2 Internet Draft M. Aissaoui 3 Alcatel-Lucent 5 L. Martini 6 Cisco 8 Expires: May 2008 November 12, 2007 10 Pseudowire Emulation MPLS PSN Congestion Status Bit 11 draft-bocci-martini-pwe3-psn-congestion-bit-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that 16 any applicable patent or other IPR claims of which he or she is 17 aware have been or will be disclosed, and any of which he or she 18 becomes aware will be disclosed, in accordance with Section 6 of 19 BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as 29 reference material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on April 12, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 44 Draft-ietf-pwe3-congestion-frmwk-00.txt [2] describes requirements 45 for a PE providing a PWE3 service to take action if congestion is 46 detected in the underlying PSN. This draft provides a control plane 47 mechanism to enable a downstream PE detecting congestion to signal 48 that congestion state to an upstream PE so that it may take 49 appropriate action on its PWs. 51 Conventions used in this document 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC-2119 [1]. 57 Table of Contents 59 1. Introduction 2 60 2. Scope 3 61 3. Reference Model 3 62 4. PSN Congestion Detection Mechanisms 4 63 5. PSN Congestion Signaling Procedures 5 64 6. Prevention of Congestion State Oscillation. 5 65 7. Congestions Status Bit 6 66 8. IANA Considerations 6 67 9. Security Considerations 6 68 10. Acknowledgments 7 69 11. References 7 71 1. Introduction 73 [2] provides requirements and a framework for congestion control for 74 pseudowires. Many pseudowire types transport traffic, which does not 75 behave in a manner similar to TCP when there is congestion in the 76 underlying PSN. That is, they carry traffic such as TDM that does 77 not automatically reduce its rate when congestion occurs. TCP/IP, on 78 the other hand, will reduce its rate and sources will adjust to a 79 sending rate that allows the control plane of the PSN to continue to 80 function. 82 There is a requirement for pseudowires to support a mechanism by 83 which the ingress PE to a PWE3 service can take action to prevent 84 its pseudowires from congesting the PSN. However, although a number 85 of methods to enable an egress PE to detect congestion exist (see 86 [2]), there is to-date no method for communicating that congestion 87 state to the ingress PE. 89 This draft presents extensions to PW status signalling to achieve 90 this. PW status signalling is used because it uses a reliable 91 channel between the PEs; if the PSN is so congested that PW status 92 messages are lost, then LDP hello messages will also be lost. This 93 will cause the PE to declare the link down and the PWs to be 94 released. A PE detecting congestion sends a PSN Congestion status 95 notification to the ingress peer PE for the PW on which congestion 96 is detected. The PE receiving this notification can then take 97 relevant action on the offending PWs, such as releasing the PW or 98 throttling the rate of the PW. 100 2. Scope 102 This draft describes a congestion notification mechanism where 103 congestion is detected by an egress PE and congestion control 104 actions on PWs are performed by an ingress PE. The draft assumes 105 that each PW or PW segment is established using the PW control 106 protocol [5]. 108 3. Reference Model 110 PSN1 111 AC +----+ +----+ AC 112 +-----+ | | PE1|==================| PE2| | +-----+ 113 | |----------|............PW1.............|----------| | 114 | CE1 | | | | | | | | CE2 | 115 | |----------|............PW2.............|----------| | 116 +-----+ | |==================| | | +-----+ 117 ^ +----+ +----+ | ^ 118 | PE1 PE2 | 119 | | 120 CE1 CE2 122 Figure 1 PWE3 reference Architecture 124 Figure 1 shows the PWE3 reference architecture, derived from 125 [RFC3985]. 127 Traffic from CE1 to CE2 enters the PSN via PE1 (the ingress PE). For 128 the sake of the description in this draft, we assume that congestion 129 occurs in PSN1 as a result of traffic on one or more PWs between PE1 130 and PE2. PE2 (the egress PE) detects congestion in PSN1 and signals 131 this congestion state to PE1 (the ingress PE). PE1 can then take 132 actions on the PWs to mitigate congestion, as described in [2]. 134 The reference architecture for multi-segment PWs is shown in Figure 135 2. 137 |<------Multi-Segment Pseudowire------>| 138 | PSN PSN | 139 | |<-Tunnel->| |<-Tunnel->| | 140 V V 1 V V 2 V V 141 +----+ +-----+ +----+ 142 +----+ |TPE1|===========|SPE1 |==========|TPE2| +----+ 143 | |------|..... PW.Seg't1.........PW.Seg't3.....|-------| | 144 | CE1| | | | | | | | |CE2 | 145 | |------|..... PW.Seg't2.........PW.Seg't4.....|-------| | 146 +----+ | |===========| |==========| | | +----+ 147 +----+ +-----+ +----+ 149 Figure 2 Reference Model for MS-PWs 151 Congestion occurring in PSN1 for traffic from CE1 to CE2 will be 152 detected by SPE1, while congestion occurring in PSN2 will be 153 detected by TPE2. In either case, the detected congestion state 154 needs to be communicated to the ingress T-PE so that appropriate 155 actions can be taken. 157 4. PSN Congestion Detection Mechanisms 159 The protocol described in this draft relies on mechanisms for 160 detecting PSN congestion specified in [2]. At least one of these 161 mechanisms MUST be used. 163 5. PSN Congestion Signaling Procedures 165 Consider the case where congestion occurs in PSN1 for packets traveling 166 from PE1 to PE2. This is detected by PE2 using one of the mechanisms 167 described in [2]. At the onset of this congestion, or when PE2 168 determines that PSN congestion is imminent, PE2 MUST send a PW status 169 message with the PSN Congestion bit set. The status message MAY be sent 170 as a wildcard notification message to each ingress PE for which the 171 egress PE has detected at least one PW in congestion state. 173 On receipt of the status message, PE1 (the ingress PE) MUST implement 174 congestion control on PWs that are destined for PE2. The precise 175 details of the mechanisms used are outside the scope of this draft. 177 When PE1 detects that congestion in PSN1 has ceased, it MUST send a PW 178 status message to PE1 with the PSN Congestion bit cleared. On receipt 179 of a PW status message with the PSN congestion bit cleared, PE1 MAY 180 cease applying congestion control to PWs destined for PE2. However, 181 there may be some benefit to introducing a random delay to this 182 cessation in order to prevent the PWs immediately re-congesting PSN1. 183 This mechanism is described in Section 6. 185 Similar procedures apply to MS-PWs. An egress T-PE or S-PE detecting 186 PSN congestion sends a PW status message with the PSN congestion bit 187 set to its peer S-PE or T-PE in the upstream direction. This T-PE or S- 188 PE MAY also insert a PW switching TLV [4] with the prefix set to 189 indicate to an upstream T-PE or S-PE the location of the congestion. An 190 S-PE receiving a PW status message relays it to the upstream segment 191 irrespective of the state of the PSN Congestion bit, as described in 192 [segment-pw]. The S-PE MAY also apply congestion control to PWs locally 193 where it represents a policy control point between PSNs. A T-PE 194 receiving a PW status message with the PSN Congestion bit set MUST 195 apply congestion control to the affected PWs, as described as for SS- 196 PWs described above. 198 6. Prevention of Congestion State Oscillation. 200 The application of PW congestion control may enable the PSN to return 201 to the un-congested state, causing the egress PE to signal no 202 congestion to the ingress PE. However, the PSN may rapidly re-congest 203 if the ingress PE immediately returns all of the PWs to their pre- 204 congestion sending rate, or immediately re-establishes all PWs which 205 were released in order to prevent congestion. 207 In order to prevent such congestion state oscillations occurring, an 208 ingress PE should introduce a per-PW random delay between receiving the 209 PW status message with the PSN Congestion bit cleared, and returning 210 each PW to its pre-congestion state (or allowing a PW that was released 211 to be re-established as in the case of constant bit rate PW types). 212 However it is highly desirable that the PE use a network bandwidth 213 control method similar to the method used by TCP which gradually 214 increases the window size until it experiences a dropped packet. In the 215 case of a PW type that can be policed, or shaped to a specific network 216 utilization bandwidth, the PW SHOULD, whenever possible be shaped to a 217 much smaller network bandwidth utilization. When the congestion status 218 bit is cleared, the PE can gradually increase the PW network bandwidth 219 utilization until either it returns to the required full speed, or it 220 starts to experience congestion again. 222 More details of this procedure will be explained in a subsequent 223 version of this document. 225 7. Congestions Status Bit 227 The PE/T-PE/S-PE nodes indicate to each other the congestion state of 228 the intervening PSN using this bit. 230 0x00000TBD When the bit is set, it represents "PSN Congestion" 232 When the bit is cleared, it represents "No PSN 233 Congestion" 235 8. IANA Considerations 237 IANA needs to allocate the bit "0x00000TBD" to mean "PSN Congestion 238 Status" in the PW status registry. 240 9. Security Considerations 242 This draft introduces no new security considerations above those in 243 [RFC3985] and [MS-ARCH]. 245 10. Acknowledgments 247 The authors gratefully acknowledge the input of Dimitri 248 Papadimitriou. 250 11. References 252 [1] Bradner, S., "Key words for use in RFCs to Indicate 253 Requirement Levels", BCP 14, RFC 2119, March 1997. 255 [2] Bryant et al; "Pseudowire Congestion Control Framework"; 256 draft-ietf-pwe3-congestion-frmwk-00.txt ; February 2007 258 [3] Bryant, S. and Pate, P. (Editors), "Pseudo Wire Emulation 259 Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005 261 [4] Martini et al, "Segmented Pseudo Wire", Internet Draft, draft- 262 ietf-pwe3-segmented-pw-05.txt, July 2007 264 [5] Martini et al; Pseudowire Setup and Maintenance Using the 265 Label Distribution Protocol (LDP); RFC 4447; April 2006 267 Author's Addresses 269 Matthew Bocci 270 Alcatel-Lucent 271 Email: matthew.bocci@Alcatel-lucent.co.uk 273 Mustapha Aissaoui 274 Alcatel-Lucent 276 Email: Mustapha.aissaoui@Alcatel-lucent.com 278 Luca Martini 279 Cisco 281 Email: lmartini@cisco.com 283 Intellectual Property Statement 285 The IETF takes no position regarding the validity or scope of any 286 Intellectual Property Rights or other rights that might be claimed 287 to pertain to the implementation or use of the technology described 288 in this document or the extent to which any license under such 289 rights might or might not be available; nor does it represent that 290 it has made any independent effort to identify any such rights. 291 Information on the procedures with respect to rights in RFC 292 documents can be found in BCP 78 and BCP 79. 294 Copies of IPR disclosures made to the IETF Secretariat and any 295 assurances of licenses to be made available, or the result of an 296 attempt made to obtain a general license or permission for the use 297 of such proprietary rights by implementers or users of this 298 specification can be obtained from the IETF on-line IPR repository 299 at http://www.ietf.org/ipr. 301 The IETF invites any interested party to bring to its attention any 302 copyrights, patents or patent applications, or other proprietary 303 rights that may cover technology that may be required to implement 304 this standard. Please address the information to the IETF at 305 ietf-ipr@ietf.org. 307 Disclaimer of Validity 309 This document and the information contained herein are provided on 310 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 311 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 312 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 313 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 314 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 315 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 316 FOR A PARTICULAR PURPOSE. 318 Copyright Statement 320 Copyright (C) The IETF Trust (2007). 322 This document is subject to the rights, licenses and restrictions 323 contained in BCP 78, and except as set forth therein, the authors 324 retain all their rights. 326 Acknowledgment 328 Funding for the RFC Editor function is currently provided by the 329 Internet Society.