Internet DRAFT - draft-shen-pce-lsp-setup-association

draft-shen-pce-lsp-setup-association







Internet Engineering Task Force                               Yimin Shen
Internet-Draft                                          Juniper Networks
Intended status: Standards Track                         October 8, 2014
Expires: April 11, 2015


       Stateful PCE Initiated LSP Setup Using Association Groups
                draft-shen-pce-lsp-setup-association-00

Abstract

   This document describes a hierarchical model for stateful PCE-
   initiated LSPs, based on the PCE association group mechanism.  It
   defines two new association types, and introduces a generic mechanism
   for stateful PCE to use P2P LSPs as component LSPs (i.e. sub-LSPs) to
   construct and set up TE LSPs with complex path topology, including
   P2MP, MP2P, and MP2MP TE LSPs.

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 11, 2015.

Copyright Notice

   Copyright (c) 2014 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 document must
   include Simplified BSD License text as described in Section 4.e of




Yimin Shen               Expires April 11, 2015                 [Page 1]

Internet-DrafStateful PCE Initiated LSP Setup Using Associa October 2014


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Theory of operation . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Downstream replication association  . . . . . . . . . . .   4
       3.1.1.  Group of ingress LSPs . . . . . . . . . . . . . . . .   4
       3.1.2.  Group of transit and ingress LSPs . . . . . . . . . .   5
       3.1.3.  Group of a single egress LSP and other LSPs . . . . .   6
     3.2.  Downstream merge association  . . . . . . . . . . . . . .   7
   4.  PCEP extensions . . . . . . . . . . . . . . . . . . . . . . .   8
   5.  PCE-initiated LSPs in a hierarchical model  . . . . . . . . .   9
     5.1.  Branch-node initiated P2MP TE LSPs  . . . . . . . . . . .  10
     5.2.  MP2P TE LSPs  . . . . . . . . . . . . . . . . . . . . . .  13
     5.3.  MP2MP TE LSPs . . . . . . . . . . . . . . . . . . . . . .  15
     5.4.  Other considerations  . . . . . . . . . . . . . . . . . .  18
   6.  Failure protection  . . . . . . . . . . . . . . . . . . . . .  18
   7.  OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  19
   8.  IANA considerations . . . . . . . . . . . . . . . . . . . . .  19
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  19
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  19
     11.2.  Informative References . . . . . . . . . . . . . . . . .  20
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  20

1.  Introduction

   [RFC 5440] describes the Path Computation Element Protocol (PCEP) for
   computation of Traffic Engineering Label Switched Path (TE LSP).
   Stateful PCE [ietf-pce-stateful-pce] specifies a set of extensions to
   PCEP to enable stateful control of TE LSPs for PCE.  PCE-initiated
   LSP [ietf-pce-pce-initiated-lsp] specifies the operation model for TE
   LSPs that are initiated from PCE.

   PCE association group [draft-minei-pce-association-group] further
   introduces a generic mechanism for creating a grouping of LSPs.  This
   grouping can then be used to define associations between sets of LSPs
   or between a set of LSPs and a set of attributes.

   This document defines two new association types, namely "downstream
   replication" and "downstream merge", for the PCE association group
   mechanism.  It introduces a generic mechanism for using PCE-initiate
   P2P LSPs as component LSPs (i.e. sub-LSPs) to construct and set up
   PCE-initiated LSPs with more complex path topologies, including P2MP,



Yimin Shen               Expires April 11, 2015                 [Page 2]

Internet-DrafStateful PCE Initiated LSP Setup Using Associa October 2014


   MP2P, and MP2MP TE LSPs.  This mechanism is applicable to PCE-
   initiated TE LSPs.  It adds a hierarchical model for PCE-initiated TE
   LSPs.

2.  Motivation

   The motivation of this document is to introduce a hierarchical model
   for stateful PCE-initiated LSPs, based on the PCE-initiated LSP
   [ietf-pce-pce-initiated-lsp] and the PCE association group mechanism
   [draft-minei-pce-association-group].  The mechanism uses P2P LSPs as
   component LSPs (i.e. sub-LSPs) to set up TE LSPs with more complex
   path topology, including P2MP, MP2P, and MP2MP TE LSPs.

