Internet DRAFT - draft-cheng-mpls-tp-pwe3-dual-homed-protection

draft-cheng-mpls-tp-pwe3-dual-homed-protection







Network Working Group                                          WQ. Cheng
Internet-Draft                                                   L. Wang
Intended status: Standards Track                                   H. Li
Expires: April 24, 2014                                     China Mobile
                                                                  K. Liu
                                           Huawei Technologies Co., Ltd.
                                                               S. Davari
                                                    Broadcom Corporation
                                                        October 21, 2013


               MPLS-TP PWE3 dual-homed protection (MPDP)
           draft-cheng-mpls-tp-pwe3-dual-homed-protection-00

Abstract

   This document presents the requirements for Dual-homed protection in
   the MPLS-TP networks and defines a protocol that can protect the
   failure of an attachment circuit (AC) or the failure of a provider
   edge (PE) node or the failure of a pseudowire (PW) in the packet-
   switched network (PSN).

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 April 24, 2014.

Copyright Notice

   Copyright (c) 2013 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



Cheng, et al.            Expires April 24, 2014                 [Page 1]

Internet-Draft                    MPDP                      October 2013


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Application scenarios of Dual-Homed protection  . . . . . . .   3
     2.1.  One-side Dual-Homing topology . . . . . . . . . . . . . .   4
     2.2.  Two-side Dual-Homing topology . . . . . . . . . . . . . .   4
   3.  PWE3 dual-homed protection mechanism  . . . . . . . . . . . .   5
     3.1.  Multi-chassis PW protection . . . . . . . . . . . . . . .   5
     3.2.  Multi-chassis LAG . . . . . . . . . . . . . . . . . . . .   7
   4.  Three point-switch collaboration  . . . . . . . . . . . . . .   8
   5.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
   8.  Author's Addresses  . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   The linear protection and Ring protection mechanisms for MPLS-TP is
   described in RFC 6378, RFC 6974 and other IETF drafts.  These
   mechanisms work within the PSN and provide fast recovery when link
   failure or P node failure occurs.  However, they are unable to
   protect against the failure of a PE node or the failure of an
   attachment circuit.

   The PW redundancy solution which is defined by RFC 6718 requires
   separate mechanisms to recover the PE and AC link failure from the
   PSN failure.

   The operators need an end-to-end network's survivability for
   guaranteed services, so the protection mechanisms for AC,PE and
   failure within PSN are all needed.  In order to meet the requirement,
   multiple layers and across nested recovery domains protection should
   be deployed.  It raised the following issues:

   o longer recovery time, because hold-off time should be set to avoid
   race scenarios, which makes the switching time longer.

   o lower bandwidth efficiency because of multi-layer protections.





Cheng, et al.            Expires April 24, 2014                 [Page 2]

Internet-Draft                    MPDP                      October 2013


   o extra configuration makes the operation and maintenance more
   complicated.

   o if RFC 6718 is used, the AC link failure will result in protection
   switching performed within PSN, that means the failure of an AC are
   propagated to the remote PEs on the other side of the network.

   In order to improve on RFC 6718, dual-homed protection mechanism
   should meet the following requirements

   O Using a single layer protection for PSN,AC and PE failure

   PWE3 Dual-Homed protection needs to recover PE failures, tunnel
   failures within PSN and AC link failures through a single layer
   protection mechanism so that the multi-layer protection can be
   avoided.

   O Independent failure recovery

   The principle of independent failure recovery is that the protection
   switching is solely performed within the network domain where the
   failure takes place.  For instance, When a failure in a an AC
   happens, there is no need to inform the remote PE about the failure
   and there is no need to change the PW and path in the PSN.

   O To deploy dual-homed network protection, as far as protocols which
   PE previously support, such as linear protection protocol, can be
   reused, upgrading remote PEs should be avoided.

   According to RFC5654 "2.5.6.  Topology-Specific Recovery Mechanisms",
   "MPLS-TP MAY support recovery mechanisms that are optimized for
   specific network topologies.  These mechanisms MUST be interoperable
   with the mechanisms defined for arbitrary topology (mesh) networks to
   enable the protection of end-to-end transport paths ",this document
   presents a single layer dual-homed protection to meet those
   requirements.

2.  Application scenarios of Dual-Homed protection

   The application scenarios of Dual-homed protection can be classified
   into a One-side Dual-Homing topology and a Two-side Dual-homing
   topology.









