Network Working Group L. Jin
Internet-Draft ZTE
Intended status: Standards Track B. Khasnabish
Expires: January 9, 2012 ZTE USA
M. Venkatesan
Aricent
July 8, 2011
Pseudowire freeze mechanism
draft-jin-pwe3-pw-freeze-02.txt
Abstract
This draft introduces a pseudowire freeze mechanism, which enables
pseudowire control plane and data plane separation. When the PW is
working in freeze state, the data transmission will not be influenced
by turbulence of control plane.
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 9, 2012.
Copyright Notice
Copyright (c) 2011 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
Jin, et al. Expires January 9, 2012 [Page 1]
Internet-Draft draft-jin-pwe3-pw-freeze-01 July 2011
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem statement . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. PW freeze mechanism . . . . . . . . . . . . . . . . . . . . . . 5
4.1. PW freeze status encoding and signaling . . . . . . . . . . 5
4.1.1. PW freeze status definition and encoding . . . . . . . 5
4.1.2. PW freeze status signaling . . . . . . . . . . . . . . 6
4.2. PE operation . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Multi-Segment PW freeze function . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Backward compatibility . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative references . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Jin, et al. Expires January 9, 2012 [Page 2]
Internet-Draft draft-jin-pwe3-pw-freeze-01 July 2011
1. Introduction
This draft introduces a pseudowire freeze mechanism, which enables
pseudowire control plane and data plane separation. When the PW is
working in freeze state, the data transmission will not be influenced
by turbulence of control plane (including signaling and PW control
component), so as to offer to pseudowire [RFC4447] more high
availability, but with low provisioning cost compared with static
pseudowire.
Note that the pseudowire freeze mechanism only applys for pseudowire
with LDP control plane.
PWE3 technology has been used as a transport technology, and deployed
in mobile backhaul or other access/aggregation network. Most of the
pizza boxes supporting PWE3 in access network have lower CPU
performance than that in aggregation/metro/core network, so as to
reduce the hardware cost. What's more, sometimes the boxes in
aggregation network also have low CPU performance. From the
currently deployed network, in order to run LDP and other routing
protocols, we observe that the main controller CPU in pizza box is
sometimes IP forwarding overloaded. When LDP session is established,
the T-LDP hello adjacency may expire because of main controller CPU
overload, which results the corresponding PW traffic being
interrupted.
In MPLS-TP [I-D.ietf-ccamp-mpls-tp-cp-framework], it is required that
the data and control planes are both logically and physically
separated, which ensures that in the case of control plane failures
the data plane is not affected and can continue to operate normally.
While in normal MPLS environment, when PW control plane is DOWN, the
PW traffic will be interrupted.
Jin, et al. Expires January 9, 2012 [Page 3]
Internet-Draft draft-jin-pwe3-pw-freeze-01 July 2011
2. Problem statement
|<-------------- Emulated Service ----------------->|
| |
| |<------- Pseudo Wire ------->| |
| | | |
| | |<-- PSN Tunnel --->| | |
| V V V V |
V AC +----+ +---+ +----+ AC V
+-----+ | | PE1|=======| P |=======| PE2| | +-----+
| |----------|.............................|----------| |
| CE1 | | | | | | | | | | CE2 |
| |----------|.............................|----------| |
+-----+ | | |=======| |=======| | | +-----+
+----+ +---+ +----+
| |
| |
\ /
\ +--------+ /
----| Router |-----
+--------+
Figure 1
In some network of deploying pseudowire, the PW signaling path is
different from the data transmission path. See figure 1, the PSN
Tunnel is setup along the path of PE1, P and PE2, while the T-LDP
session is setup along the path of PE1, Router and PE2. This is
possible if the PSN tunnel is initiated by RSVP-TE which will
calculate the path with explicit route, or the path is an inter-
area/AS one. In this case, the failure of T-LDP session should not
influence the pseudowire data traffic. For example, if the Router in
figure 1 fails and T-LDP session is DOWN, then PW traffic
corresponding to this T-LDP session should not be interrupted.
According to the LDP procedure [RFC5036], if the T-LDP session is
DOWN, the received label from this session should be deleted and
corresponding traffic is interrupted. LDP graceful restart defined
in [RFC3478] is more appliable for IP Prefix, not PW FEC. The PW
information in MPLS forwarding state defined in [RFC3478] section 1
is not enought for a restarting PE to recover. And it is also a bit
complicated for a pizza boxe to implement LDP graceful restart.
For MPLS-TP network, there are also some network maintenance
motivations to make PW to be independent from LDP signaling after PW
being setup successfully. For example, if the service provider wants
to adjust some part of the network without influencing the traffic,
Jin, et al. Expires January 9, 2012 [Page 4]
Internet-Draft draft-jin-pwe3-pw-freeze-01 July 2011
it only needs to care about the transport path of PW without
considering the dynamic IP path of LDP signaling, which will bring
the network adjustment to be much easier.
The PW freeze mechanism can prevent the PW traffic to be interrupted
when T-LDP session is DOWN or the PW control component on PE is
corrupted, but PW forwarding engine continues working.
3. Terminology
T-LDP: Target LDP.
PW control component: The processing component on PE, which is
responsible for PW signaling and management.
Freezed PW: A PW whose control plane is separated from data plane.
4. PW freeze mechanism
The PW freeze mechanism aims to provide a function for PW not to be
influenced by the turbulence of control plane, which will improve the
high availability of the PW. When the PW supports !ofreeze"
function, once PW is operational UP, it will not be influenced by the
turbulence of control plane. When the freezed PW is unfreezed, the
PW will behave as defined in [RFC4447] and [RFC5036].
The turbulence of control plane will include instability of signaling
session and PW control component. When PW is in "freezed" state, PE
should have the capability of continuing PW data forwarding without
PW control component. In this case, before PW control component is
failed, PE SHOULD store the PW information in the backup PW control
component or non-volatile ROM, which is an implementation issue.
When PW control component is initialized, it SHOULD restore the PW
information from the backup component. The specific of above
procedure depends on implementation and is out of scope of this
draft. This draft only deals with the control plane of PW signaling
session, T-LDP session. This version of draft only describes the
case of point-to-point PW, and unidirectional point-to-multipoint PW
will be studied in future version.
4.1. PW freeze status encoding and signaling
4.1.1. PW freeze status definition and encoding
There will be two state defined for PW in this draft, freezed and
normal state. In the freezed state, PW will not be influenced by the
Jin, et al. Expires January 9, 2012 [Page 5]
Internet-Draft draft-jin-pwe3-pw-freeze-01 July 2011
control plane and continue working and transmitting traffic if
control plane is DOWN. In the normal state, also known as unfreezed
state, the PW will behave as defined in [RFC4447] and [RFC5036], and
the PW traffic will be interrupted when T-LDP session is DOWN.
The PW freeze status is encoded in PW status TLV. The status code
definition (IANA, TBD) is pre-allocated as 0x00000080.
When the PW freeze bit is set, it indicates that the PW supports
"freeze" function, and will be in "freeze" state.
When the PW freeze bit is cleared, it indicates that the PW will be
in "unfreeze" status.
4.1.2. PW freeze status signaling
When the PW is configured as "freeze", PE SHOULD advertise the
capability by sending label mapping message carrying the PW status
TLV with "PW freeze bit" set, or by sending LDP notification message
carrying the PW status TLV with "PW freeze bit" set. The PW freeze
function will be effective only when both endpoints of PW signal the
"PW freeze" status.
When one of the PW endpoint signals PW status with PW freeze bit
cleared, both of the two endpoints should unfreeze the PW. When PW
is already in "freeze" state, the PW status should be transmitted
through generic associated channel, as defined in
[I-D.ietf-pwe3-static-pw-status], the MAC withdraw message
transmission should follow [I-D.boutros-pwe3-mpls-tp-mac-wd].
4.2. PE operation
If PW supports "freeze" function through negotiation, as in section
4.1.2:
1. When PW is operational UP, PW will enter into the freezed state.
The PE should locally store the PW information that received from the
peer node, including PW type, PW label and etc. For more detail of
the PW information, please refer to [RFC4447].
1.a. When T-LDP session is DOWN, the PE should continue the PW data
forwarding. In this case, if the PW on one PE will be deleted or not
provisioned, before deleting the PW, PE should send PW down status
bit to peer node through G-ACH.
1.b. When T-LDP session switches from DOWN to UP status, and if
local PW status is DOWN, PE should send PW label mapping message to
peer node again, with the PW information stored locally. If peer
Jin, et al. Expires January 9, 2012 [Page 6]
Internet-Draft draft-jin-pwe3-pw-freeze-01 July 2011
node receives a PW label mapping message with different information
as stored locally, it should update the PW information. If local PW
status is UP, there is no operation for PE.
2. When PW is operational DOWN, PW will still in normal state, and
not enter into the freezed state.
If PW is configured or signaled to "unfreeze", as in section 4.1.2:
When PW corresponding T-LDP session is DOWN, PE should delete the
corresponding PW, and stop forwarding traffic. To be noted: PE
should send PW status TLV with !oPW not forwarding!+/- status bit set
to peer node through G-ACH before completely delete PW locally.
2. When PW corresponding T-LDP session is UP, there is no operation
for PE.
4.3. Multi-Segment PW freeze function
For the case of multi-segment PW, only when each PW segment support
"freeze" function, the MS-PW will support freeze function. When S-PE
receives PW status with "PW freeze" bit set, and if the PW segment on
this S-PE does not support "freeze" function, S-PE will forward this
PW status with "PW freeze" bit cleared.
5. IANA Considerations
This document defines the PW freeze status code for the PW freeze
mechanism. IANA is requested to allocate these from the PW Status
Codes registry. The PW freeze status code definition is pre-
allocated as 0x00000080.
When the PW freeze bit is set, it indicates that the PW supports
"freeze" function, and will be in "freeze" status.
When the PW freeze bit is cleared, it indicates that the PW will be
in "unfreeze" status.
6. Backward compatibility
The PE that does not support the PW freeze bit in status TLV will
ignore this bit, and the PW will not enter into freeze status.
7. References
Jin, et al. Expires January 9, 2012 [Page 7]
Internet-Draft draft-jin-pwe3-pw-freeze-01 July 2011
7.1. Normative references
[RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful
Restart Mechanism for Label Distribution Protocol",
RFC 3478, February 2003.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
7.2. Informative References
[I-D.boutros-pwe3-mpls-tp-mac-wd]
Sivabalan, S., Boutros, S., and L. Martini, "MAC Address
Withdrawal over Static Pseudowire",
draft-boutros-pwe3-mpls-tp-mac-wd-01 (work in progress),
March 2011.
[I-D.ietf-ccamp-mpls-tp-cp-framework]
Andersson, L., Berger, L., Fang, L., Bitar, N., Gray, E.,
Takacs, A., Vigoureux, M., and E. Bellagamba, "MPLS-TP
Control Plane Framework",
draft-ietf-ccamp-mpls-tp-cp-framework-06 (work in
progress), February 2011.
[I-D.ietf-pwe3-static-pw-status]
Martini, L., Swallow, G., Heron, G., and M. Bocci,
"Pseudowire Status for Static Pseudowires",
draft-ietf-pwe3-static-pw-status-05 (work in progress),
June 2011.
Authors' Addresses
Lizhong Jin
ZTE Corporation
889, Bibo Road
Shanghai, 201203, China
Email: lizhong.jin@zte.com.cn
Jin, et al. Expires January 9, 2012 [Page 8]
Internet-Draft draft-jin-pwe3-pw-freeze-01 July 2011
Bhumip Khasnabish
ZTE USA
Email: bhumip.khasnabish@zteusa.com
Mahalingam Venkatesan
Aricent
India
Email: venkatesan.mahalingam@aricent.com
Kan Hu
ZTE Corporation
68, Zijinghua Road
Nanjing, 210012, China
Email: hu.kan@zte.com.cn
Baojun Chen
ZTE Corporation
68, Zijinghua Road
Nanjing, 210012, China
Email: chen.baojun@zte.com.cn
Jian Feng
ZTE Corporation
68, Zijinghua Road
Nanjing, 210012, China
Email: feng.jian@zte.com.cn
Jin, et al. Expires January 9, 2012 [Page 9]