3.  Theory of operation

   PCE association group [draft-minei-pce-association-group] describes a
   generic mechanism for creating a grouping of LSPs.  Base on this
   mechanism, this document introduces two new association types:

      - Downstream replication

      - Downstream merge

   With the new associations, a stateful PCE can use uni-directional and
   bi-directional P2P LSPs as component LSPs (i.e. sub-LSPs) to
   construct TE LSPs with complex path topology, including P2MP, MP2P,
   and full-mesh and partial-mesh MP2MP TE LSPs.  Specifically, the PCE
   can first set up P2P sub-LSPs, and then apply the associations to
   create desired forwarding state for the complex LSPs.  In other
   words, these complex LSPs are established as a group of associated
   P2P sub-LSPs in a hierarchical manner.  These LSPs and their sub-LSPs
   are both PCE-initiated LSPs.

   Each association group will create certain forwarding state on a PCC,
   e.g. a set of forwarding entries, each with a set of nexthops.  The
   forwarding state remains stable during the lifetime of the
   association group.  In any case where there is change to the
   relationship between member LSPs which will cause the forwarding
   state to change, the PCE SHOULD create a new association group to
   replace the old association group.

   Note that all the sub-LSPs in this document are independent P2P LSPs.
   They are not required to correlate with each other via RSVP
   LSP_TUNNEL_IPv4/6 SESSION, LSP_TUNNEL_IPv4/6 SENDER_TEMPLATE,
   P2MP_LSP_TUNNEL_IPv4/6 SESSION, or P2MP_LSP_TUNNEL_IPv4/6
   SENDER_TEMPLATE object [RFC 3209, RFC 4857].  Their relationships are
   formed by association groups at PCE level.




Yimin Shen               Expires April 11, 2015                 [Page 3]

Internet-DrafStateful PCE Initiated LSP Setup Using Associa October 2014


   This section describes the nodal behaviors of these new associations,
   when they are applied to a group of LSPs on a node.  Section 5 will
   describe a framework in a network scope how stateful PCE can use
   these associations while coordinating multiple nodes to set up
   complex LSPs.

   Currently PCE association group [draft-minei-pce-association-group]
   only supports association groups for ingress LSPs.  This document
   extends it to support association groups for transit and egress LSPs
   as well.

3.1.  Downstream replication association

   A downstream replication association group may include a number of
   ingress, transit and egress P2P LSPs.  It allows a router (i.e.  PCC)
   to create forwarding state with a so-called "flood nexthop", so that
   outgoing packets are replicated to and label-switched over every
   ingress and transit LSPs of the group.  Note that not all
   combinations of ingress, transit and egress P2P LSPs are meaningful
   for forwarding.  This document only considers the following specific
   combinations.

3.1.1.  Group of ingress LSPs

   In this scenario, the group includes purely ingress LSPs.  The
   following example shows two P2P LSPs, A-B-C and A-D-E, and the label
   allocation schema at node A.  Both LSPs are ingress LSPs at node A.



                               ----B-----C
                              /
                             A
                              \
                               ----D-----E



                     LSP      in-label     out-label
                     --------------------------------
                     A-B-C       -            100
                     A-D-E       -            200


                                 Figure 1

   When downstream replication association is applied to the LSPs at
   node A, node A should create the following forwarding entry with a



Yimin Shen               Expires April 11, 2015                 [Page 4]

Internet-DrafStateful PCE Initiated LSP Setup Using Associa October 2014


   flood nexthop.  Thus, outgoing packets will be replicated and label-
   switched along both LSPs.



                  in-label     out-label   out-interface
                  ---------------------------------------
                     -           100           to-B
                                 200           to-D


                                 Figure 2

3.1.2.  Group of transit and ingress LSPs

   In this scenario, the group may include [1, n) transit LSPs and [0,
   n) ingress LSPs, but no egress LSP.  One transit LSP MUST be
   designated to have its incoming packets replicated to every other
   LSPs of the group, in addition to being label-switched along the
   transit LSP itself.  If there are multiple transit LSPs in the group,
   the designated LSP MUST be marked by a "Designated in-LSP" flag of
   the Type-Specific Flags in Association object, defined in Section 4.
   Incoming packets on other transit LSPs are discarded.

   The following example shows three P2P LSPs, A-B-C-D, E-B-F-G, and
   B-X-Y, and the label allocation schema at node B.  At node B, LSP
   A-B-C-D and E-B-F-G are transit LSPs, and LSP B-X-Y is a ingress LSP.



                                   ---F-----G
                                  /
                                 /
                          A-----B-----C-----D
                               / \
                              /   \
                          E---     ---X-----Y



                     LSP       in-label     out-label
                     ---------------------------------
                     A-B-C-D     100           200
                     E-B-F-G     300           400
                     B-X-Y        -            500


                                 Figure 3



