Request for Comments: 4461 NTT
Category: Informational April 2006
Signaling Requirements for Point-to-Multipoint
Traffic-Engineered MPLS Label Switched Paths (LSPs)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document presents a set of requirements for the establishment
and maintenance of Point-to-Multipoint (P2MP) Traffic-Engineered (TE)
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs).
There is no intent to specify solution-specific details or
application-specific requirements in this document.
The requirements presented in this document not only apply to
packet-switched networks under the control of MPLS protocols, but
also encompass the requirements of Layer Two Switching (L2SC), Time
Division Multiplexing (TDM), lambda, and port switching networks
managed by Generalized MPLS (GMPLS) protocols. Protocol solutions
developed to meet the requirements set out in this document must
attempt to be equally applicable to MPLS and GMPLS.
Table of Contents
1. Introduction ....................................................3
1.1. Non-Objectives .............................................6
2. Definitions .....................................................6
2.1. Acronyms ...................................................6
2.2. Terminology ................................................6
2.2.1. Terminology for Partial LSPs ........................8
2.3. Conventions ................................................9
3. Problem Statement ...............................................9
3.1. Motivation .................................................9
3.2. Requirements Overview ......................................9
4. Detailed Requirements for P2MP TE Extensions ...................11
4.1. P2MP LSP ..................................................11
4.2. P2MP Explicit Routing .....................................12
4.3. Explicit Path Loose Hops and Widely Scoped
Abstract Nodes ............................................13
4.4. P2MP TE LSP Establishment, Teardown, and
Modification Mechanisms ...................................14
4.5. Fragmentation .............................................14
4.6. Failure Reporting and Error Recovery ......................15
4.7. Record Route of P2MP TE LSP ...............................16
4.8. Call Admission Control (CAC) and QoS Control
Mechanism of P2MP TE LSPs .................................17
4.9. Variation of LSP Parameters ...............................17
4.10. Re-Optimization of P2MP TE LSPs ..........................18
4.11. Merging of Tree Branches .................................18
4.12. Data Duplication .........................................19
4.13. IPv4/IPv6 Support ........................................20
4.14. P2MP MPLS Label ..........................................20
4.15. Advertisement of P2MP Capability .........................20
4.16. Multi-Access LANs ........................................21
4.17. P2MP MPLS OAM ............................................21
4.18. Scalability ..............................................21
4.18.1. Absolute Limits ..................................22
4.19. Backwards Compatibility ..................................24
4.20. GMPLS ....................................................24
4.21. P2MP Crankback Routing ...................................25
5. Security Considerations ........................................25
6. Acknowledgements ...............................................26
7. References .....................................................26
7.1. Normative References ......................................26
7.2. Informative References ....................................26
1. Introduction
Existing MPLS traffic engineering (MPLS-TE) allows for strict QoS
guarantees, resource optimization, and fast failure recovery, but it
is limited to point-to-point (P2P) LSPs. There is a desire to
support point-to-multipoint (P2MP) services using traffic-engineered
LSPs, and this clearly motivates enhancements of the base MPLS-TE
tool box in order to support P2MP MPLS-TE LSPs.
A P2MP TE LSP is a TE LSP (per [RFC2702] and [RFC3031]) that has a
single ingress LSR and one or more egress LSRs, and is
unidirectional. P2MP services (that deliver data from a single
source to one or more receivers) may be supported by any combination
of P2P and P2MP LSPs depending on the degree of optimization required
within the network, and such LSPs may be traffic-engineered again
depending on the requirements of the network. Further, multipoint-
to-multipoint (MP2MP) services (which deliver data from more than one
source to one or more receivers) may be supported by a combination of
P2P and P2MP LSPs.
[RFC2702] specifies requirements for traffic engineering over MPLS.
In Section 2, it describes traffic engineering in some detail, and
those definitions are equally applicable to traffic engineering in a
point-to-multipoint service environment. They are not repeated here,
but it is assumed that the reader is fully familiar with them.
Section 3.0 of [RFC2702] also explains how MPLS is particularly
suited to traffic engineering; it presents the following eight
reasons.
1. Explicit label switched paths that are not constrained by the
destination-based forwarding paradigm can be easily created
through manual administrative action or through automated
action by the underlying protocols.
2. LSPs can potentially be maintained efficiently.
3. Traffic trunks can be instantiated and mapped onto LSPs.
4. A set of attributes can be associated with traffic trunks that
modulate their behavioral characteristics.
5. A set of attributes can be associated with resources that
constrain the placement of LSPs and traffic trunks across them.
6. MPLS allows for both traffic aggregation and disaggregation,
whereas classical destination-only-based IP forwarding permits
only aggregation.
7. It is relatively easy to integrate a "constraint-based routing"
framework with MPLS.
8. A good implementation of MPLS can offer significantly lower
overhead than competing alternatives for traffic engineering.
These points are equally applicable to point-to-multipoint traffic
engineering. Points 1 and 7 are particularly important. Note that
point 3 implies that the concept of a point-to-multipoint traffic
trunk is defined and is supported by (or mapped onto) P2MP LSPs.
That is, the traffic flow for a point-to-multipoint LSP is not
constrained to the path or paths that it would follow during
multicast routing or shortest path destination-based routing, but it
can be explicitly controlled through manual or automated action.
Further, the explicit paths that are used may be computed using
algorithms based on a variety of constraints to produce all manner of
tree shapes. For example, an explicit path may be cost-based
[STEINER], shortest path, or QoS-based, or it may use some fair-cost
QoS algorithm.
[RFC2702] also describes the functional capabilities required to
fully support traffic engineering over MPLS in large networks.
This document presents a set of requirements for Point-to-Multipoint
(P2MP) traffic engineering (TE) extensions to Multiprotocol Label
Switching (MPLS). It specifies functional requirements for solutions
to deliver P2MP TE LSPs.
Solutions that specify procedures for P2MP TE LSP setup MUST satisfy
these requirements. There is no intent to specify solution-specific
details or application-specific requirements in this document.
The requirements presented in this document apply equally to packet-
switched networks under the control of MPLS protocols and to packet-
switched, TDM, lambda, and port-switching networks managed by
Generalized MPLS (GMPLS) protocols. Protocol solutions developed to
meet the requirements set out in this document MUST attempt to be
equally applicable to MPLS and GMPLS.
Existing MPLS TE mechanisms such as [RFC3209] do not support P2MP TE
LSPs, so new mechanisms need to be developed. This SHOULD be
achieved with maximum re-use of existing MPLS protocols.
Note that there is a separation between routing and signaling in MPLS
TE. In particular, the path of the MPLS TE LSP is determined by
performing a constraint-based computation (such as CSPF) on a traffic
engineering database (TED). The contents of the TED may be collected
through a variety of mechanisms.
This document focuses on requirements for establishing and
maintaining P2MP MPLS TE LSPs through signaling protocols; routing
protocols are out of scope. No assumptions are made about how the
TED used as the basis for path computations for P2MP LSPs is formed.
This requirements document assumes the following conditions for P2MP
MPLS TE LSP establishment and maintenance:
o A P2MP TE LSP will be set up with TE constraints and will allow
efficient packet or data replication at various branching points in
the network. Although replication is a data plane issue, it is the
responsibility of the control plane (acting in conjunction with the
path computation component) to install LSPs in the network such
that replication can be performed efficiently. Note that the
notion of "efficient" replication is relative and may have
different meanings depending on the objectives (see Section 4.2).
o P2MP TE LSP setup mechanisms must include the ability to add/remove
receivers to/from the P2MP service supported by an existing P2MP TE
LSP.
o Tunnel endpoints of P2MP TE LSP will be modified by adding/removing
egress LSRs to/from an existing P2MP TE LSP. It is assumed that
the rate of change of leaves of a P2MP LSP (that is, the rate at
which new egress LSRs join, or old egress LSRs are pruned) is "not
so high" because P2MP TE LSPs are assumed to be utilized for TE
applications. This issue is discussed at greater length in Section
4.18.1.
o A P2MP TE LSP may be protected by fast error recovery mechanisms to
minimize disconnection of a P2MP service.
o A set of attributes of the P2MP TE LSP (e.g., bandwidth, etc.) may
be modified by some mechanism (e.g., make-before-break, etc.) to
accommodate attribute changes to the P2MP service without impacting
data traffic. These issues are discussed in Sections 4.6 and 4.10.
It is not a requirement that the ingress LSR must control the
addition or removal of leaves from the P2MP tree.
It is this document’s objective that a solution compliant to the
requirements set out in this document MUST operate these P2MP TE
capabilities in a scalable fashion.
1.1. Non-Objectives
For clarity, this section lists some items that are out of scope of
this document.
It is assumed that some information elements describing the P2MP TE
LSP are known to the ingress LSR prior to LSP establishment. For
example, the ingress LSRs know the IP addresses that identify the
egress LSRs of the P2MP TE LSP. The mechanisms by which the ingress
LSR obtains this information is outside the scope of P2MP TE
signaling and so is not included in this document. Other documents
may complete the description of this function by providing automated,
protocol-based ways of passing this information to the ingress LSR.
This document does not specify any requirements for the following
functions.
- Non-TE LSPs (such as per-hop, routing-based LSPs).
- Discovery of egress leaves for a P2MP LSP.
- Hierarchical P2MP LSPs.
- OAM for P2MP LSPs.
- Inter-area and inter-AS P2MP TE LSPs.
- Applicability of P2MP MPLS TE LSPs to service scenarios.
- Specific application or application requirements.
- Algorithms for computing P2MP distribution trees.
- Multipoint-to-point LSPs.
- Multipoint-to-multipoint LSPs.
- Routing protocols.
- Construction of the traffic engineering database.
- Distribution of the information used to construct the traffic
engineering database.
2. Definitions
2.1. Acronyms
P2P: Point-to-point
P2MP: Point-to-multipoint
2.2. Terminology
The reader is assumed to be familiar with the terminology in
[RFC3031] and [RFC3209].
The following terms are defined for use in the context of P2MP TE
LSPs only.
P2MP tree:
The ordered set of LSRs and TE links that comprise the path of a
P2MP TE LSP from its ingress LSR to all of its egress LSRs.
ingress LSR:
The LSR that is responsible for initiating the signaling messages
that set up the P2MP TE LSP.
egress LSR:
One of potentially many destinations of the P2MP TE LSP. Egress
LSRs may also be referred to as leaf nodes or leaves.
bud LSR:
An LSR that is an egress LSR, but also has one or more directly
connected downstream LSRs.
branch LSR:
An LSR that has more than one directly connected downstream LSR.
P2MP-ID (P2ID):
A unique identifier of a P2MP TE LSP, which is constant for the
whole LSP regardless of the number of branches and/or leaves.
source:
The sender of traffic that is carried on a P2MP service supported
by a P2MP LSP. The sender is not necessarily the ingress LSR of
the P2MP LSP.
receiver:
A recipient of traffic carried on a P2MP service supported by a
P2MP LSP. A receiver is not necessarily an egress LSR of the P2MP
LSP. Zero, one, or more receivers may receive data through a
given egress LSR.
2.2.1. Terminology for Partial LSPs
It is convenient to sub-divide P2MP trees for functional and
representational reasons. A tree may be divided in two dimensions:
- A division may be made along the length of the tree. For example,
the tree may be split into two components each running from the
ingress LSR to a discrete set of egress LSRs. Upstream LSRs (for
example, the ingress LSR) may be members of both components.
- A tree may be divided at a branch LSR (or any transit LSR) to
produce a component of the tree that runs from the branch (or
transit) LSR to all egress LSRs downstream of this point.
These two methods of splitting the P2MP tree can be combined, so it
is useful to introduce some terminology to allow the partitioned
trees to be clearly described.
Use the following designations:
Source (ingress) LSR - S
Leaf (egress) LSR - L
Branch LSR - B
Transit LSR - X (any single, arbitrary LSR that is not a source,
leaf or branch)
All - A
Partial (i.e., not all) - P
Define a new term:
Sub-LSP:
A segment of a P2MP TE LSP that runs from one of the LSP’s LSRs
to one or more of its other LSRs.
Using these new concepts, we can define any combination or split of
the P2MP tree. For example:
S2L sub-LSP:
The path from the source to one specific leaf.
S2PL sub-LSP:
The path from the source to a set of leaves.
B2AL sub-LSP:
The path from a branch LSR to all downstream leaves.
X2X sub-LSP:
A component of the P2MP LSP that is a simple path that does not
branch.
Note that the S2AL sub-LSP is equivalent to the P2MP LSP.
2.3. Conventions
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 [RFC2119].
3. Problem Statement
3.1. Motivation
As described in Section 1, traffic engineering and constraint-based
routing (including Call Admission Control (CAC), explicit source
routing, and bandwidth reservation) are required to enable efficient
resource usage and strict QoS guarantees. Such mechanisms also make
it possible to provide services across a congested network where
conventional "shortest path first" forwarding paradigms would fail.
Existing MPLS TE mechanisms [RFC3209] and GMPLS TE mechanisms
[RFC3473] only provide support for P2P TE LSPs. While it is possible
to provide P2MP TE services using P2P TE LSPs, any such approach is
potentially suboptimal since it may result in data replication at the
ingress LSR, or in duplicate data traffic within the network.
Hence, to provide P2MP MPLS TE services in a fully efficient manner,
it is necessary to specify specific requirements. These requirements
can then be used when defining mechanisms for the use of existing
protocols and/or extensions to existing protocols and/or new
protocols.
3.2. Requirements Overview
This document states basic requirements for the setup of P2MP TE
LSPs. The requirements apply to the signaling techniques only, and
no assumptions are made about which routing protocols are run within
the network, or about how the information that is used to construct
the Traffic Engineering Database (TED) is distributed. These factors
are out of the scope of this document.
A P2MP TE LSP path computation will take into account various
constraints such as bandwidth, affinities, required level of
protection and so on. The solution MUST allow for the computation of
P2MP TE LSP paths that satisfy constraints, with the objective of
supporting various optimization criteria such as delays, bandwidth
consumption in the network, or any other combinations. This is
likely to require the presence of a TED, as well as the ability to
signal the explicit path of an LSP.
A desired requirement is also to maximize the re-use of existing MPLS
TE techniques and protocols where doing so does not adversely impact
the function, simplicity, or scalability of the solution.
This document does not restrict the choice of signaling protocol used
to set up a P2MP TE LSP, but note that [RFC3468] states
...the consensus reached by the Multiprotocol
Label Switching (MPLS) Working Group within the IETF to focus its
efforts on "Resource Reservation Protocol (RSVP)-TE: Extensions to
RSVP for Label-Switched Paths (LSP) Tunnels" (RFC 3209) as the MPLS
signalling protocol for traffic engineering applications...
The P2MP TE LSP setup mechanism MUST include the ability to
add/remove egress LSRs to/from an existing P2MP TE LSP and MUST allow
for the support of all the TE LSP management procedures already
defined for P2P TE LSP. Further, when new TE LSP procedures are
developed for P2P TE LSPs, equivalent or identical procedures SHOULD
be developed for P2MP TE LSPs.
The computation of P2MP trees is implementation dependent and is
beyond the scope of the solutions that are built with this document
as a guideline.
Consider the following figure.
Source 1 (S1)
|
I-LSR1
| |
| |
R2----E-LSR3--LSR1 LSR2---E-LSR2--Receiver 1 (R1)
| :
R3----E-LSR4 E-LSR5
| :
| :
R4 R5
Figure 1
Figure 1 shows a single ingress LSR (I-LSR1), and four egress LSRs
(E-LSR2, E-LSR3, E-LSR4, and E-LSR5). I-LSR1 is attached to a
traffic source that is generating traffic for a P2MP application.
Receivers R1, R2, R3, and R4 are attached to E-LSR2, E-LSR3, and
E-LSR4.
The following are the objectives of P2MP LSP establishment and use.
a) A P2MP tree that satisfies various constraints is pre-
determined, and details are supplied to I-LSR1.
Note that no assumption is made about whether the tree is
provided to I-LSR1 or computed by I-LSR1. The solution SHOULD
also allow for the support of a partial path by means of loose
routing.
Typical constraints are bandwidth requirements, resource class
affinities, fast rerouting, and preemption. There should not
be any restriction on the possibility of supporting the set of
constraints already defined for point-to-point TE LSPs. A new
constraint may specify which LSRs should be used as branch LSRs
for the P2MP LSR in order to take into account LSR capabilities
or network constraints.
b) A P2MP TE LSP is set up from I-LSR1 to E-LSR2, E-LSR3, and
E-LSR4 using the tree information.
c) In this case, the branch LSR1 should replicate incoming packets
or data and send them to E-LSR3 and E-LSR4.
d) If a new receiver (R5) expresses an interest in receiving
traffic, a new tree is determined, and a B2L sub-LSP from LSR2
to E-LSR5 is grafted onto the P2MP TE LSP. LSR2 becomes a
branch LSR.
4. Detailed Requirements for P2MP TE Extensions
4.1. P2MP LSP
The P2MP TE extensions MUST be applicable to the signaling of LSPs
for different switching types. For example, it MUST be possible to
signal a P2MP TE LSP in any switching medium, whether it is packet or
non-packet based (including frame, cell, TDM, lambda, etc.).
As with P2P MPLS technology [RFC3031], traffic is classified with a
FEC in this extension. All packets that belong to a particular FEC
and that travel from a particular node MUST follow the same P2MP
tree.
In order to scale to a large number of branches, P2MP TE LSPs SHOULD
be identified by a unique identifier (the P2MP ID or P2ID) that is
constant for the whole LSP regardless of the number of branches
and/or leaves.
4.2. P2MP Explicit Routing
Various optimizations in P2MP tree formation need to be applied to
meet various QoS requirements and operational constraints.
Some P2MP applications may request a bandwidth-guaranteed P2MP tree
that satisfies end-to-end delay requirements. And some operators may
want to set up a cost-minimum P2MP tree by specifying branch LSRs
explicitly.
The P2MP TE solution therefore MUST provide a means of establishing
arbitrary P2MP trees under the control of an external tree
computation process, path configuration process, or dynamic tree
computation process located on the ingress LSR. Figure 2 shows two
typical examples.
A A
| / \
B B C
| / \ / \