From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4461.txt | 1683 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1683 insertions(+) create mode 100644 doc/rfc/rfc4461.txt (limited to 'doc/rfc/rfc4461.txt') 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] + -- cgit v1.2.3