Yimin Shen               Expires April 11, 2015                 [Page 5]

Internet-DrafStateful PCE Initiated LSP Setup Using Associa October 2014


   When downstream replication association is applied to the LSPs at
   node B, with LSP A-B-C-D specified as the designated in-LSP, node B
   should create the following forwarding entry for label 100 with a
   flood nexthop, and discard entry for label 300.  Thus, packets
   received on LSP A-B-C-D will be replicated and label-switched along
   all LSPs.



                 in-label     out-label   out-interface
                 ----------------------------------------
                 100            200           to-C
                                400           to-F
                                500           to-X
                 300               __discard__


                                 Figure 4

3.1.3.  Group of a single egress LSP and other LSPs

   In this scenario, the group includes a single egress LSP, [0, n)
   transit LSPs, and [0, n) ingress LSPs.  The egress LSP must be UHP
   (ultimate hop popping).  Incoming packets on the egress LSP are
   replicated to and label-switched along every other LSPs of the group.
   Incoming packets on the transit LSPs are discarded.

   The following example shows four P2P LSPs, A-B-C, C-D-E, F-G-C-H-I,
   and C-X-Y, and the label allocation schema at node C.  LSP A-B-C is a
   UHP LSP, and an egress LSP at node C.  LSP C-D-E and C-X-Y are both
   ingress LSPs at node C.  LSP F-G-C-H-I is a transit LSP at node C.




















Yimin Shen               Expires April 11, 2015                 [Page 6]

Internet-DrafStateful PCE Initiated LSP Setup Using Associa October 2014


                                    ---H-----I
                                   /
                                  /
                     A-----B-----C-----D-----E
                                / \
                               /   \
                     F-----G---     ---X-----Y


                     LSP      in-label     out-label
                     --------------------------------
                     A-B-C      100            -
                     C-D-E       -            200
                     C-X-Y       -            300
                     F-G-C-H-I  400           500


                                 Figure 5

   When downstream replication association is applied to the LSPs at
   node C, node C should create the following forwarding entry for label
   100 with a flood nexthop, and discard entry for label 400.  Thus,
   packets received on LSP A-B-C will be replicated and label-switched
   along the other LSPs.



                  in-label     out-label   out-interface
                  ---------------------------------------
                  100            200           to-D
                                 300           to-X
                                 500           to-H
                  400               __discard__


                                 Figure 6

3.2.  Downstream merge association

   An downstream merge association group includes a single transit P2P
   LSP, [1, n) egress P2P LSPs, and no ingress LSP.  All the egress LSPs
   must be UHP.  This type of association group allows a router (i.e.
   PCC) to set up forwarding state in such a fashion that packets
   received on any LSP of the group will be label-switched along that
   transit LSP.  In other words, multiple incoming flows from upstream
   are merged into a single flow downstream.





Yimin Shen               Expires April 11, 2015                 [Page 7]

Internet-DrafStateful PCE Initiated LSP Setup Using Associa October 2014


   The following example shows two P2P LSPs, A-B-C-D and X-Y-B, and the
   label allocation schema at node B.  Note that LSP X-Y-B is a UHP LSP
   in this case.



                          A-----B-----C-----D
                                |
                                |
                          X-----Y


                     LSP      in-label     out-label
                     --------------------------------
                     A-B-C-D    100           200
                     B-X-Y      300            -


                                 Figure 7

   When downstream merge association is applied the LSPs at node B, B
   should then create the following forwarding entries.  Thus, incoming
   packets on both LSPs will be label-switched downstream along LSP
   A-B-C-D.



                  in-label     out-label   out-interface
                  ---------------------------------------
                  100            200           to-C
                  300            200           to-C


                                 Figure 8

4.  PCEP extensions

   PCE association group [draft-minei-pce-association-group] defines the
   Association object.  This document defines two new Association types
   for the Association object.  The values of these types are TBD.

      - Downstream Replication

      - Downstream Merge

   For Downstream Replication type, this document also allocates a flag,
   i.e. the Designated in-LSP flag in the Type-specific Flags field.
   When there are more than one transit LSPs in a group (Section 3.1.2),



