summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4461.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4461.txt')
-rw-r--r--doc/rfc/rfc4461.txt1683
1 files changed, 1683 insertions, 0 deletions
diff --git a/doc/rfc/rfc4461.txt b/doc/rfc/rfc4461.txt
new file mode 100644
index 0000000..284f621
--- /dev/null
+++ b/doc/rfc/rfc4461.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+Network Working Group S. Yasukawa, Ed.
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yasukawa Informational [Page 1]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+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
+
+
+
+
+
+
+
+
+Yasukawa Informational [Page 2]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+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.
+
+
+
+
+Yasukawa Informational [Page 3]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+ 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.
+
+
+
+
+
+
+
+Yasukawa Informational [Page 4]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+ 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.
+
+
+
+
+
+
+
+
+Yasukawa Informational [Page 5]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+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.
+
+
+
+
+Yasukawa Informational [Page 6]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+Yasukawa Informational [Page 7]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+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.
+
+
+
+
+
+
+Yasukawa Informational [Page 8]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+ 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
+
+
+
+Yasukawa Informational [Page 9]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+ 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.
+
+
+
+Yasukawa Informational [Page 10]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+ 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.
+
+
+
+
+
+
+Yasukawa Informational [Page 11]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+ 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
+ | / \ / \
+ C D E F G
+ | / \ / \/ \ / \
+ D--E*-F*-G*-H*-I*-J*-K*--L H I J KL M N O
+
+ Steiner P2MP tree SPF P2MP tree
+
+ Figure 2: Examples of P2MP TE LSP topology
+
+ One example is the Steiner P2MP tree (cost-minimum P2MP tree)
+ [STEINER]. This P2MP tree is suitable for constructing a cost-
+ minimum P2MP tree so as to minimize the bandwidth consumption in the
+ core. To realize this P2MP tree, several intermediate LSRs must be
+ both MPLS data terminating LSRs and transit LSRs (LSRs E, F, G, H, I,
+ J, and K in Figure 2). Therefore, the P2MP TE solution MUST support
+ a mechanism that can set up this kind of bud LSR between an ingress
+ LSR and egress LSRs. Note that this includes constrained Steiner
+ trees that allow for the computation of a minimal cost trees with
+ some other constraints such as a bounded delay between the source and
+ every receiver.
+
+
+
+
+
+
+
+Yasukawa Informational [Page 12]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+ Another example is a CSPF (Constraint Shortest Path First) P2MP tree.
+ By some metric (which can be set upon any specific criteria like the
+ delay, bandwidth, or a combination of those), one can calculate a
+ shortest-path P2MP tree. This P2MP tree is suitable for carrying
+ real-time traffic.
+
+ The solution MUST allow the operator to make use of any tree
+ computation technique. In the former case, an efficient/optimal tree
+ is defined as a minimal cost tree (Steiner tree), whereas in the
+ later case, it is defined as the tree that provides shortest path
+ between the source and any receiver.
+
+ To support explicit setup of any reasonable P2MP tree shape, a P2MP
+ TE solution MUST support some form of explicit source-based control
+ of the P2MP tree that can explicitly include particular LSRs as
+ branch LSRs. This can be used by the ingress LSR to set up the P2MP
+ TE LSP. For instance, a P2MP TE LSP can be represented simply as a
+ whole tree or by its individual branches.
+
+4.3. Explicit Path Loose Hops and Widely Scoped Abstract Nodes
+
+ A P2MP tree is completely specified if all the required branches and
+ hops between a sender and leaf LSR are indicated.
+
+ A P2MP tree is partially specified if only a subset of intermediate
+ branches and hops is indicated. This may be achieved using loose
+ hops in the explicit path, or using widely scoped abstract nodes
+ (that is, abstract nodes that are not simple [RFC3209]) such as IPv4
+ prefixes shorter than 32 bits, or AS numbers. A partially specified
+ P2MP tree might be particularly useful in inter-area and inter-AS
+ situations, although P2MP requirements for inter-area and inter-AS
+ are beyond the scope of this document.
+
+ Protocol solutions SHOULD include a way to specify loose hops and
+ widely scoped abstract nodes in the explicit source-based control of
+ the P2MP tree as defined in the previous section. Where this support
+ is provided, protocol solutions MUST allow downstream LSRs to apply
+ further explicit control to the P2MP tree to resolve a partially
+ specified tree into a (more) completely specified tree.
+
+ Protocol solutions MUST allow the P2MP tree to be completely
+ specified at the ingress LSR where sufficient information exists to
+ allow the full tree to be computed and where policies along the path
+ (such as at domain boundaries) support full specification.
+
+
+
+
+
+
+
+Yasukawa Informational [Page 13]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+ In all cases, the egress LSRs of the P2MP TE LSP must be fully
+ specified either individually or through some collective identifier.
+ Without this information, it is impossible to know where the TE LSP
+ should be routed to.
+
+ In case of a tree being computed by some downstream LSRs (e.g., the
+ case of hops specified as loose hops), the solution MUST provide
+ protocol mechanisms for the ingress LSR of the P2MP TE LSP to learn
+ the full P2MP tree. Note that this information may not always be
+ obtainable owing to policy considerations, but where part of the path
+ remains confidential, it MUST be reported through aggregation (for
+ example, using an AS number).
+
+4.4. P2MP TE LSP Establishment, Teardown, and Modification Mechanisms
+
+ The P2MP TE solution MUST support establishment, maintenance, and
+ teardown of P2MP TE LSPs in a manner that is at least scalable in a
+ linear way. This MUST include both the existence of very many LSPs
+ at once, and the existence of very many destinations for a single
+ P2MP LSP.
+
+ In addition to P2MP TE LSP establishment and teardown mechanisms, the
+ solution SHOULD support a partial P2MP tree modification mechanism.
+
+ For the purpose of adding sub-P2MP TE LSPs to an existing P2MP TE
+ LSP, the extensions SHOULD support a grafting mechanism. For the
+ purpose of deleting a sub-P2MP TE LSPs from an existing P2MP TE LSP,
+ the extensions SHOULD support a pruning mechanism.
+
+ It is RECOMMENDED that these grafting and pruning operations cause no
+ additional processing in nodes that are not along the path to the
+ grafting or pruning node, or that are downstream of the grafting or
+ pruning node toward the grafted or pruned leaves. Moreover, both
+ grafting and pruning operations MUST NOT disrupt traffic currently
+ forwarded along the P2MP tree.
+
+ There is no assumption that the explicitly routed P2MP LSP remains on
+ an optimal path after several grafts and prunes have occurred. In
+ this context, scalable refers to the signaling process for the P2MP
+ TE LSP. The TE nature of the LSP allows that re-optimization may
+ take place from time to time to restore the optimality of the LSP.
+
+4.5. Fragmentation
+
+ The P2MP TE solution MUST handle the situation where a single
+ protocol message cannot contain all the information necessary to
+ signal the establishment of the P2MP LSP. It MUST be possible to
+ establish the LSP in these circumstances.
+
+
+
+Yasukawa Informational [Page 14]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+ This situation may arise in either of the following circumstances.
+
+ a. The ingress LSR cannot signal the whole tree in a single
+ message.
+
+ b. The information in a message expands to be too large (or is
+ discovered to be too large) at some transit node. This may
+ occur because of some increase in the information that needs to
+ be signaled or because of a reduction in the size of signaling
+ message that is supported.
+
+ The solution to these problems SHOULD NOT rely on IP fragmentation of
+ protocol messages, and it is RECOMMENDED to rely on some protocol
+ procedures specific to the signaling solution.
+
+ In the event that fragmented IP packets containing protocol messages
+ are received, it is NOT RECOMMENDED that they are reassembled at the
+ receiving LSR.
+
+4.6. Failure Reporting and Error Recovery
+
+ Failure events may cause egress LSRs or sub-P2MP LSPs to become
+ detached from the P2MP TE LSP. These events MUST be reported
+ upstream as for a P2P LSP.
+
+ The solution SHOULD provide recovery techniques, such as protection
+ and restoration, allowing recovery of any impacted sub-P2MP TE LSPs.
+ In particular, a solution MUST provide fast protection mechanisms
+ applicable to P2MP TE LSP similar to the solutions specified in
+ [RFC4090] for P2P TE LSPs. Note also that no assumption is made
+ about whether backup paths for P2MP TE LSPs should or should not be
+ shared with P2P TE LSPs backup paths.
+
+ Note that the functions specified in [RFC4090] are currently specific
+ to packet environments and do not apply to non-packet environments.
+ Thus, while solutions MUST provide fast protection mechanisms similar
+ to those specified in [RFC4090], this requirement is limited to the
+ subset of the solution space that applies to packet-switched networks
+ only.
+
+ Note that the requirements expressed in this document are general to
+ all MPLS TE P2MP signaling, and any solution that meets them will
+ therefore be general. Specific applications may have additional
+ requirements or may want to relax some requirements stated in this
+ document. This may lead to variations in the solution.
+
+
+
+
+
+
+Yasukawa Informational [Page 15]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+ The solution SHOULD also support the ability to meet other network
+ recovery requirements such as bandwidth protection and bounded
+ propagation delay increase along the backup path during failure.
+
+ A P2MP TE solution MUST support the P2MP fast protection mechanism to
+ handle P2MP applications sensitive to traffic disruption.
+
+ If the ingress LSR is informed of the failure of delivery to fewer
+ than all the egress LSRs, this SHOULD NOT cause automatic teardown of
+ the P2MP TE LSP. That is, while some egress LSRs remain connected to
+ the P2MP tree, it SHOULD be a matter of local policy at the ingress
+ LSR whether the P2MP LSP is retained.
+
+ When all egress LSRs downstream of a branch LSR have become
+ disconnected from the P2MP tree, and some branch LSR is unable to
+ restore connectivity to any of them by means of some recovery or
+ protection mechanisms, the branch LSR MAY remove itself from the P2MP
+ tree provided that it is not also an egress LSR (that is, a bud).
+ Since the faults that severed the various downstream egress LSRs from
+ the P2MP tree may be disparate, the branch LSR MUST report all such
+ errors to its upstream neighbor. An upstream LSR or the ingress LSR
+ can then decide to re-compute the path to those particular egress
+ LSRs around the failure point.
+
+ Solutions MAY include the facility for transit LSRs and particularly
+ branch LSRs to recompute sub-P2MP trees to restore them after
+ failures. In the event of successful repair, error notifications
+ SHOULD NOT be reported to upstream nodes, but the new paths are
+ reported if route recording is in use. Crankback requirements are
+ discussed in Section 4.21.
+
+4.7. Record Route of P2MP TE LSP
+
+ Being able to identify the established topology of P2MP TE LSP is
+ very important for various purposes such as management and operation
+ of some local recovery mechanisms like Fast Reroute [RFC4090]. A
+ network operator uses this information to manage P2MP TE LSPs.
+
+ Therefore, the P2MP TE solution MUST support a mechanism that can
+ collect and update P2MP tree topology information after the P2MP LSP
+ establishment and modification process.
+
+ It is RECOMMENDED that the information is collected in a data format
+ that allows easy recognition of the P2MP tree topology.
+
+ The solution MUST support mechanisms for the recording of both
+ outgoing interfaces and node-ids.
+
+
+
+
+Yasukawa Informational [Page 16]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+ The solution MUST gracefully handle scaling issues concerned with the
+ collection of P2MP tree information, including the case where the
+ collected information is too large to be carried in a single protocol
+ message.
+
+4.8. Call Admission Control (CAC) and QoS Control Mechanism of
+ P2MP TE LSPs
+
+ P2MP TE LSPs may share network resource with P2P TE LSPs. Therefore,
+ it is important to use CAC and QoS in the same way as P2P TE LSPs for
+ easy and scalable operation.
+
+ P2MP TE solutions MUST support both resource sharing and exclusive
+ resource utilization to facilitate coexistence with other LSPs to the
+ same destination(s).
+
+ P2MP TE solutions MUST be applicable to DiffServ-enabled networks
+ that can provide consistent QoS control in P2MP LSP traffic.
+
+ Any solution SHOULD also satisfy the DS-TE requirements [RFC3564] and
+ interoperate smoothly with current P2P DS-TE protocol specifications.
+
+ Note that this requirement document does not make any assumption on
+ the type of bandwidth pool used for P2MP TE LSPs, which can either be
+ shared with P2P TE LSP or be dedicated for P2MP use.
+
+4.9. Variation of LSP Parameters
+
+ Certain parameters (such as priority and bandwidth) are associated
+ with an LSP. The parameters are installed by the signaling exchanges
+ associated with establishing and maintaining the LSP.
+
+ Any solution MUST NOT allow for variance of these parameters within a
+ single P2MP LSP. That is:
+
+ - No attributes set and signaled by the ingress LSR of a P2MP LSP may
+ be varied by downstream LSRs.
+ - There MUST be homogeneous QoS from the root to all leaves of a
+ single P2MP LSP.
+
+ Changing the parameters for the whole tree MAY be supported, but the
+ change MUST apply to the whole tree from ingress LSR to all egress
+ LSRs.
+
+
+
+
+
+
+
+
+Yasukawa Informational [Page 17]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+4.10. Re-Optimization of P2MP TE LSPs
+
+ The detection of a more optimal path (for example, one with a lower
+ overall cost) is an example of a situation where P2MP TE LSP re-
+ routing may be required. While re-routing is in progress, an
+ important requirement is to avoid double bandwidth reservation (over
+ the common parts between the old and new LSP) thorough the use of
+ resource sharing.
+
+ Make-before-break MUST be supported for a P2MP TE LSP to ensure that
+ there is minimal traffic disruption when the P2MP TE LSP is re-
+ routed.
+
+ Make-before-break that only applies to a sub-P2MP tree without
+ impacting the data on all the other parts of the P2MP tree MUST be
+ supported.
+
+ The solution SHOULD allow for make-before-break re-optimization of
+ any subdivision of the P2MP LSP (S2PL sub-LSP, S2X sub-LSP, S2L sub-
+ LSP, X2AL sub-LSP, B2PL sub-LSP, X2AL sub-LSP, or B2AL tree).
+ Further, it SHOULD do so by minimizing the signaling impact on the
+ rest of the P2MP LSP, and without affecting the ability of the
+ management plane to manage the LSP.
+
+ The solution SHOULD also provide the ability for the ingress LSR to
+ have strict control over the re-optimization process. The ingress
+ LSR SHOULD be able to limit all re-optimization to be source-
+ initiated.
+
+ Where sub-LSP re-optimization is allowed by the ingress LSR, such
+ re-optimization MAY be initiated by a downstream LSR that is the root
+ of the sub-LSP that is to be re-optimized. Sub-LSP re-optimization
+ initiated by a downstream LSR MUST be carried out with the same
+ regard to minimizing the impact on active traffic as was described
+ above for other re-optimization.
+
+4.11. Merging of Tree Branches
+
+ It is possible for a single transit LSR to receive multiple signaling
+ messages for the same P2MP LSP but for different sets of
+ destinations. These messages may be received from the same or
+ different upstream nodes and may need to be passed on to the same or
+ different downstream nodes.
+
+ This situation may arise as the result of the signaling solution
+ definition or implementation options within the signaling solution.
+ Further, it may happen during make-before-break re-optimization
+ (Section 4.10).
+
+
+
+Yasukawa Informational [Page 18]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+ It is even possible that it is necessary to construct distinct
+ upstream branches in order to achieve the correct label choices in
+ certain switching technologies managed by GMPLS (for example,
+ photonic cross-connects where the selection of a particular lambda
+ for the downstream branches is only available on different upstream
+ switches).
+
+ The solution MUST support the case where multiple signaling messages
+ for the same P2MP LSP are received at a single transit LSR and refer
+ to the same upstream interface. In this case, the result of the
+ protocol procedures SHOULD be a single data flow on the upstream
+ interface.
+
+ The solution SHOULD support the case where multiple signaling
+ messages for the same P2MP LSP are received at a single transit LSR
+ and refer to different upstream interfaces, and where each signaling
+ message results in the use of different downstream interfaces. This
+ case represents data flows that cross at the LSR but that do not
+ merge.
+
+ The solution MAY support the case where multiple signaling messages
+ for the same P2MP LSP are received at a single transit LSR and refer
+ to different upstream interfaces, and where the downstream interfaces
+ are shared across the received signaling messages. This case
+ represents the merging of data flows. A solution that supports this
+ case MUST ensure that data is not replicated on the downstream
+ interfaces.
+
+ An alternative to supporting this last case is for the signaling
+ protocol to indicate an error such that the merge may be resolved by
+ the upstream LSRs.
+
+4.12. Data Duplication
+
+ Data duplication refers to the receipt by any recipient of duplicate
+ instances of the data. In a packet environment, this means the
+ receipt of duplicate packets. Although small-scale packet
+ duplication (that is, a few packets over a relatively short period of
+ time) should be a harmless (if inefficient) situation, certain
+ existing and deployed applications will not tolerate packet
+ duplication. Sustained packet duplication is, at best, a waste of
+ network and processing resources and, at worst, may cause congestion
+ and the inability to process the data correctly.
+
+ In a non-packet environment, data duplication means the duplication
+ of some part of the signal that may lead to the replication of data
+ or to the scrambling of data.
+
+
+
+
+Yasukawa Informational [Page 19]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+ Data duplication may legitimately arise in various scenarios
+ including re-optimization of active LSPs as described in the previous
+ section, and protection of LSPs. Thus, it is impractical to regulate
+ against data duplication in this document.
+
+ Instead, the solution:
+
+ - SHOULD limit to bounded transitory conditions the cases where
+ network bandwidth is wasted by the existence of duplicate delivery
+ paths.
+
+ - MUST limit the cases where duplicate data is delivered to an
+ application to bounded transitory conditions.
+
+4.13. IPv4/IPv6 Support
+
+ Any P2MP TE solution MUST support IPv4 and IPv6 addressing.
+
+4.14. P2MP MPLS Label
+
+ A P2MP TE solution MUST allow the continued use of existing
+ techniques to establish P2P LSPs (TE and otherwise) within the same
+ network, and MUST allow the coexistence of P2P LSPs within the same
+ network as P2MP TE LSPs.
+
+ A P2MP TE solution MUST be specified in such a way that it allows
+ P2MP and P2P TE LSPs to be signaled on the same interface.
+
+4.15. Advertisement of P2MP Capability
+
+ Several high-level requirements have been identified to determine the
+ capabilities of LSRs within a P2MP network. The aim of such
+ information is to facilitate the computation of P2MP trees using TE
+ constraints within a network that contains LSRs that do not all have
+ the same capability levels with respect to P2MP signaling and data
+ forwarding.
+
+ These capabilities include, but are not limited to:
+
+ - The ability of an LSR to support branching.
+ - The ability of an LSR to act as an egress LSR and a branch LSR for
+ the same LSP.
+ - The ability of an LSR to support P2MP MPLS-TE signaling.
+
+
+
+
+
+
+
+
+Yasukawa Informational [Page 20]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+4.16. Multi-Access LANs
+
+ P2MP MPLS TE may be used to traverse network segments that are
+ provided by multi-access media such as Ethernet. In these cases, it
+ is also possible that the entry point to the network segment is a
+ branch LSR of the P2MP LSP.
+
+ Two options clearly exist:
+
+ - the branch LSR replicates the data and transmits multiple copies
+ onto the segment.
+ - the branch LSR sends a single copy of the data to the segment and
+ relies on the exit points to determine whether to receive and
+ forward the data.
+
+ The first option has a significant data plane scaling issue since all
+ replicated data must be sent through the same port and carried on the
+ same segment. Thus, a solution SHOULD provide a mechanism for a
+ branch LSR to send a single copy of the data onto a multi-access
+ network to reach multiple (adjacent) downstream nodes. The second
+ option may have control plane scaling issues.
+
+4.17. P2MP MPLS OAM
+
+ The MPLS and GMPLS MIB modules MUST be enhanced to provide P2MP TE
+ LSP management in line with whatever signaling solutions are
+ developed.
+
+ In order to facilitate correct management, P2MP TE LSPs MUST have
+ unique identifiers, since otherwise it is impossible to determine
+ which LSP is being managed.
+
+ Further discussions of OAM are out of scope for this document. See
+ [P2MP-OAM] for more details.
+
+4.18. Scalability
+
+ Scalability is a key requirement in P2MP MPLS systems. Solutions
+ MUST be designed to scale well with an increase in the number of any
+ of the following:
+
+ - the number of recipients
+ - the number of egress LSRs
+ - the number of branch LSRs
+ - the number of branches
+
+ Both scalability of control plane operation (setup, maintenance,
+ modification, and teardown) MUST be considered.
+
+
+
+Yasukawa Informational [Page 21]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+ Key considerations MUST include:
+
+ - the amount of refresh processing associated with maintaining a P2MP
+ TE LSP.
+ - the amount of protocol state that must be maintained by ingress and
+ transit LSRs along a P2MP tree.
+ - the number of protocol messages required to set up or tear down a
+ P2MP LSP as a function of the number of egress LSRs.
+ - the number of protocol messages required to repair a P2MP LSP after
+ failure or to perform make-before-break.
+ - the amount of protocol information transmitted to manage a P2MP TE
+ LSP (i.e., the message size).
+ - the amount of additional data distributed in potential routing
+ extensions.
+ - the amount of additional control plane processing required in the
+ network to detect whether an add/delete of a new branch is
+ required, and in particular, the amount of processing in steady
+ state when no add/delete is requested
+ - the amount of control plane processing required by the ingress,
+ transit, and egress LSRs to add/delete a branch LSP to/from an
+ existing P2MP LSP.
+
+ It is expected that the applicability of each solution will be
+ evaluated with regards to the aforementioned scalability criteria.
+
+4.18.1. Absolute Limits
+
+ In order to achieve the best solution for the problem space, it is
+ helpful to clarify the boundaries for P2MP TE LSPs.
+
+ - Number of egress LSRs.
+
+ A scaling bound is placed on the solution mechanism such that a
+ P2MP TE LSP MUST reduce to similar scaling properties as a P2P LSP
+ when the number of egress LSRs reduces to one. That is,
+ establishing a P2MP TE LSP to a single egress LSR should cost
+ approximately as much as establishing a P2P LSP.
+
+ It is important to classify the issues of scaling within the
+ context of traffic engineering. It is anticipated that the initial
+ deployments of P2MP TE LSPs will be limited to a maximum of around
+ a hundred egress LSRs, but that within five years deployments may
+ increase this to several hundred, and that future deployments may
+ require significantly larger numbers.
+
+ An acceptable upper bound for a solution, therefore, is one that
+ scales linearly with the number of egress LSRs. It is expected
+ that solutions will scale better than linearly.
+
+
+
+Yasukawa Informational [Page 22]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+ Solutions that scale worse than linearly (that is, exponentially or
+ polynomially) are not acceptable whatever the number of egress LSRs
+ they could support.
+
+ - Number of branch LSRs.
+
+ Solutions MUST support all possibilities from one extreme of a
+ single branch LSR that forks to all leaves on a separate branch, to
+ the greatest number of branch LSRs which is (n-1) for n egress
+ LSRs. Assumptions MUST NOT be made in the solution regarding which
+ topology is more common, and the solution MUST be designed to
+ ensure scalability in all topologies.
+
+ - Dynamics of P2MP tree.
+
+ Recall that the mechanisms for determining which egress LSRs should
+ be added to an LSP and for adding and removing egress LSRs from
+ that group are out of the scope of this document. Nevertheless, it
+ is useful to understand the expected rates of arrival and departure
+ of egress LSRs, since this can impact the selection of solution
+ techniques.
+
+ Again, this document is limited to traffic engineering, and in this
+ model the rate of change of LSP egress LSRs may be expected to be
+ lower than the rate of change of recipients in an IP multicast
+ group.
+
+ Although the absolute number of egress LSRs coming and going is the
+ important element for determining the scalability of a solution,
+ note that a percentage may be a more comprehensible measure, but
+ that this is not as significant for LSPs with a small number of
+ recipients.
+
+ A working figure for an established P2MP TE LSP is less than 10%
+ churn per day; that is, a relatively slow rate of churn.
+
+ We could say that a P2MP LSP would be shared by multiple multicast
+ groups, so the dynamics of the P2MP LSP would be relatively small.
+
+ Solutions MUST optimize for such relatively low rates of change and
+ are not required to optimize for significantly higher rates of
+ change.
+
+ - Rate of change within the network.
+
+ It is also important to understand the scaling with regard to
+ changes within the network. That is, one of the features of a P2MP
+ TE LSP is that it can be robust or protected against network
+
+
+
+Yasukawa Informational [Page 23]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+ failures, and it can be re-optimized to take advantage of newly
+ available network resources.
+
+ It is more important that a solution be optimized for scaling with
+ respect to recovery and re-optimization of the LSP than for change
+ in the egress LSRs, because P2MP is used as a TE tool.
+
+ The solution MUST follow this distinction and optimize accordingly.
+
+4.19. Backwards Compatibility
+
+ It SHOULD be an aim of any P2MP solution to offer as much backward
+ compatibility as possible. An ideal that is probably impossible to
+ achieve would be to offer P2MP services across legacy MPLS networks
+ without any change to any LSR in the network.
+
+ If this ideal cannot be achieved, the aim SHOULD be to use legacy
+ nodes as both transit non-branch LSRs and egress LSRs.
+
+ It is a further requirement for the solution that any LSR that
+ implements the solution SHALL NOT be prohibited by that act from
+ supporting P2P TE LSPs using existing signaling mechanisms. That is,
+ unless doing so is administratively prohibited, P2P TE LSPs MUST be
+ supported through a P2MP network.
+
+ Also, it is a requirement that P2MP TE LSPs MUST be able to coexist
+ with IP unicast and IP multicast networks.
+
+4.20. GMPLS
+
+ The requirement for P2MP services for non-packet switch interfaces is
+ similar to that for Packet-Switch Capable (PSC) interfaces.
+ Therefore, it is a requirement that reasonable attempts must be made
+ to make all the features/mechanisms (and protocol extensions) that
+ will be defined to provide MPLS P2MP TE LSPs equally applicable to
+ P2MP PSC and non-PSC TE-LSPs. If the requirements of non-PSC
+ networks over-complicate the PSC solution a decision may be taken to
+ separate the solutions.
+
+ Solutions for MPLS P2MP TE-LSPs, when applied to GMPLS P2MP PSC or
+ non-PSC TE-LSPs, MUST be compatible with the other features of GMPLS
+ including:
+
+ - control and data plane separation;
+ - full support of numbered and unnumbered TE links;
+ - use of the arbitrary labels and labels for specific technologies,
+ as well as negotiation of labels, where necessary, to support
+ limited label processing and swapping capabilities;
+
+
+
+Yasukawa Informational [Page 24]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+ - the ability to apply external control to the labels selected on
+ each hop of the LSP, and to control the next hop
+ label/port/interface for data after it reaches the egress LSR;
+ - support for graceful and alarm-free enablement and termination of
+ LSPs;
+ - full support for protection including link-level protection,
+ end-to-end protection, and segment protection;
+ - the ability to teardown an LSP from a downstream LSR, in
+ particular, from the egress LSR;
+ - handling of Graceful Deletion procedures; and
+ - support for failure and restart or reconnection of the control
+ plane without any disruption of the data plane.
+
+ In addition, since non-PSC TE-LSPs may have to be processed in
+ environments where the "P2MP capability" could be limited, specific
+ constraints may also apply during the P2MP TE Path computation.
+ Being technology specific, these constraints are outside the scope of
+ this document. However, technology-independent constraints (i.e.,
+ constraints that are applicable independently of the LSP class)
+ SHOULD be allowed during P2MP TE LSP message processing. It has to
+ be emphasized that path computation and management techniques shall
+ be as close as possible to those being used for PSC P2P TE LSPs and
+ P2MP TE LSPs.
+
+4.21. P2MP Crankback Routing
+
+ P2MP solutions SHOULD support crankback requirements as defined in
+ [CRANKBACK]. In particular, they SHOULD provide sufficient
+ information to a branch LSR from downstream LSRs to allow the branch
+ LSR to re-route a sub-LSP around any failures or problems in the
+ network.
+
+5. Security Considerations
+
+ This requirements document does not define any protocol extensions
+ and does not, therefore, make any changes to any security models.
+
+ It is a requirement that any P2MP solution developed to meet some or
+ all of the requirements expressed in this document MUST include
+ mechanisms to enable the secure establishment and management of P2MP
+ MPLS-TE LSPs. This includes, but is not limited to:
+
+ - mechanisms to ensure that the ingress LSR of a P2MP LSP is
+ identified;
+ - mechanisms to ensure that communicating signaling entities can
+ verify each other's identities;
+ - mechanisms to ensure that control plane messages are protected
+ against spoofing and tampering;
+
+
+
+Yasukawa Informational [Page 25]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+ - mechanisms to ensure that unauthorized leaves or branches are not
+ added to the P2MP LSP; and
+ - mechanisms to protect signaling messages from snooping.
+
+ Note that P2MP signaling mechanisms built on P2P RSVP-TE signaling
+ are likely to inherit all the security techniques and problems
+ associated with RSVP-TE. These problems may be exacerbated in P2MP
+ situations where security relationships may need to maintained
+ between an ingress LSR and multiple egress LSRs. Such issues are
+ similar to security issues for IP multicast.
+
+ It is a requirement that documents offering solutions for P2MP LSPs
+ MUST have detailed security sections.
+
+6. Acknowledgements
+
+ The authors would like to thank George Swallow, Ichiro Inoue, Dean
+ Cheng, Lou Berger, and Eric Rosen for their review and suggestions.
+
+ Thanks to Loa Andersson for his help resolving the final issues in
+ this document and to Harald Alvestrand for a thorough GenArt review.
+
+7. References
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and
+ J. McManus, "Requirements for Traffic Engineering Over
+ MPLS", RFC 2702, September 1999.
+
+ [RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
+ "Multiprotocol Label Switching Architecture", RFC 3031,
+ January 2001.
+
+ [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
+ V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
+ LSP Tunnels", RFC 3209, December 2001.
+
+7.2. Informative References
+
+ [RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label
+ Switching (MPLS) Working Group decision on MPLS
+ signaling protocols", RFC 3468, February 2003.
+
+
+
+
+
+Yasukawa Informational [Page 26]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+ [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
+ (GMPLS) Signaling Resource ReserVation Protocol-Traffic
+ Engineering (RSVP-TE) Extensions", RFC 3473, January
+ 2003.
+
+ [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support
+ of Differentiated Services-aware MPLS Traffic
+ Engineering", RFC 3564, July 2003.
+
+ [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
+ Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
+ 2005.
+
+ [STEINER] H. Salama, et al., "Evaluation of Multicast Routing
+ Algorithm for Real-Time Communication on High-Speed
+ Networks," IEEE Journal on Selected Area in
+ Communications, pp.332-345, 1997.
+
+ [CRANKBACK] A. Farrel, A. Satyanarayana, A. Iwata, N. Fujita, G.
+ Ash, S. Marshall, "Crankback Signaling Extensions for
+ MPLS Signaling", Work in Progress, May 2005.
+
+ [P2MP-OAM] S. Yasukawa, A. Farrel, D. King, and T. Nadeau, "OAM
+ Requirements for Point-to-Multipoint MPLS Networks",
+ Work in Progress, February 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yasukawa Informational [Page 27]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+Editor's Address
+
+ Seisho Yasukawa
+ NTT Corporation
+ 9-11, Midori-Cho 3-Chome
+ Musashino-Shi, Tokyo 180-8585,
+ Japan
+
+ Phone: +81 422 59 4769
+ EMail: yasukawa.seisho@lab.ntt.co.jp
+
+Authors' Addresses
+
+ Dimitri Papadimitriou
+ Alcatel
+ Francis Wellensplein 1,
+ B-2018 Antwerpen,
+ Belgium
+
+ Phone : +32 3 240 8491
+ EMail: dimitri.papadimitriou@alcatel.be
+
+
+ JP Vasseur
+ Cisco Systems, Inc.
+ 300 Beaver Brook Road
+
+ Boxborough, MA 01719,
+ USA
+
+ EMail: jpv@cisco.com
+
+
+ Yuji Kamite
+ NTT Communications Corporation
+ Tokyo Opera City Tower
+ 3-20-2 Nishi Shinjuku, Shinjuku-ku,
+ Tokyo 163-1421,
+ Japan
+
+ EMail: y.kamite@ntt.com
+
+
+
+
+
+
+
+
+
+
+Yasukawa Informational [Page 28]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+ Rahul Aggarwal
+ Juniper Networks
+ 1194 North Mathilda Ave.
+ Sunnyvale, CA 94089
+
+ EMail: rahul@juniper.net
+
+
+ Alan Kullberg
+ Motorola Computer Group
+ 120 Turnpike Rd.
+ Southborough, MA 01772
+ EMail: alan.kullberg@motorola.com
+
+
+ Adrian Farrel
+ Old Dog Consulting
+
+ Phone: +44 (0) 1978 860944
+ EMail: adrian@olddog.co.uk
+
+
+ Markus Jork
+ Quarry Technologies
+ 8 New England Executive Park
+ Burlington, MA 01803
+
+ EMail: mjork@quarrytech.com
+
+
+ Andrew G. Malis
+ Tellabs
+ 2730 Orchard Parkway
+ San Jose, CA 95134
+
+ Phone: +1 408 383 7223
+ EMail: andy.malis@tellabs.com
+
+
+ Jean-Louis Le Roux
+ France Telecom
+ 2, avenue Pierre-Marzin
+ 22307 Lannion Cedex
+ France
+
+ EMail: jeanlouis.leroux@francetelecom.com
+
+
+
+
+
+Yasukawa Informational [Page 29]
+
+RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Yasukawa Informational [Page 30]
+