Internet DRAFT - draft-cohn-mpls-tp-pw-protection
draft-cohn-mpls-tp-pw-protection
MPLS Working Group D. Cohn
R. Ram
Internet Draft Orckit-Corrigent
Intended status: Standards Track
M. Yuxia
Expires: July 4, 2012 ZTE Corp.
M. Daikoku
KDDI
January 4, 2012
MPLS-TP Linear Protection Applicability to MS-PW
draft-cohn-mpls-tp-pw-protection-02.txt
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), 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 July 4, 2012.
Copyright Notice
Copyright (c) 2012 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 to this document. Code Components extracted from this
Cohn, et al. Expires July 4, 2012 [Page 1]
Internet-Draft MPLS-TP LP Applicability to MS-PW Jan 2012
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.
Abstract
One of the requirements of the MPLS transport profile [RFC5654] is
to provide linear protection for transport paths, which include both
LSPs and PWs. The functional architecture described in [SurvivFwk]
is applicable to both LSP and PWs, however [LinearProt] does not
explicitly describe mechanisms for PW protection in MPLS-TP.
This document extends the applicability of the linear protection
mechanism described in [LinearProt] to MPLS-TP segmented PWs as
defined in [RFC6073].
Table of Contents
1. Introduction ................................................ 2
1.1. Background on MS-PW..................................... 3
1.2. MS-PW protection requirements........................... 3
2. Conventions used in this document............................ 4
3. PSC applicability to PW...................................... 4
4. Security Considerations...................................... 5
5. IANA Considerations ......................................... 5
6. References .................................................. 5
6.1. Normative References.................................... 5
6.2. Informative References.................................. 5
7. Acknowledgments ............................................. 6
1. Introduction
When specifying the requirements for an MPLS Transport Profile,
[RFC5654] states that "In an MPLS-TP environment, a transport path
corresponds to an LSP or a PW". It follows that recovery
requirements in section 2.5 of [RFC5654] apply to PWs as well as to
LSPs. The MPLS-TP survivability framework described in [SurvivFwk]
states that "The general description of the functional architecture
is applicable to both LSPs and pseudowires (PWs), however, PW
recovery is only introduced in Section 7, and the relevant details
are beyond the scope of this document and are for further study".
Finally, the MPLS-TP OAM framework described in [OamFwk] provides
tools for PW monitoring that are suitable for PW protection
triggering.
[LinearProt] describes a protection state coordination (PSC)
protocol that can be used to provide linear protection for LSPs.
Cohn, et al. Expires July 4, 2012 [Page 2]
Internet-Draft MPLS-TP LP Applicability to MS-PW Jan 2012
This document extends the applicability of the PSC control logic and
protocol to support MPLS-TP segmented PW (aka MS-PW) protection
against S-PE failure.
1.1. Background on MS-PW
This section reviews operator motivations for MS-PW usage in an
MPLS-TP framework. Some of these are mentioned in [RFC5254] and
[RFC6073].
o PSN Internetworking: The PW route may go across nodes that are
interconnected using different PSN protocols. In this case, it is
not possible to establish a single LSP between the terminating
PEs, and therefore a single-segment PW (SS-PW) cannot be used.
o Domain separation: The PW route may cross different
administrative domains, either intra- or inter-operator. In this
scenario, it may not be possible to establish a single transport
path (LSP or PW) between nodes in different operators, so SS-PW
cannot be used.
o Reduce network delay variations: Some end users (e.g. financial
customers) are very sensitive to the network delay provided by
the operator service. Operators therefore want to minimize both
the absolute network delay provided, and the variations in
network delay upon different events, specifically node or link
failures. SS-PW recovery from a link failure requires end-to-end
switching to another SS-PW which will typically have a different
network route and thus provide a significantly different network
delay. MS-PW, on the other hand, allows link failure recovery by
local switching on the failed segment, which typically achieves
much lower network delay variation.
MS-PW end-to-end switching, involving higher network delay
variation, is performed only upon node (S-PE) failure.
1.2. MS-PW protection requirements
PW protection is required to support PW recovery upon node failure
of an S-PE in an MS-PW application. MS-PW and S-PE are defined in
[RFC6073]. LSP recovery is not helpful in this scenario and
therefore a separate mechanism is required to provide MS-PW
recovery. It should be noted that LSP recovery does provide PW
recovery in the link failure scenario.
Figure 1 illustrates such a scenario, where two MS-PWs are
established between T-PE A and T-PE Z, over S-PEs 1-2 and 3-4
respectively. Each PW segment is established over an LSP (e.g. PW-
s12 over LSP12).
Cohn, et al. Expires July 4, 2012 [Page 3]
Internet-Draft MPLS-TP LP Applicability to MS-PW Jan 2012
<--------------MS-PW A12Z------------->
+----+ +-----+ +-----+ +----+
| |LSPA1 |SPE1 |LSP12 |SPE2 |LSP2Z | |
| |------| X |------| X |------| |
| |PW-sA1| |PW-s12| |PW-s2Z| |
|TPEA| +-----+ +-----+ |TPEZ|
| | | |
| | +-----+ +-----+ | |
| |PW-sA3|SPE3 |PW-s34|SPE4 |PW-s4Z| |
| |------| X |------| X |------| |
| |LSPA3 | |LSP34 | |LSP4Z | |
+----+ +-----+ +-----+ +----+
<--------------MS-PW A34Z------------->
Figure 1: MS-PW protection
Without loss of generality, it is assumed that MS-PW A12Z is active
in the normal state. In the event of a failure in S-PE 1, LSPs A1
and 12 cannot recover by using LSP protection mechanisms, but the
MS-PW can recover by switching to MS-PW A34Z.
This mechanism requires coordination between the two MS-PW endpoints
to decide which of the two MS-PWs will be active, i.e. transmitting
data traffic.
2. 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].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
3. PSC applicability to PW
PSC control logic and protocol for MS-PW protection SHALL be as
defined in sections 3 and 4 of [LinearProt].
Cohn, et al. Expires July 4, 2012 [Page 4]
Internet-Draft MPLS-TP LP Applicability to MS-PW Jan 2012
All references therein to OAM indications SHALL be applied as
referring to MS-PW OAM, i.e. provided by the MS-PW MEG (PMEG, as
defined in section 4.3. of [OamFwk] ).
All references therein to LER SHALL be applied as referring to T-PE.
All references therein to the server layer SHALL be applied as
referring to the LSPs over which the MS-PW is carried.
Protocol format SHALL be the same defined in section 4.2 of
[LinearProt]. All references therein to the G-ACh SHALL be applied
to the PW Associated Channel (PWAC), as described in [RFC4385].
4. Security Considerations
No security considerations other than those mentioned in
[LinearProt] apply.
5. IANA Considerations
No new IANA considerations
6. References
6.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[SurvivFwk] Sprecher, N., Farrel, A., and H. Shah, "Multi-protocol
Label Switching Transport Profile Survivability
Framework", RFC 6372, Sep 2011
[LinearProt] S. Bryant, E. Osborne, N. Sprecher, A. Fulignoli, Y.
Weingarten, "MPLS-TP Linear Protection", RFC 6378, Oct
2011
[OamFwk] I. Busi, D. Allan, "Operations, Administration and
Maintenance Framework for MPLS-based Transport
Networks", RFC 6371, Sep 2011
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word
for Use over an MPLS PSN", RFC 4385, Feb 2006.
Cohn, et al. Expires July 4, 2012 [Page 5]
Internet-Draft MPLS-TP LP Applicability to MS-PW Jan 2012
[RFC5254] Bitar, N., Ed., Bocci, M., Ed., and L. Martini, Ed.,
"Requirements for Multi-Segment Pseudowire Emulation
Edge-to-Edge (PWE3)", RFC 5254, Oct 2008.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher,
N., and S. Ueno, "Requirements of an MPLS Transport
Profile", RFC 5654, Sep 2009
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
Aissaoui, "Segmented Pseudowire", RFC 6073, Jan 2011.
7. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Daniel Cohn
Orckit-Corrigent
Yigal Alon 126, Tel Aviv
Israel
Email: danielc@orckit.com
Rafi Ram
Orckit-Corrigent
Yigal Alon 126, Tel Aviv
Israel
Email: rafir@orckit.com
Ma Yuxia
ZTE Corp.
China
Email: ma.yuxia@zte.com.cn
Masahiro Daikoku
KDDI
Japan
Email: ms-daikoku@kddi.com
Cohn, et al. Expires July 4, 2012 [Page 6]