Yimin Shen               Expires April 11, 2015                 [Page 8]

Internet-DrafStateful PCE Initiated LSP Setup Using Associa October 2014


   this flag MUST be set for the designated transit LSP, whose incoming
   packets should be replicated to every transit and ingress LSPs of the
   group.  There SHOULD be one and only one transit LSP with this flag
   set.

   Per [draft-minei-pce-association-group], the format of the
   Association object for Downstream Replication and Downstream Merge is
   shown Figure-9:



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Type   |  Generic flags    |R| Type-specific flags           |D|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Association group id                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //            Optional TLVs                                    //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                                 Figure 9

      Type - Downstream Replication or Downstream Merge.  Values TBD.

      Generic flags - flags for the association object.  The R flag
      indicating removal from the association group.

      Type-specific flags - specific to the association type.  The D
      flag is defined for Designated in-LSP.

      Association group id - identifier of the association group.

   Error handling for these new association types will be defined in a
   future version of this document.

5.  PCE-initiated LSPs in a hierarchical model

   This section describes a framework for stateful PCE to use the
   downstream replication and downstream merge associations to construct
   and set up TE LSPs with complex path topology in a hierarchical
   manner.








Yimin Shen               Expires April 11, 2015                 [Page 9]

Internet-DrafStateful PCE Initiated LSP Setup Using Associa October 2014


5.1.  Branch-node initiated P2MP TE LSPs

   RSVP P2MP TE LSP is specified by RFC 4857, where a P2MP LSP is
   established by its source node signaling an S2L (source-to-leaf) sub-
   LSP to each leaf node.  This signaling mechanism can be viewed as a
   "source-node initiated" P2MP LSP model.  Stateful PCE for P2MP LSPs
   [draft-palle-pce-stateful-pce-p2mp-04] introduces PCEP extensions to
   support stateful PCE for this model.

   One observation about the source-node initiated P2MP LSP model is
   that the source node must be provisioned with all leaf nodes and
   signal S2L sub-LSPs to all the leaf nodes, regardless of the actual
   number of traffic flows branching out from it.  Similarly, a transit
   router must participate in the signaling of all the S2L sub-LSPs
   traversing it, regardless of the actual number of traffic flows
   branching out from it.  This leaves some room of improvement for
   efficiency.

   With stateful PCE, an alternative P2MP LSP model becomes available.
   It is called "branch-node initiated" P2MP LSP model.  In this model,
   we introduce the notion of "branch-node to leaf" (B2L) sub-LSP, which
   represents a single-path segment of a P2MP LSP that starts from a
   branch node and ends at a leaf node.  The branch node is the headend
   of this B2L sub-LSP, while the leaf node is the tailend.

   Therefore, a P2MP LSP can be viewed as to consist of a set of S2L
   sub-LSPs (called level-1 sub-LSPs) whose ingress is the source node,
   a set of B2L sub-LSPs (i.e. level-2 sub-LSPs) attached to the level-1
   sub-LSPs at some branch nodes, a set of B2L sub-LSPs (i.e. level-3
   sub-LSPs) attached to the level-2 sub-LSPs at some branch nodes, and
   so on.  A branch node is called a level-N branch node (N > 1), if
   some level-N sub-LSPs are attached to a level-(N-1) sub-LSP at this
   node.  The branch node is the ingress node of the level-N sub-LSPs,
   and a transit node of the level-(N-1) sub-LSP.  For example:

















Yimin Shen               Expires April 11, 2015                [Page 10]

