Internet DRAFT - draft-bocci-martini-pwe3-psn-congestion-bit
draft-bocci-martini-pwe3-psn-congestion-bit
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]