Cheng, et al.            Expires April 24, 2014                 [Page 3]

Internet-Draft                    MPDP                      October 2013


2.1.  One-side Dual-Homing topology


            |------------- Emulated Service ------------|
            |                                           |
            |       |-------- Pseudo Wire -------|      |
            |       |                            |      |
            |       |    |--- PSN Tunnels---|    |      |
            |       V    V                  V    V      |
            V   AC  +----+                  +----+      V
      +-----+   |   | PE1|                  |    |      +-----+
      |     |-------|....|...PW1.(active)...|....|      |     |
      |     |       |    |                  |    |      |     |
      |     |       +----+                  |    |  AC  |     |
      |     |         ||                    |    |  |   |     |
      | CE1 |        DNI                    |PE2 |------| CE2 |
      |     |         ||                    |    |      |     |
      |     |       +----+                  |    |      |     |
      |     |       |    |                  |    |      |     |
      |     |-------|....|...PW2.(standby)..|....|      |     |
      +-----+   |   | PE3|                  |    |      +-----+
                AC  +----+                  +----+

                Figure 1 One-side PW Dual-Homing protection

   Figure 1 illustrates the network scenario of one-side CE dual-homing
   topology.  The dual-homing gateways for CE1 are PE1 and PE3, while
   PE2 is the single-homing for CE2.  This scheme protects the node
   failures of PE1 and PE3 and the link failures between PE1 and CE1/PE3
   and CE1.  This scheme can be used in back hauling application
   scenarios.  For example, nodeB serves for CE2 while RNC serves for
   CE1.  PE2 works as an access layer MPLS-TP device while PE1 and PE3
   works as a a pair of core layer MPLS-TP devices.

2.2.  Two-side Dual-Homing topology


            |------------- Emulated Service -------------|
            |                                            |
            |      |--------- Pseudowire -------|        |
            |      |                            |        |
            |      |    |--- PSN Tunnels---|    |        |
            |      V    V                  V    V        |
            V  AC  +----+                  +----+   AC   V
      +-----+  |   |....|.......PW1........|....|   |    +-----+
      |     |------| PE1|                  | PE2|--------|     |
      |     |      +----+                  +----+        |     |
      |     |        ||                      ||          |     |



Cheng, et al.            Expires April 24, 2014                 [Page 4]

Internet-Draft                    MPDP                      October 2013


      | CE1 |       DNI                     DNI          | CE2 |
      |     |        ||                      ||          |     |
      |     |      +----+                  +----+        |     |
      |     |      |    |                  |    |        |     |
      |     |------| PE3|                  | PE4|------- |     |
      +-----+  |   |....|.....PW2..........|....|   |    +-----+
               AC  +----+                  +----+   AC

               Figure 2 dual-side PW Dual-Homing protection

   Figure 2 illustrates the network scenario of two-side CE dual-homing.
   The dual- homing nodes are PE1 and PE3 for CE1, and PE2 and PE4 for
   CE2, respectively.  This scenario protects the PE1/PE3 and PE2/PE4
   nodes failures.  It also protects the links failure between PE1 and
   CE1, PE3 and CE1, PE2 and CE2, and PE4 and CE2.  Meanwhile, dual-
   homing protection needs to handle the recovery of PSN Tunnel failure
   as well.  As for broadband services provider, this scenario is mainly
   used in services for important business customers.  Here, CE1 and CE2
   can be regarded as service access points.

3.  PWE3 dual-homed protection mechanism

   In a PWE3 dual-homed protection mechanism, Multi-chassis PW
   protection is used between PEs, Multi-chassis LAG is used between
   dual-homed PE node group.

3.1.  Multi-chassis PW protection

   RFC6738(MPLS Transport Profile (MPLS-TP) Linear Protection) and ITU-T
   G.8131 have defined linear protection mechanism for MPLS-TP network.
   The PEs of working PW are the same as its protecting PW and the
   protection switching mechanism is running on each PE.

   Dual-homed PW protection mechanism keeps the same protection
   switching mechanism with linear protection in the Remote PE (PE3 in
   figure 3) and the working PW and protecting PW are terminated in
   Dual-homed PEs (PE1 and PE2 in figure 3) respectively in order to
   protect Dual-homed PEs.The protection switching mechanism will be
   detailed in the following chapters.

   Dual nodes interconnection (DNI) PW is set up between two dual-homed
   PE nodes, and it is used to bridge traffic when failure occurs.

   Messages between two dual-homed node include channel status notify
   message and protection group status notify message.  The format of
   these messages is TBD.