Internet-DrafStateful PCE Initiated LSP Setup Using Associa October 2014


                        ---------E-----F
                       /
                      /
                     A-----B-----C-----D
                            \
                             \
                              ---G-----H


                     Source node: A
                     Leaf nodes: D, F, H
                     Branch node: B
                     Level-1 sub-LSPs: A-B-C-D, A-E-F
                     Level-2 sub-LSPs: B-G-H


                                 Figure 10

   With this model, a stateful PCE can construct and set up a P2MP LSP
   by two steps.  First, initiate S2L and B2L sub-LSP creation on the
   source node and branch nodes, respectively.  Second, apply downstream
   replication association to the sub-LSPs to create desired flood
   nexthops on those nodes.  Note that the sub-LSPs are not required to
   use P2MP_LSP_TUNNEL_IPv4/6 SESSION or P2MP_LSP_TUNNEL_IPv4/6
   SENDER_TEMPLATE [RFC 4857] to correlate with each other.  Instead,
   they are signaled as independent P2P LSPs.  It is the downstream
   replication association that groups them together explicitly at PCEP
   level.

   The partitioning of a P2MP LSP into sub-LSPs should be performed by
   the stateful PCE as part of P2MP path computation.  Hence, it is
   outside the scope of this document.  Note that for a given P2MP LSP,
   there may be multiple schemas to partition it into sub-LSPs.  After
   the PCE has computed the sub-LSP paths, it sends PCinit messages to
   the source node and branch nodes to for the sub-LSPs.  The source
   node and branch nodes then signal these sub-LSPs independently.
   After the sub-LSPs are set up as indicated by PCrpt messages, the PCE
   sends PCupd messages to the source node and branch nodes to create
   downstream replication association groups.  The PCupd messages MUST
   carry an Association object with the new Downstream Replication
   association type defined in this document.  The Association Group ID
   should be non-0 and unique within each node.  Based on this
   association, the source node MUST build a flood next-hop by combining
   the downstream labels and interfaces of all level-1 sub-LSPs;
   Likewise, each level-N branch node MUST build a flood next-hop for
   the in-label of the level-(N-1) sub-LSP, by combining the downstream
   labels and interfaces of the level-(N-1) and all level-N sub-LSPs.




Yimin Shen               Expires April 11, 2015                [Page 11]

Internet-DrafStateful PCE Initiated LSP Setup Using Associa October 2014


   In the example above, assume the following label allocation schema at
   the source node A and branch node B.



                 Sub-LSP   node   in-label     out-label
                 ----------------------------------------
                 A-B-C-D    A        -           100
                 A-E-F      A        -           200
                 A-B-C-D    B        300         400
                 B-G-H      B        -           500


                                 Figure 11

   After downstream replication association is applied to the sub-LSP on
   node A and B, node A and B will create the following forwarding
   entries with flood nexthop, respectively.



                  Node A:

                  Group ID: 1
                  Members: A-B-C-D, A-E-F

                  in-label     out-label   out-interface
                  ---------------------------------------
                     -           100            to-B
                                 200            to-E

                  Node B:

                  Group ID: 1
                  Members: A-B-C-D, B-G-H

                  in-label     out-label   out-interface
                  ---------------------------------------
                     300         400           to-C
                                 500           to-G


                                 Figure 12

   As shown above, the number of sub-LSPs that a node needs to be aware
   of is the number of traffic flows branching out from it, rather than
   the total number of leaf nodes downstream of it.  This means less




Yimin Shen               Expires April 11, 2015                [Page 12]

Internet-DrafStateful PCE Initiated LSP Setup Using Associa October 2014


   sub-LSPs to maintain in RSVP.  Hence, the overall efficiency and
   scalability of signaling is improved.

5.2.  MP2P TE LSPs

   MP2P RSVP-TE [draft-yasukawa-mpls-mp2p-rsvpte] specifies a mechanism
   and a set of RSVP extensions for signaling MP2P LSPs from multiple
   ingress nodes to a single egress node.  With stateful PCE and PCE
   association group, an alternative MP2P LSP model becomes possible,
   without the need for RSVP extension.  In this model, we call a sub-
   LSP that goes from an ingress node to the egress node an I2E (i.e.
   ingress-to-egress) sub-LSP.  We also introduce the notion of "ingress
   to merge-node" (I2M) sub-LSP.  It refers to a single-path segment of
   an MP2P LSP that starts from an ingress node and ends at a merge
   node.  The ingress node is the headend of this I2M sub-LSP, while the
   merge node is the tailend.

   Therefore, an MP2P LSP can be viewed as to consist of a set of I2E
   sub-LSPs (called level-1 sub-LSPs), a set of I2M sub-LSPs (i.e.
   level-2 sub-LSPs) merged with the I2E sub-LSPs, a set of I2M sub-LSPs
   (i.e. level-3 sub-LSPs) merged with the level-2 sub-LSPs, and so on.
   A merge node is called a level-N merge node (where N > 1), if one or
   multiple level-N sub-LSPs merge with a level-(N-1) sub-LSP at this
   node.  In this case, the merge node is the egress node of the level-N
   sub-LSP(s), while it is a transit node of the level-(N-1) sub-LSP.
   For example:



                         A------B------C------D
                                       |
                                       |
                         E------F------
                                |
                                |
                         G------H


                         Ingress nodes: A, E, G
                         Egress node: D
                         Merge nodes: C, F
                         Level-1 sub-LSP: A-B-C-D
                         Level-2 sub-LSP: E-F-C
                         Level-3 sub-LSP: G-H-F


                                 Figure 13




