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]