Cheng, et al.            Expires April 24, 2014                 [Page 5]

Internet-Draft                    MPDP                      October 2013


               +--------------------+                +--------+
               |                    |                |        |
               |       PE1          |  Working PW    |        |
               |             +-----------------------|        |
               |             |      |\               |        |
               |             |      | \              |        |
               |             |      |  \             |        |
               |             |      |   \            |        |
               +-------------|------+    \           |        |
                          DNI PW    MC PW Protection |  PE3   |
                             |           /           |        |
               +-------------|------+   /            |        |
               |             |      |  /             |        |
               |             |      | /              |        |
               |             |      |- protection PW |        |
               |             +-----------------------|        |
               |                    |                |        |
               |       PE2          |                |        |
               +--------------------+                +--------+


                Figure 3 MC PW linear protection mechanism

   The failure scenarios are listed as follows:

   O One direction Failure of Working PW (PE1 to PE3):

   PE3 detects failure and sends PSC or APS message in protection PW.
   When PE2 receives the failure information, it will exchange a
   switching message with PE3.  At last, PE2 and PE3 will switch the
   traffic to the protection PW.  PE2 will periodically send PE1 MC PW
   protection group status messages,and then PE1 will execute the
   switching according to the status of the MC PW protection.

   O One direction Failure of Working PW (PE3 to PE1):

   PE1 will detect the failure and send PE2 a MC PW protection message
   to notify work PW failure through DNI PW.  PE2 will execute the
   switch with PE3 based on PSC or APS.  PE2 will periodically send PE1
   MC PW protection group status messages, and PE1 will execute
   switching according to the status of the MC PW protection.

   O Bi-direction Failure of Working PW (Between PE3 and PE1):

   Both of PE1 and PE3 will detect link fault respectively.  PE3
   executes switching to protection PW based on APS or PSC.  PE1 sends
   PE2 a MC PW protection message to notify working PW failure through
   DNI PW,and then PE2 will execute switching to protection PW.  PE2



Cheng, et al.            Expires April 24, 2014                 [Page 6]

Internet-Draft                    MPDP                      October 2013


   will periodically send PE1 MC PW protection group status messages,
   and PE1 will execute switching according to the status of the MC PW
   protection.

   O Working PE failure:

   PE3 will detect failure, and send PSC or APS message in the
   protection PW.  After PE2 exchanges the switching message with PE3,
   PE2 and PE3 will switch traffic to the protection PW.

3.2.  Multi-chassis LAG

   LAG(Link Aggregation Group) and LACP(Link Aggregation control
   protocol) is defined in IEEE802.1ax.  LAG is used to expand bandwidth
   and protect link failure.

   DRNI (Distributed Resilient Network Interconnect) and DRCP
   (Distributed Relay Control Protocol) is defined in IEEE P802.1AX-
   REV-D2.2.  DRNI expands the concept of Link Aggregation so that, at
   either one or both ends of a Link Aggregation Group, the single
   Aggregation System is replaced by a Portal, composed from one to
   three Portal Systems.

   In the document, DRNI is used to protect Ethernet link failure
   between CE and PE and dual-homed node Failure on the CE side as shown
   in figure 4.

   O Working PE failure: Detailed signaling between PE1, PE2, CE is TBD


                    +-----------+            +--------+
                    | PE1       |            |        |
                    |     +----+|  Ethernet  |+----+  |
                    |     |port|-------------||port|  |
                    |     +----+|           /|+----+  |
                    +-------|---+          | |        |
                            |  \           | |        |
                          DRCP DRNI      LAG |   CE   |
                            |  /           | |        |
                    +-------|---+          | |        |
                    | PE2   |   |          | |        |
                    |     +----+|           \|+----+  |
                    |     |port||------------||port|  |
                    |     +----+|  Ethernet  |+----+  |
                    +-----------+            +--------+


                          Figure 4 DRNI mechanism



Cheng, et al.            Expires April 24, 2014                 [Page 7]

Internet-Draft                    MPDP                      October 2013