Yimin Shen               Expires April 11, 2015                [Page 13]

Internet-DrafStateful PCE Initiated LSP Setup Using Associa October 2014


   With this model, a stateful PCE can set up an MP2P LSP by two steps.
   First, initiate sub-LSP creation at every ingress node.  All ingress
   nodes signal I2E and I2M sub-LSPs as independent P2P LSPs.  All I2M
   sub-LSPs are signaled as UHP LSPs.  Second, apply downstream merge
   association to the sub-LSPs at every merge node.  Note that at each
   level-N merge node, there should be one level-(N-1) transit sub-LSP
   and one or multiple level-N egress sub-LSP.  This merge node MUST
   create normal forwarding state for the level-(N-1) transit sub-LSP.
   For each level-N egress sub-LSP, the merge node MUST create
   forwarding state in such a manner that the incoming packets of this
   sub-LSP are also label-switched downstream along the level-(N-1)
   transit sub-LSP.

   The partitioning of an MP2P LSP into sub-LSPs should be performed by
   the stateful PCE as part of MP2P path computation.  Hence, it is
   outside the scope of this document.  Note that for a given MP2P LSP,
   there may be multiple schemas to partition it into sub-LSPs.  After
   the PCE has computed the sub-LSP paths, it sends PCinit messages to
   the ingress nodes.  The ingress nodes then signal these sub-LSPs
   independently.  All I2M sub-LSPs must be signaled as UHP LSPs.  After
   the sub-LSPs are set up as indicated by PCrpt messages, the PCE sends
   PCupd messages to merge nodes to create downstream merge association
   groups.  The PCupd message should carry an Association object with
   the new Downstream Merge association type defined in this document.
   The Association Group ID should be non-0 and unique within each merge
   node.  Each level-N merge node MUST create forwarding state for each
   sub-LSP of the group, using a common nexthop with the downstream
   label and interface of the level-(N-1) transit sub-LSP.

   In the above example, assume the following schema of label allocation
   at merge nodes C and F.



                Sub-LSP   node   in-label     out-label
                -------------------------------------------
                A-B-C-D    C        100      implicit null
                E-F-C      C        200          -
                E-F-C      F        300         200
                G-H-F      F        400          -


                                 Figure 14

   After downstream merge association is applied to the sub-LSPs on node
   C and F, node C and F will create the following forwarding entries,
   respectively.




Yimin Shen               Expires April 11, 2015                [Page 14]

Internet-DrafStateful PCE Initiated LSP Setup Using Associa October 2014


                  Node C:

                  Group ID: 1
                  Members: A-B-C-D, E-F-C

                  in-label     out-label   out-interface
                  ---------------------------------------
                     100         pop            to-D
                     200         pop            to-D

                  Node F:

                  Group ID: 1
                  Members: E-F-C, G-H-F

                  in-label     out-label   out-interface
                  ---------------------------------------
                     300         200           to-C
                     400         200           to-C


                                 Figure 15

5.3.  MP2MP TE LSPs

   RSVP-TE currently doesn't provide a mechanism for signaling MP2MP TE
   LSPs.  An MP2MP LSP may be constructed by setting up separate P2MP
   LSPs from ingress nodes.  However, these P2MP LSPs do not have the
   awareness of each other.  Hence they are unable to share network
   resources on common links or nodes.  Also, the number of sub-LSPs
   needed for an MP2MP LSP is generally bound to the average number of
   ingress nodes multiplied by the average number of egress nodes.  In
   the case of a full-mesh MP2MP LSP with N ingress/egress nodes, this
   number is (N-1)^2.

   With the downstream replication and downstream merge associations, a
   stateful PCE can construct and set up full-mesh and partial-mesh
   MP2MP LSPs by using uni-directional and bi-directional P2P LSPs as
   component LSPs.  The number of P2P LSPs needed can be significantly
   lower than that of the above model using P2MP LSPs.  In some network
   topologies, O(n) may be achievable.

   The idea of constructing an MP2MP LSP is similar to that of P2MP and
   MP2P LSPs.  A stateful PCE computes an MP2MP path, which is normally
   a graph, consisting of a set of nodes and unidirectional and
   bidirectional edges.  The PCE then partitions the graph into a set of
   unidirectional and bidirectional single-path segments, branching out,
   intersecting or merging with each other at some nodes.  These nodes



