Internet Engineering Task Force                                  H. Chen
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                                   N. So
Expires: September 14, 2012                                 Verizon Inc.
                                                                  A. Liu
                                                                Ericsson
                                                             O. Komolafe
                                                           Cisco Systems
                                                                  L. Liu
                                                       KDDI R&D Lab Inc.
                                                          March 13, 2012


      Extensions to RSVP-TE for P2MP LSP Ingress Local Protection
             draft-chen-mpls-p2mp-ingress-protection-05.txt

Abstract

   This document describes extensions to Resource Reservation Protocol -
   Traffic Engineering (RSVP-TE) for locally protecting the ingress node
   of a Traffic Engineered (TE) Point-to-MultiPoint (P2MP) Label
   Switched Path (LSP) in a Multi-Protocol Label Switching (MPLS) and
   Generalized MPLS (GMPLS) network.

Status of this Memo

   This Internet-Draft is submitted to IETF 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 September 14, 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



Chen, et al.           Expires September 14, 2012               [Page 1]


Internet-Draft         P2MP LSP Ingress Protection            March 2012


   (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 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.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
   4.  Mechanism  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  An Example of Ingress Local Protection . . . . . . . . . .  4
     4.2.  Set up of Backup P2MP sub Tree . . . . . . . . . . . . . .  5
     4.3.  Forwarding State for Backup P2MP sub Tree  . . . . . . . .  5
     4.4.  Detection of Failure around Ingress  . . . . . . . . . . .  6
   5.  Ingress Local Protection with FRR  . . . . . . . . . . . . . .  7
   6.  LSP Information Message  . . . . . . . . . . . . . . . . . . .  7
     6.1.  Format of LSP Information Message  . . . . . . . . . . . .  8
     6.2.  Processing of LSP Information Message  . . . . . . . . . .  8
     6.3.  Discussions on Other Approaches  . . . . . . . . . . . . .  9
   7.  PATH Messages for Backup P2MP sub Tree . . . . . . . . . . . .  9
     7.1.  Construction of PATH Messages  . . . . . . . . . . . . . .  9
     7.2.  Processing of PATH Messages  . . . . . . . . . . . . . . . 10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   9.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 10
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     10.2. Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12


















Chen, et al.           Expires September 14, 2012               [Page 2]


Internet-Draft         P2MP LSP Ingress Protection            March 2012


1.  Introduction

   RFC4090 "Fast Reroute Extensions to RSVP-TE for LSP Tunnels"
   describes two methods to protect P2P LSP tunnels or paths at local
   repair points.  The first method is a one-to-one backup method, where
   a detour backup P2P LSP for each protected P2P LSP is created at each
   potential point of local repair, which is an intermediate node
   between the ingress node and the egress node of the protected LSP.
   The second method is a facility bypass backup protection method,
   where a bypass backup P2P LSP tunnel is created using MPLS label
   stacking to protect a potential failure point for a set of P2P LSP
   tunnels.  The bypass backup tunnel can protect a set of P2P LSPs that
   have similar backup constraints.

   RFC4875 "Extensions to RSVP-TE for P2MP TE LSPs" describes how to use
   the one-to-one backup method and facility bypass backup method to
   protect a link or intermediate node failure on the path of a P2MP
   LSP.  However, there is no mention of locally protecting an ingress
   node failure in a protected P2MP LSP.

   There exist two methods for protecting an ingress node of a P2MP LSP.
   The first method deploys a backup P2MP LSP from a backup ingress node
   to the destination nodes to protect the ingress node.  The main
   disadvantage of this method is that the backup P2MP LSP consumes
   additional network bandwidth along the entire LSP paths.  The impact
   on network efficiency can be significant in case of large P2MP
   deployments.  In addition, the backup LSP often has to be manually
   constructed so that the backup P2MP LSP does not route through the
   unprotected ingress node, and it has to be linked to the primary LSP
   logically at the head-end to allow the fast switching in case of
   ingress failure.

   The second method extends the existing ways of protecting an
   intermediate node of a P2P LSP to protect an ingress node of a P2MP
   LSP.  The disadvantages of this method include extra work for
   refreshing PATH messages and processing RESV messages for the P2MP
   LSP in the backup ingress node.

   This document defines extensions to RSVP-TE for locally protecting an
   ingress node of a Traffic Engineered (TE) point-to-multipoint (P2MP)
   Label Switched Path (LSP) through using a backup P2MP sub tree.  The
   new method overcomes the disadvantages described above.  It can also
   be applied for protecting an ingress node of a TE point-to-point
   (P2P) LSP since a TE P2P LSP can be considered as a special case of a
   TE P2MP LSP.






Chen, et al.           Expires September 14, 2012               [Page 3]


Internet-Draft         P2MP LSP Ingress Protection            March 2012


2.  Terminology

   This document uses terminologies defined in RFC2205, RFC3031,
   RFC3209, RFC3473, RFC4090, RFC4461, and RFC4875.


3.  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.


4.  Mechanism

   This section briefly describes a solution that locally protects an
   ingress node of a P2MP LSP through using a backup P2MP sub tree.  We
   start with a simple example, and then present different parts of the
   solution, which includes the creation of the backup P2MP sub tree,
   the forwarding state for the backup P2MP sub tree, and the detection
   of a failure in the ingress node.

4.1.  An Example of Ingress Local Protection

   Figure 1 below illustrates an example of using a backup P2MP sub tree
   to locally protect the ingress of a P2MP LSP.  The P2MP LSP to be
   protected is from ingress node R1 to three egress/leaf nodes: L1, L2
   and L3.  The backup P2MP sub tree used to protect the ingress node R1
   is from backup ingress node Ra to the next hop nodes R2 and R4 of the
   ingress node R1 along the P2MP LSP.

   The traffic from source S may be delivered to both R1 and Ra.  R1
   introduces the traffic into the P2MP LSP, which is sent to the
   egress/leaf nodes L1, L2 and L3 along the P2MP LSP.  Ra normally does
   not put the traffic into the backup P2MP sub tree, which is from Ra
   to R2 and R4.

   There may be a BFD session between ingress node R1 and backup ingress
   node Ra.  Ra uses this BFD session to detect the failure of ingress
   R1.  When Ra detects the failure of R1, it imports the traffic from
   the source S into the backup P2MP sub tree.  The traffic from the sub
   tree is merged into the P2MP LSP at R2 and R4, and then sent to the
   egress/leaf nodes L1, L2 and L3 along the P2MP LSP.  The time for
   switching the traffic after R1 fails is within tens of milliseconds.







Chen, et al.           Expires September 14, 2012               [Page 4]


Internet-Draft         P2MP LSP Ingress Protection            March 2012


                         [R2]======[R3]=====[L1]
                        // |
                       //  |
                      //   |
                     //    |
                    //     /
                   //     /
                  //     /
              +---[R1]======[R4]====[R5]=====[L2]
              |   !    /      /      \\
              |   !   /      /        \\
         [S]--|   !  /      /          \\
              |   ! /      /            \\
              |   !/      /              \\
              +---[Ra]---[Rb]             \\
                                           \\
                                            \\
                                             [L3]


          Figure 1: P2MP sub Tree for Locally Protecting Ingress

   After the failure of the ingress node R1, the refresh of the PATH
   messages for the ingress node is not needed.  Each of the next-hop
   nodes of the ingress node will receive the PATH messages and the
   refresh of the PATH messages for the backup P2MP sub tree from the
   backup ingress node Ra, which make the P2MP LSP alive.

4.2.  Set up of Backup P2MP sub Tree

   For the ingress node of the P2MP LSP, a backup ingress node is
   designated to protect it.  The ingress node sends the P2MP LSP
   information to the backup ingress node.  The backup ingress node
   initiates the creation of the backup P2MP sub tree from itself to the
   next-hop nodes of the ingress node.

   The backup ingress node sets up the backup P2MP sub tree in a way
   similar to setting up a P2MP tree or LSP from the signaling's point
   of view.  It constructs and sends RSVP-TE PATH messages along the
   path for the backup P2MP sub tree with the final destinations (i.e,
   egress/leaf nodes) matching the P2MP LSP.  It receives and processes
   RSVP-TE RESV messages that response to the PATH messages.

4.3.  Forwarding State for Backup P2MP sub Tree

   The forwarding state for the backup P2MP sub tree is different from
   that for a P2MP LSP.  After receiving the RSVP-TE RESV messages for
   the backup P2MP sub tree, the backup ingress node creates a



Chen, et al.           Expires September 14, 2012               [Page 5]


Internet-Draft         P2MP LSP Ingress Protection            March 2012


   forwarding entry with an inactive state or flag.  This forwarding
   entry with an inactive state or flag is called an inactive forwarding
   entry.  In a normal operation, this inactive forwarding entry is not
   used to forward any data traffic to be transported by the P2MP LSP,
   even though the data traffic may be delivered to the backup ingress
   node from an external node such as source node S in the above example
   or network.  The forwarding entry for the P2MP LSP is with an active
   state or flag.  Thus when the data traffic from the external node or
   network reaches the ingress node of the P2MP LSP, it is imported into
   the P2MP LSP tunnel through the active forwarding entry on the
   ingress node.

   When the ingress node fails, the inactive forwarding entry on the
   backup ingress node is changed to active.  Thus when the data traffic
   from the external node reaches the backup ingress node, it is
   imported into the backup P2MP sub tree.  When the traffic arrives at
   the next-hop nodes through the backup P2MP sub tree, it is merged
   into the P2MP LSP to be transported to the destinations.

4.4.  Detection of Failure around Ingress

   There can be two different failure scenarios involving the ingress
   node of a P2MP LSP that need to be detected.

   o  The failure of the ingress node (e.g.  R1 of figure 1).

   o  The failure of the link between the source node and the ingress
      node (e.g. the link between node S and node R1 in figure 1).

   A failure of the ingress node can be detected through a BFD session
   between the ingress node and the backup ingress node in MPLS
   networks.  A failure of the link between the source node and the
   ingress node can be detected by a BFD session running over the link
   and to the backup ingress via the ingress.

   In the GMPLS networks where the control plane and data plane are
   physically separated, the detection and localization of failures in
   the physical layer can be achieved by introducing the link management
   protocol (LMP) or assisting by performance monitoring devices.

   After the backup ingress node detects any failure involving the
   ingress node, it imports the traffic from the source node into the
   backup P2MP sub tree.  The traffic from the backup ingress node via
   the sub tree is merged into the P2MP LSP on the next-hop nodes of the
   ingress of the P2MP LSP, and then transported to the egress/leaf
   nodes of the P2MP LSP.





Chen, et al.           Expires September 14, 2012               [Page 6]


Internet-Draft         P2MP LSP Ingress Protection            March 2012


5.  Ingress Local Protection with FRR

   RFC4875 "Extensions to RSVP-TE for P2MP TE LSPs" describes how to use
   RFC 4090 "Fast Reroute Extensions to RSVP-TE for LSP Tunnels" (FFR
   for short) to locally protect failures in a link or intermediate node
   of a P2MP LSP.  However, there is not any standard that locally
   protects the ingress of the P2MP LSP.  The ingress local protection
   mechanism described above fills this gap.  Thus, through using the
   ingress local protection and the FRR, we can locally protect the
   ingress node , all the links and the intermediate nodes of a P2MP
   LSP.  The traffic switchover time is within tens of milliseconds
   whenever the ingress, any of the links and the intermediate nodes of
   the P2MP LSP fails.

   The ingress node of the P2MP LSP can be locally protected through
   using the ingress local protection.  All the links and all the
   intermediate nodes of the P2MP LSP can be locally protected through
   using the FRR.

   RFC 4090 defines fast reroute extensions to RSVP-TE for local
   protection of P2P TE LSP in MPLS networks.  RFC 4090, which is for
   local protection of P2P TE LSP, has a few of limitations or issues
   when it is used for local protection of P2MP TE LSP.

   For example, locally protecting an intermediate node of a P2MP TE LSP
   requires, when the protected node is a branch LSR, a set of P2P Next-
   Next-Hop (NNHOP) Bypass tunnels toward all LSRs downstream to the
   protected node.  When the protected node fails, the PLR has to
   replicate traffic on each of the P2P bypass tunnels.  If there are K
   next-next-hops, this may lead to K times of the traffic on some
   links, which is not acceptable.

   To overcome these limitations, draft "P2MP MPLS-TE Fast Reroute with
   P2MP Bypass Tunnels" proposes extensions to FRR procedures defined in
   RFC4090 to locally protect links and intermediate nodes of a P2MP TE
   LSP with P2MP bypass tunnels.

   Note that the methods for locally protecting all the links and the
   intermediate nodes of a P2MP LSP are out of scope of this document.


6.  LSP Information Message

   LSP information messages are used to transfer the information about a
   P2MP LSP to a backup ingress node from an ingress node.  The
   destination address of the LSP information message is that of the
   backup ingress node.  This section describes the format of an LSP
   information message and processing of the message.  It also discusses



Chen, et al.           Expires September 14, 2012               [Page 7]


Internet-Draft         P2MP LSP Ingress Protection            March 2012


   other approaches for transferring the information about a P2MP LSP to
   a backup ingress from an ingress.

6.1.  Format of LSP Information Message

   The format of a P2MP LSP information message is illustrated below.


      <LSP Information Message> ::=
                          <Common Header> [ <INTEGRITY> ]
                          [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
                          [ <MESSAGE_ID> ]
                          <SESSION> <RSVP_HOP>
                          <TIME_VALUES>
                          [ <EXPLICIT_ROUTE> ]
                          <LABEL_REQUEST>
                          [ <PROTECTION> ]
                          [ <LABEL_SET> ... ]
                          [ <SESSION_ATTRIBUTE> ]
                          [ <NOTIFY_REQUEST> ]
                          [ <ADMIN_STATUS> ]
                          [ <POLICY_DATA> ... ]
                          <sender descriptor>
                          [<S2L sub-LSP descriptor list>]
                          <RECORD_ROUTE>
                          <S2L sub LSP flow descriptor list>


   The formats and values of the objects in a P2MP LSP information
   message are similar to or the same as those of the corresponding
   objects defined in RFC4875.

   The value of the Msg Type field in the common header in the P2MP LSP
   information message will be a new number to be assigned by Internet
   Assigned Numbers Authority (IANA).

6.2.  Processing of LSP Information Message

   Similar to sending an existing RSVP-TE message such as a PATH
   message, the primary ingress MUST send a updated RSVP-TE LSP
   information message to the backup ingress whenever there is a change
   in the RSVP-TE LSP information message.  It MAY send the same RSVP-TE
   LSP information message to the backup ingress every refresh interval
   if there is no change.

   When the backup ingress receives the RSVP-TE LSP information message
   from the primary ingress, it stores the LSP information, constructs
   PATH messages, and sends the PATH messages downstream accordingly.



Chen, et al.           Expires September 14, 2012               [Page 8]


Internet-Draft         P2MP LSP Ingress Protection            March 2012


   If it has not received any RSVP-TE LSP information message for an
   extended period of time (e.g. a cleanup timeout interval) and the BFD
   session between the primary ingress and backup ingress is up, it
   SHALL remove the information about the P2MP LSP, constructs PathTear
   messages, and send the PathTear messages downstream accordingly.

   When the BFD session between the primary ingress and backup ingress
   is down, the backup ingress MUST keep the information about the P2MP
   LSP and the state of the backup P2MP sub tree even though it has not
   received any RSVP-TE LSP information message for an extended period
   of time.  It refreshes the PATH messages downstream for the backup
   P2MP sub tree.

6.3.  Discussions on Other Approaches

   The information about a P2MP LSP may be transferred through other
   approaches from the ingress node of the LSP to the backup ingress
   node.  One approach is to use OSPF Opaque LSA.  The main reason for
   giving up this option is that more parts need to be changed.  Both
   OSPF and RSVP-TE need to be modified.

   On the ingress node, RSVP-TE needs to be changed to send the
   information to OSPF when there is a change on the information about
   the P2MP LSP.  OSPF needs to be changed to receive the information
   about the P2MP LSP from RSVP-TE and distribute the information in
   Opaque LSA to the OSPF on the backup ingress node.

   On the backup ingress node, OSPF needs to be changed to receive the
   information in Opaque LSA from the ingress ndoe and send the
   information to RSVP-TE.  RSVP-TE needs to be changed to receive the
   information about the P2MP LSP from OSPF.


7.  PATH Messages for Backup P2MP sub Tree

   PATH messages for a backup P2MP sub tree has the same format as PATH
   messages for a P2MP LSP defined in RFC 4875.  This section describes
   the construction of the PATH messages for the backup P2MP sub tree,
   which is followed by processing of the PATH messages.

7.1.  Construction of PATH Messages

   When the backup ingress node receives a P2MP LSP information message,
   it checks to see if anything has been changed.  If the message is a
   new message or the information in the message has been changed, then
   the PATH messages for the backup P2MP sub tree are to be constructed
   as follows.




Chen, et al.           Expires September 14, 2012               [Page 9]


Internet-Draft         P2MP LSP Ingress Protection            March 2012


   First, a path to the next-hop nodes of the ingress node HAS to be
   computed.  The path MUST satisfy the constraints for the P2MP LSP and
   not go through the ingress node.

   If a path is computed successfully, then the PATH messages for the
   backup P2MP sub tree are constructed based on the computed path and
   the information message received, and sent downstream accordingly.
   After sending the PATH messages, the backup ingress node receives
   RESV messages from downstream nodes responding to the PATH messages.
   It then processes the RESV messages and creates forwarding state
   based on the information in the RESV messages.

   If a path can not be found, the backup ingress node SHALL tear down
   the backup P2MP sub tree created based the previous information
   message.

   The construction of a PATH message on a backup ingress node for a
   backup P2MP sub tree is similar to the construction of a normal PATH
   message on an ingress node for a P2MP LSP.  It is based on LSP
   information messages and a computed path for the backup P2MP sub
   tree.  The backup ingress node refreshes the PATH message to its
   downstream nodes when the refresh reduction is not enabled.

   The EXPLICIT_ROUTE object and the objects in the S2L sub-LSP
   descriptor list for the PATH message may be constructed through
   combining the path computed to the next-hop nodes of the ingress node
   and the path from the next-hop nodes to the destination nodes of the
   P2MP LSP obtained from the RECORD_ROUTE object and the objects for
   the S2L sub-LSP flow descriptor list in the LSP information messages.

7.2.  Processing of PATH Messages

   The processing of PATH messages on the intermediate nodes and the
   destination nodes along the backup P2MP sub tree is the same as the
   processing of PATH messages for a P2MP LSP.


8.  IANA Considerations

   TBD


9.  Acknowledgement

   The authors would like to thank Richard Li, Rahul Aggarwal, Rob
   Rennison, Neil Harrison, Kannan Sampath, Yimin Shen, Ronhazli Adam
   and Quintin Zhao for their valuable comments and suggestions on this
   draft.



Chen, et al.           Expires September 14, 2012              [Page 10]


Internet-Draft         P2MP LSP Ingress Protection            March 2012


10.  References

10.1.  Normative References

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

   [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
              Considered Useful", BCP 82, RFC 3692, January 2004.

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

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

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

   [RFC4090]  Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
              Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
              May 2005.

   [RFC4461]  Yasukawa, S., "Signaling Requirements for Point-to-
              Multipoint Traffic-Engineered MPLS Label Switched Paths
              (LSPs)", RFC 4461, April 2006.

   [RFC4875]  Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
              "Extensions to Resource Reservation Protocol - Traffic
              Engineering (RSVP-TE) for Point-to-Multipoint TE Label
              Switched Paths (LSPs)", RFC 4875, May 2007.

   [P2MP FRR]
              Le Roux, J., Aggarwal, R., Vasseur, J., and M. Vigoureux,
              "P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels",
              draft-leroux-mpls-p2mp-te-bypass , March 1997.

10.2.  Informative References

   [RFC2702]  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
              McManus, "Requirements for Traffic Engineering Over MPLS",
              RFC 2702, September 1999.



Chen, et al.           Expires September 14, 2012              [Page 11]


Internet-Draft         P2MP LSP Ingress Protection            March 2012


   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, January 2001.


Authors' Addresses

   Huaimo Chen
   Huawei Technologies
   Boston, MA
   USA

   Email: Huaimochen@huawei.com


   Ning So
   Verizon Inc.
   2400 North Glenville Drive
   Richardson, TX  75082
   USA

   Email: Ning.So@verizonbusiness.com


   Autumn Liu
   Ericsson
   CA
   USA

   Email: autumn.liu@ericsson.com


   Olufemi Komolafe
   Cisco Systems
   96 Commercial Street
   Edinburgh,   EH6 6LX
   United Kingdom

   Email: femi@cisco.com












Chen, et al.           Expires September 14, 2012              [Page 12]


Internet-Draft         P2MP LSP Ingress Protection            March 2012


   Lei Liu
   KDDI R&D Lab Inc.
   2-1-15
   Ohara Fujimino-shi, Saitama
   Japan

   Email: le-liu@kddilabs.jp












































Chen, et al.           Expires September 14, 2012              [Page 13]