4.  Three point-switch collaboration

   In dual-homed PE nodes, the protection mechanism in PSN network(MC PW
   protection) and protection mechanism between PE and CE(DRNI) should
   cooperate to ensure an appropriate switch operation.


             +------------+            +------------------+
             |   PE3      |            |      PE1         |
             |       +---+| service PW |+---+        +---+|
             |       |PW1|--------------|PW1|        |AC1||
             |       +---+|            |+---+        +---+|
             |            |            |     +------+     |
             |            |            |     |DNI PW|     |
             |            |            |     +------+     |
             |            |            +------------------+
             |            |                     ||
             |            |                     ||DNI PW
             |            |                     ||
             |            |            +------------------+
             |            |            |      +------+    |
             |            |            |      |DNI PW|    |
             |            |            |      +------+    |
             |            |            |                  |
             |       +---+| service PW |+---+        +---+|
             |       |PW2|--------------|PW2|        |AC1||
             |       +---+|            |+---+  PE2   +---+|
             +------------+            +------------------+


                    Figure 6 three point status machine

   Service PW is the PW which carry service between dual-homed PE and
   remote PE.  Service PW status is decided by MC PW protection
   mechanism.

   DNI PW is the bridge PW between two dual-homed PE nodes.  It is used
   to bridge traffic when PSN tunnel or AC failure occurs.

   AC status is the status of AC port between dual-homed PW and CE,
   being either active or standby.  It is decided by DRNI mechanism.


           +--------+--------+--------+---------+--------+
           |srv PW  |   AC   | PW fwd | DNI fwd | AC fwd |
           +--------+--------+--------+---------+--------+
           | Active | Active | to AC  |  to PW  |  to PW |
           +--------+--------+--------+---------+--------+



Cheng, et al.            Expires April 24, 2014                 [Page 8]

Internet-Draft                    MPDP                      October 2013


           | Active | Standby| to DNI |  to PW  |  to PW |
           +--------+--------+--------+---------+--------+
           | Standby| Active | to AC  |  to AC  |  to DNI|
           +--------+--------+--------+---------+--------+
           | Standby| Standby| to DNI |  to AC  |  to DNI|
           +--------+--------+--------+---------+--------+


          Figure 7 three point status machine in dual-homed nodes

   The principle of three point status machine in dual-homed nodes:

   O If AC status is active, establish connection from service PW to AC.
   If AC status is standby, establish connection from service PW to DNI
   PW.

   O If service PW is active, establish connection from AC to service
   PW.  If service PW status is standby, establish connection from AC to
   DNI PW.

   O If service PW is active, establish connection from DNI PW to
   service PW.  If service PW status is standby, establish connection
   from DNI PW to AC.

5.  Formal Syntax

   None

6.  Security Considerations

   None

7.  Acknowledgments

   None

8.  Author's Addresses

   None

9.  References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.




Cheng, et al.            Expires April 24, 2014                 [Page 9]

Internet-Draft                    MPDP                      October 2013


   [RFC5654]  Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
              and S. Ueno, "Requirements of an MPLS Transport Profile",
              RFC 5654, September 2009.

   [RFC6378]  Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and
              A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear
              Protection", RFC 6378, October 2011.

   [RFC6718]  Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire
              Redundancy", RFC 6718, August 2012.

   [RFC6974]  Weingarten, Y., Bryant, S., Ceccarelli, D., Caviglia, D.,
              Fondelli, F., Corsi, M., Wu, B., and X. Dai,
              "Applicability of MPLS Transport Profile for Ring
              Topologies", RFC 6974, July 2013.

Authors' Addresses

   Weiqiang Cheng
   China Mobile
   No.32 Xuanwumen West Street
   Beijing  100053
   China

   Email: chengweiqiang@chinamobile.com


   Lei Wang
   China Mobile
   No.32 Xuanwumen West Street
   Beijing  100053
   China

   Email: Wangleiyj@chinamobile.com


   Han Li
   China Mobile
   No.32 Xuanwumen West Street
   Beijing  100053
   China

   Email: Lihan@chinamobile.com








Cheng, et al.            Expires April 24, 2014                [Page 10]

Internet-Draft                    MPDP                      October 2013


   Kai Liu
   Huawei Technologies Co., Ltd.
   Huawei base, Bantian, Longgang District
   Shenzhen 518129
   China

   Email: alex.liukai@huawei.com


   Shahram Davari
   Broadcom Corporation
   3151 Zanker Road
   San Jose, CA 95134-1933

   Email: davari@broadcom.com




































Cheng, et al.            Expires April 24, 2014                [Page 11]