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]