Yimin Shen               Expires April 11, 2015                [Page 15]

Internet-DrafStateful PCE Initiated LSP Setup Using Associa October 2014


   are generally called stitching nodes in this document.  The algorithm
   for performing such partitioning and identifying the stitching nodes
   is outside the scope of this document.  The stateful PCE then models
   these segments as unidirectional and bidirectional P2P sub-LSPs.
   Note that bidirectional P2P sub-LSPs are not mandatory, because they
   can be achieved by using co-routed unidirectional P2P LSPs.

   The PCE then sends PCinit messages to the ingress nodes and stitching
   nodes to initiate the creation of these sub-LSPs.  The ingress nodes
   and stitching nodes signal the sub-LSPs independently.  All sub-LSPs
   that egress at an stitching node must be signaled as UHP LSPs.  After
   the sub-LSPs are set up as indicated by PCrpt messages, the PCE sends
   PCupd messages to the stitching nodes to create downstream
   replication and downstream merge association groups.  The PCupd
   messages should carry one or multiple Association objects with the
   Downstream Replication or Downstream Merge association type defined
   in this document.  Each stitching node then creates forwarding state
   based on the associations, to achieve the desired forwarding state
   for the MP2MP LSP.

   Consider an example where a stateful PCE has computed the following
   path for a full-mesh MP2MP LSP with three ingress/egress nodes, A, E,
   and F.  The stateful PCE then partitions the path into four
   unidirectional P2P sub-LSPs, i.e.  A-B-C-D-E, E-D-C-B-A, F-G-C, and
   C-G-F.  Alternative, the stateful PCE may partition the path into two
   bi-directional P2P sub-LSPs, i.e.  A-B-C-D-E and C-G-F.  In either
   case, node C is a stitching node, and label allocation for the sub-
   LSPs can remain the same.



                            A-----B-----C-----D-----E
                                        |
                                        |
                                        G
                                        |
                                        |
                                        F

               Ingress/egress nodes: A, E, F
               Sub-LSPs: A-B-C-D-E, E-D-C-B-A, F-G-C, C-G-F
               Stitching node: C


                                 Figure 16

   Assume the following label allocation schema at node C, after the
   sub-LSPs are set up.  In particular, the sub-LSP F-G-C is a UHP LSP.



Yimin Shen               Expires April 11, 2015                [Page 16]

Internet-DrafStateful PCE Initiated LSP Setup Using Associa October 2014


                  Sub-LSP         in-label     out-label
                  ---------------------------------------
                  A-B-C-D-E          101          102
                  E-D-C-B-A          201          202
                  F-G-C              301           -
                  C-G-F               -           402


                                 Figure 17

   The stateful PCE applies the following downstream replication
   association groups to the sub-LSPs at node C.



                       Group ID: 1
                       Members: A-B-C-D-E, C-G-F

                       Group ID: 2
                       Members: E-D-C-B-A, C-G-F

                       Group ID: 3
                       Members: A-B-C-D-E, E-D-C-B-A


                                 Figure 18

   Base on the association groups, node C creates the following
   forwarding entries with flood nexthop.



                In-label      out-label      out-interface
                -------------------------------------------
                101             102             to-D
                                402             to-G
                -------------------------------------------
                201             202             to-B
                                402             to-G
                -------------------------------------------
                301             102             to-D
                                202             to-B


                                 Figure 19






Yimin Shen               Expires April 11, 2015                [Page 17]

Internet-DrafStateful PCE Initiated LSP Setup Using Associa October 2014


5.4.  Other considerations

   It is expected that not all routers in a network can act as PCC or
   support the mechanism in this document.  A PCE SHOULD use the set of
   routers that support this mechanism as a constraint in path
   computation, and only use these routers as branch, merge, and
   stitching nodes.

   When there is a change to the path topology of an LSP, a PCE may
   perform an incremental modification on the LSP, by adding a set of
   new sub-LSPs and association groups, and deleting a set of existing
   sub-LSPs and association groups that are no longer valid.
   Alternatively, the PCE may simply create new sub-LSPs and association
   groups for the entire LSP as a new LSP, and replace the existing LSP
   in a make-before-break fashion.

6.  Failure protection

   Several strategies can be used provide link and node failure
   protection for LSPs set up by the mechanism in this document.

   The first strategy is based on the fast re-route (aka. local repair)
   specified in RFC 4090.  This is driven by routers at PLR (point of
   local repair) using pre-installed backup forwarding state, and has
   the advantage of fast reaction.  It is suitable for protection
   against link failures and non-branch/merge/stitching node failures.
   On an LSP set up by the mechanism in this document, each link is
   traversed in each direction by one and only one sub-LSP; Likewise,
   each non-branch/merge/stitching node is traversed in each direction
   by one and only one sub-LSP.  Therefore, protecting the LSP against a
   link failure or non-branch/merge/stitching node failure is no
   different than protecting a single sub-LSP against that failure.

   The second strategy is global repair driven by PCE.  A PCE computes
   an alternative P2MP, MP2P or MP2MP path based on the new topology,
   and constructs a new LSP with new sub-LSPs and association groups to
   replace the existing LSP.  This strategy is applicable to protection
   against branch/merge/stitching node failures, where the above fast
   re-reroute is not possible due to PLR's lack of knowledge of
   downstream sub-LSPs to build backup forwarding state.  It can also be
   used for protection against link failure and non-branch/merge/
   stitching node failure, when fast re-reroute is not available.
   However, it is worth noting that a global repair may take time, due
   to path recomputation and LSP reestablishment.







Yimin Shen               Expires April 11, 2015                [Page 18]

Internet-DrafStateful PCE Initiated LSP Setup Using Associa October 2014


7.  OAM

   The operation of OAM including LSP ping will be described in a future
   version of this document.

8.  IANA considerations

   This document requests IANA to allocate values for the Downstream
   Replication association type and Downstream Merge association type
   defined in this document.

9.  Security Considerations

   The security consideration described in [ietf-pce-pce-initiated-lsp]
   and [draft-minei-pce-association-group] apply to this document.
   Additional consideration related to malicious PCE are introduced in
   this document, as the PCE may now modify forwarding state on the PCC
   through downstream replication association and downstream merge
   association.

10.  Acknowledgements

   The author would like to thank David Wood and Colby Barth for their
   kind review and valuable comments.

11.  References

11.1.  Normative References

   [draft-minei-pce-association-group]
              Minei, I., Crabbe, E., Sivabalan, S., Zhang, X., and Y.
              Tanaka, "PCE extensions for establishing relationships
              between sets of LSPs", draft-minei-pce-association-group
              (work in progress), 2014.

   [ietf-pce-pce-initiated-lsp]
              Crabbe, E., Minei, I., Sivabalan, S., and R. Verga, "PCEP
              extensions for PCE-initiated LSP setup in a stateful PCE
              model", draft-ietf-pce-pce-initiated-lsp (work in
              progress), 2014.

   [ietf-pce-stateful-pce]
              Crabbe, E., Minei, I., Medved, J., and R. Verga, "PCEP
              extensions for stateful PCE", draft-ietf-pce-stateful-pce
              (work in progress), 2014.

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



Yimin Shen               Expires April 11, 2015                [Page 19]

Internet-DrafStateful PCE Initiated LSP Setup Using Associa October 2014


   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5440]  Vasseur, JP. and JL. Le Roux, "Path Computation Element
              (PCE) Communication Protocol (PCEP)", RFC 5440, March
              2009.

   [RFC4578]  Johnston, M. and S. Venaas, "Dynamic Host Configuration
              Protocol (DHCP) Options for the Intel Preboot eXecution
              Environment (PXE)", RFC 4578, November 2006.

   [draft-yasukawa-mpls-mp2p-rsvpte]
              Yasukawa, S., "Supporting Multipoint-to-point LSPs in MPLS
              TE", draft-ietf-pce-stateful-pce (work in progress), 2010.

11.2.  Informative References

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

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655, August 2006.

   [RFC4657]  Ash, J. and J. Le Roux, "Path Computation Element (PCE)
              Communication Protocol Generic Requirements", RFC 4657,
              September 2006.

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

Author's Address

   Yimin Shen
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886
   USA

   Phone: +1 9785890722
   Email: yshen@juniper.net








Yimin Shen               Expires April 11, 2015                [Page 20]