Network Working Group J.-L. Le Roux Internet Draft T. Morin France Telecom Category: Informational Vincent Parfait Expires: January 2006 Equant Luyuan Fang AT&T Lei Wang Telenor Yuji Kamite NTT Communications Shane Amante Level 3 Communications July 2005 Requirements for multipoint extensions to the Label Distribution Protocol draft-leroux-mpls-mp-ldp-reqs-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Le Roux et al. Reqs for multipoint extensions to LDP [Page 1] Internet Draft draft-leroux-mpls-mp-ldp-reqs-00.txt July 2005 Abstract This document lists a set of functional requirements for Label Distribution Protocol (LDP) extensions for setting up point-to- multipoint (P2MP) and potentially multipoint-to-multipoint (MP2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multi Protocol Label Switching (MPLS) infrastructure. It is intended that solutions that specify LDP procedures for setting up P2MP and MP2MP LSP satisfy these requirements. Conventions used in this document 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 RFC-2119. Table of Contents 1. Terminology.................................................3 2. Introduction................................................4 3. Problem Statement and Requirements Overview.................5 3.1. Problem Statement...........................................5 3.2. Requirements overview.......................................6 4. Application scenarios.......................................6 5. Detailed Requirements.......................................7 5.1. MP LSPs.....................................................7 5.1.1. P2MP LSP....................................................7 5.1.2. MP2MP LSP...................................................7 5.1.3. MP LSP FEC..................................................8 5.2. Setting up, tearing down and modifying MP LSPs..............8 5.3. Label Advertisement.........................................8 5.4. Data Duplication............................................9 5.5. Avoiding loops..............................................9 5.6. MP LSP routing..............................................9 5.7. MP LSP Re-routing...........................................9 5.7.1. Rerouting on a Better Path..................................9 5.7.2. Rerouting due to a Network Failure.........................10 5.7.3. Rerouting Due to Planned Maintenance.......................10 5.8. Support for LAN interfaces.................................10 5.9. Support for encapsulation in P2P and P2MP TE tunnels.......10 5.10. Label spaces...............................................10 5.11. IPv4/IPv6 support..........................................11 5.12. Multi-Area LSPs............................................11 5.13. OAM........................................................11 5.14. Graceful Restart and Fault Recovery........................11 5.15. Robustness.................................................11 5.16. Scalability................................................12 5.16.1. Orders of magnitude of the expected numbers of MP LSPs and leaves per LSP in operational networks...............12 5.17. Backward Compatibility.....................................12 Le Roux et al. Reqs for multipoint extensions to LDP [Page 2] Internet Draft draft-leroux-mpls-mp-ldp-reqs-00.txt July 2005 6. Evaluation criteria........................................12 6.1. Performances...............................................12 6.2. Complexity and Risks.......................................12 7. Security Considerations....................................13 8. Acknowledgment.............................................13 9. References.................................................13 10. Authors' Addresses:........................................14 11. Intellectual Property Statement............................15 1. Terminology LSR: Label Switching Router LSP: MPLS Label Switched Path Ingress LSR: Router acting as a sender of an LSP Egress LSR: Router acting as a receiver of an LSP P2P LSP: A LSP that has one unique Ingress LSR and one unique Egress LSR MP2P LSP: A LSP that has one or more Ingress LSRs and one unique Egress LSR P2MP LSP: A LSP that has one unique Ingress LSR and one or more Egress LSRs MP2MP LSP: A bidirectional LSP connecting a group of two or more LSRs acting equally as Ingress LSR or Egress LSR Leaf LSR: Egress LSR of a P2MP LSP or Ingress/Egress LSR of a MP2MP LSP MP LSP: P2MP LSP or MP2MP LSP Transit LSR: A LSR of a MP LSP that has one or more downstream LSRs Branch LSR: A LSR of a P2MP LSP that has more than one downstream LSRs Hub LSR: A LSR of a MP2MP LSP that has two or more neighbour LSRs Bud LSR: A LSR of a MP LSP that is an egress but also has one or more directly connected downstream LSRs Le Roux et al. Reqs for multipoint extensions to LDP [Page 3] Internet Draft draft-leroux-mpls-mp-ldp-reqs-00.txt July 2005 2. Introduction Many operators have deployed LDP [LDP] for setting up point-to-point (P2P) and multipoint-to-point (MP2P) LSPs, in order to offer point-to -point services in MPLS backbones. There are emerging requirements for supporting delivery of point-to- multipoint applications in MPLS backbones, such as those defined in [L3VPN-MCAST] and [L2VPN-MCAST]. An interesting and useful approach for operators who want to support point-to-multipoint traffic delivery on an MPLS backbone and have already deployed LDP for P2P traffic would be to rely on LDP extensions in order to setup point-to-multipoint (P2MP) LSPs and potentially multipoint-to-multipoint (MP2MP) LSPs. This would bring consistency with P2P MPLS applications and would ease the delivery of point-to-multipoint applications in an MPLS backbone. This document lists a set of requirements for LDP extensions, for setting up P2MP LSPs and potentially MP2MP LSPs, so as to deliver P2MP traffic over a MPLS infrastructure. It is intended that solutions that specify LDP procedures for P2MP and MP2MP LSP setup, satisfy these requirements. Note that generic requirements for point-to-multipoint extensions to MPLS are out of the scope of this document. Rather this document describes solution specific requirements related to LDP extensions in order to set up P2MP and MP2MP LSPs. Other mechanisms could be used for setting up P2MP and MP2MP LSPs, such as for instance PIM extensions, but these are out of the scope of this document. The objective is not to compare these mechanisms but rather to focus on the requirements for an LDP extension approach. Section 3 points out the problem statement. Section 4 illustrates application scenarios. Finally section 5 addresses detailed requirements. Le Roux et al. Reqs for multipoint extensions to LDP [Page 4] Internet Draft draft-leroux-mpls-mp-ldp-reqs-00.txt July 2005 3. Problem Statement and Requirements Overview 3.1. Problem Statement Many operators have deployed LDP [LDP] for setting up P2P and MP2P MPLS LSPs as PE-to-PE tunnels so as to carry point-to-point traffic essentially in Layer 3 and Layer 2 VPN networks. There are emerging requirements for supporting multicast traffic delivery within these VPN infrastructures ([L3VPN-MCAST] and [L2VPN- MCAST]). For various reasons, including consistency with P2P applications, and taking full advantages of MPLS network infrastructure, it would be highly desirable to use MPLS LSPs for the delivery of multicast traffic. This could be implemented by setting up a group of P2P or MP2P LSPs, but such an approach may be sub-optimal since it would result in data replication at the ingress LSR, and bandwidth inefficiency (duplicate data traffic within the network). Hence new mechanisms are required that would allow traffic from an Ingress LSR to be efficiently delivered to a number of Egress LSRs in an MPLS backbone, avoiding duplicate copies of a packet on a given link. Such efficient traffic delivery requires setting up P2MP LSPs. A P2MP LSPs is an LSP starting at an Ingress LSR, and ending on a set of one or more Egress LSRs. Traffic sent by the Ingress LSR is replicated on one or more Branch LSRs down to Egress LSRs. Requirements for setting up P2MP TE LSPs have been expressed in [P2MP-TE-REQ]. RSVP-TE extensions for setting up P2MP Traffic Engineered LSPs have been defined in [P2MP-TE-RSVP]. This approach is useful, in network environments where Traffic Engineering capabilities are required. However, for operators that deployed LDP for setting up PE-to-PE unicast MPLS LSPs, and without the need of traffic engineering, an interesting approach would be using LDP extensions for setting up P2MP LSPs. Note that there are other alternatives for setting up P2MP (e.g. PIM extensions defined in [PIM-MPLS]), that could be useful in various situations. These are out of the scope of this document. This document focuses on the LDP approach for setting up P2MP LSPs. The following gives a set of guidelines that a specification of LDP extensions for setting up P2MP LSPs should follow. Le Roux et al. Reqs for multipoint extensions to LDP [Page 5] Internet Draft draft-leroux-mpls-mp-ldp-reqs-00.txt July 2005 3.2. Requirements overview The multi-point (MP) LDP mechanism MUST support setting up P2MP LSPs, i.e. LSPs with one Ingress LSR and one or more egress LSRs, with traffic replication at some Branch LSRs. For traffic delivery between a group of N LSRs which are acting indifferently as Ingress or Egress LSRs, it could be preferable to setup MP2MP LSP connecting all these LSRs, instead of having N P2MP LSPs. This would significantly reduce the amount of states that must be maintained on a given LSR. The traffic sent by any Leaf LSRs of a MP2MP LSP is delivered to all other Leaf LSRs of the MP2MP LSP. Hence the MP LDP mechanism SHOULD also allow setting up MP2MP LSPs, connecting a group of leaf LSRs. Note that in the following we use the term MP LSP when referring to P2MP and MP2MP LSPs. The MP LDP mechanism MUST allow the arbitrary addition or removal of leaves associated with a MP LSP. The MP LDP mechanism MUST interoperate seamlessly with existing P2P and MP2P LDP mechanisms. It is of paramount importance that MP LDP mechanisms MUST NOT impede the operation of existing P2P/MP2P LSPs. Also the MP LDP mechanism SHOULD scale independently from the number of Leaf LSRs. For example, it SHOULD NOT create an extraordinary number of LFIB entries even as the number of leaves increases. 4. Application scenarios To be completed in next revision Le Roux et al. Reqs for multipoint extensions to LDP [Page 6] Internet Draft draft-leroux-mpls-mp-ldp-reqs-00.txt July 2005 5. Detailed Requirements 5.1. MP LSPs 5.1.1. P2MP LSP The MP LDP mechanism MUST support setting up P2MP LSPs. A P2MP LSP has one Ingress LSR and one or more Egress LSRs. Traffic sent by the Ingress LSR is received by all Egress LSRs. The specific aspects related to P2MP LSP is the action required at a Branch LSR, where data replication occurs. Incoming labelled data is appropriately replicated to several outgoing interfaces which may use different labels. Only one copy of a packet MUST be sent on a given link of a P2MP LSP. A P2MP LSP MUST be identified by a constant and unique identifier within the whole LDP domain, whatever the number of leaves, which may vary dynamically. This identifier will be used so as to add/remove leaves to/from the P2MP tree. 5.1.2. MP2MP LSP The MP LDP mechanism SHOULD allow setting up MP2MP LSPs. A MP2MP LSP is a bidirectional LSP whose Leaf LSRs act indifferently as Ingress or Egress. Traffic sent by any Leaf LSRs is received by all other Leaf LSRs. Only one copy of a packet MUST be sent on a given link of a MP2MP LSP. The specific aspect related to a MP2MP LSP is the action required at Hub LSRs, where data replication occurs. A Hub LSR has more than two interfaces on the LSP. A Hub LSR replicates labeled packets received on any interface of the LSP to all other interfaces of the LSP, which may use different labels. A Leaf LSR of a MP2MP LSP MUST NOT receive back a packet it had previously transmitted on the MP2MP LSP. A MP2MP LSP MUST be identified by a constant and unique identifier within the whole LDP domain, whatever the number of leaves, which may vary dynamically. This identifier will be used so as to add and remove leaves to and from the MP2MP tree. Le Roux et al. Reqs for multipoint extensions to LDP [Page 7] Internet Draft draft-leroux-mpls-mp-ldp-reqs-00.txt July 2005 5.1.3. MP LSP FEC As with P2P MPLS technology [LDP], traffic MUST be classified into a FEC in this MP extension. All packets which belong to a particular P2MP or MP2MP FEC and which travel from a particular node MUST use the same MP LSP. As such, a solution MUST specify a FEC that is suitable for P2MP/MP2MP forwarding. Such P2MP/MP2MP FEC MUST be distinguished clearly from the exiting P2P/MP2P FEC. 5.2. Setting up, tearing down and modifying MP LSPs The MP LDP mechanism MUST support the establishment, maintenance and teardown of MP LSPs in a scalable manner. This MUST include both the existence of a large amount of MP LSPs within a single network and a large amount of leaf LSRs for a single MP LSP. In order to scale well with a large number of leaves it is RECOMMENDED to follow a leaf-initiated MP LSP setup approach. For that purpose, leaves will have to be aware of the MP LSP identifier. The way a Leaf LSR discovers MP LSPs identifiers SHOULD not be part of MP LDP extensions. Instead this SHOULD be part of the applications that will use MP LSPs, and it is out of the scope of this document. The MP LDP mechanism MUST allow the dynamic addition and removal of leaves to and from a MP LSP. It is RECOMMENDED that these operations be leaf-initiated. It is RECOMMENDED that these operations do not cause any additional processing except on the path from the Branch (or possibly Hub) LSR to the added or removed leaf LSR. 5.3. Label Advertisement The MP LDP mechanism SHOULD support downstream unsolicited label advertisement mode. This is well suited to a leaf-initiated approach and is consistent with P2P/MP2P LDP operations. In order to follow a leaf initiated LSP setup approach, MP LDP mechanism SHOULD support the Ordered label distribution control mode. Note that the Independent control mode is not relevant in a MP context, because the upstream LSRs cannot distribute labels independently like P2P/MP2P LDP, they must wait for label distribution from downstream LSRs. Upstream label allocation ([MPLS-UPSTREAM]) may be particularly useful to avoid packet replication on LAN interfaces of a MP LSP, or when encapsulating the MP LSP into a P2MP TE tunnel. Hence the MP LDP mechanism SHOULD also support upstream solicited label advertisement mode, where the solicitation is made by the downstream LSR, but the label is assigned by the upstream LSR. Le Roux et al. Reqs for multipoint extensions to LDP [Page 8] Internet Draft draft-leroux-mpls-mp-ldp-reqs-00.txt July 2005 Note that the existing base LDP specification [RFC3036] does not specify upstream solicited label advertisement. Hence specific extensions SHOULD be defined. 5.4. Data Duplication Data duplication refers to the receipt of multiple copies of a packet by any leaf. Although this may be a marginal situation, it may also be detrimental for certain applications. Hence, data duplication SHOULD be avoided as much as possible, and limited to (hopefully rare) transitory conditions. Note, in particular, that data duplication might occur if MP LSP rerouting is being performed (See also section 5.6). 5.5. Avoiding loops The MP LDP mechanism SHOULD have a mechanism to avoid routing loops even during transient events. Furthermore, the MP LDP mechanism MUST avoid routing loops that may trigger unexpected non-localized exponential growth of traffic. Note that any loop-avoidance mechanism MUST respect scalability requirements, and particularly SHOULD scale independently from the number of Leaf LSRs. 5.6. MP LSP routing As with P2P and MP2P LDP LSPs, the MP LDP mechanism MUST support hop- by-hop LSP routing. MP LSP LDP-based routing SHOULD rely upon the information maintained in LSR Routing Information Bases (RIB). For instance, P2MP LSP routing could rely upon a shortest path to the Ingress LSR, and MP2MP LSP routing could rely upon a shortest path to one or more specific Hub LSRs. Note that unlike P2P/MP2P LDP routing, Equal Cost Multi Path (ECMP) MUST be avoided with MP LDP routing. 5.7. MP LSP Re-routing The MP LDP mechanism MUST support the rerouting of a MP LSP in the following cases: -A better path exists (e.g. new link, netric change) -Network failure (link or node) -Planned maintenance 5.7.1. Rerouting on a Better Path The MP LDP mechanism MUST allow for rerouting of a MP LSP in case a better path is created in the network, for instance as a result of a metric change, or the addition of links or nodes. Traffic disruption MUST be minimized during such rerouting. It is RECOMMENDED that devices perform make-before-break for traffic on MP LSPÆs to minimize traffic disruption. It SHOULD be feasible to avoid packet loss during such rerouting. Le Roux et al. Reqs for multipoint extensions to LDP [Page 9] Internet Draft draft-leroux-mpls-mp-ldp-reqs-00.txt July 2005 Unnecessary data duplication during such rerouting MUST also be minimized. 5.7.2. Rerouting due to a Network Failure The MP LDP mechanism MUST allow for rerouting of a MP LSP in case of link or node failure(s). The rerouting time SHOULD be minimized as much as possible so as to reduce traffic disruption. A mechanism MUST be defined to prevent constant MP LSP teardown and rebuild which may be caused by the instability of a specific link/node in the network. 5.7.3. Rerouting Due to Planned Maintenance The MP LDP mechanism MUST support planned maintenance operations. It SHOULD be possible to reroute a MP-LSP before a link/node is deactivated for maintenance purposes. Traffic disruption MUST be minimized during such rerouting. It SHOULD be feasible to avoid packet loss during such rerouting. Unnecessary traffic duplication during such rerouting MUST also be minimized. 5.8. Support for LAN interfaces The MP LDP mechanism MUST provide a way for a Hub/Branch LSR to send a single copy of the data onto an Ethernet LAN interface and reach multiple adjacent downstream nodes. This requires that the same label be negotiated will all downstream LSRs for the LSP. In order to ease such negotiation an upstream label allocation approach may be used. 5.9. Support for encapsulation in P2P and P2MP TE tunnels The MP LDP mechanism MUST support nesting MP LSPs into P2P and P2MP TE tunnels. The MP LDP mechanism MUST provide a way for a Hub/Branch LSR of a MP LPS, which is also a Head End LSR of a P2MP TE tunnel, to send a single copy of the data onto the tunnel and reach all downstream LSRs on the MP LSP, which are also Egress LSRs of the tunnel. As with LAN interfaces, this requires that the same LDP label be negotiated with all downstream LSRs for the MP LDP LSP. In order to ease such negotiation, an upstream label allocation approach may be used. 5.10. Label spaces Labels for MP LSPs and P2P/MP2P LSPs MAY be assigned from shared or dedicated label spaces. MPLS Context Specific Label Spaces ([UPSTREAM-LABEL]) and particularly Upstream label spaces and Tunnel label spaces MAY be required to support upstream label allocation so as to avoid packet replication on LAN or P2MP TE Tunnel interfaces. Le Roux et al. Reqs for multipoint extensions to LDP [Page 10] Internet Draft draft-leroux-mpls-mp-ldp-reqs-00.txt July 2005 Note that dedicated label spaces will require the establishment of separate MP LDP sessions. 5.11. IPv4/IPv6 support The MP LDP mechanism MUST be equally applicable to IPv4 and IPv6 traffic. Likewise, it SHOULD be possible to convey both kinds of traffic in a given MP LSP facility. Also the MP LDP mechanism MUST support the establishment of LDP sessions over both IPv4 and IPv6 control planes. 5.12. Multi-Area LSPs The MP LDP mechanism MUST support the establishment of multi-area MP LSPs, i.e. LSPs whose leaves do not all reside in the same IGP area. This SHOULD be possible without requiring the advertisement of Leaf LSRs' addresses across IGP areas. 5.13. OAM LDP management tools ([LDP-MIB],...) MUST be enhanced to support MP LDP extensions. This may yield a new MIB module, which may possibly be inherited from the LDP MIB. In order to facilitate correct management, MP LDP LSPs MUST have unique identifiers, otherwise it is impossible to determine which LSP is being managed. OAM facilities will have special demands in MP MPLS environments especially within the context of tracing the paths and determining the connectivity of MP LSPs. Further and precise requirements and mechanisms for OAM purpose are out of the scope of this document. It is expected that a separate document will cover these requirements and mechanisms. 5.14. Graceful Restart and Fault Recovery LDP Graceful Restart mechanisms [LDP-GR] and Fault Recovery [LDP-FT] mechanisms SHOULD be enhanced to support MP LDP LSPs. Particularly [LDP-GR] applies only to downstream unsolicited label distribution. Hence new mechanisms are required to account for upstream label assignment, particularly in multi segment LANs. 5.15. Robustness A solution SHOULD avoid whatever single points of failures or propose some technical solutions for a failover mechanism (e.g., redundancy/ failover of Hub LSRs). Le Roux et al. Reqs for multipoint extensions to LDP [Page 11] Internet Draft draft-leroux-mpls-mp-ldp-reqs-00.txt July 2005 5.16. Scalability Scalability is a key requirement for the MP LDP mechanism. It MUST be designed to scale well with an increase in the number of any of the following: - number of Leaf LSRs per MP LSP - number of Branch/Hub LSRs per MP LSP - number of MP LSPs per LSR The size of a MP LSP state on a LSR SHOULD be independent of the number of leaves, and SHOULD only depend on the number of adjacent LSRs. 5.16.1. Orders of magnitude of the expected numbers of MP LSPs and leaves per LSP in operational networks To be completed in next revision 5.17. Backward Compatibility In order to allow for a smooth migration, the MP LDP mechanism SHOULD offer as much backward compatibility as possible. In particular, the solution SHOULD allow the setup of a MP LSP along non branch/hub transit LSRs that do not support MP LDP extensions. Also, the MP LDP solution MUST interoperate seamlessly with current LDP mechanisms and inherit its capability sets from [LDP]. The MP LDP solution MUST not impede the operation of P2P/MP2P LSPs. A MP LSP solution MUST be designed in such a way that it allows P2P/MP2P and MP LSPs to be signalled on the same interface. 6. Evaluation criteria 6.1. Performances The solution will be evaluated with respect to the following criteria: (1) Time (in msec) to add or remove a Leaf LSR (2) Time (in msec) to repair a MP LSP in case of link or node failure (3) Scalability (state size, number of messages, message size). Particularly, the MP LDP mechanism SHOULD be designed so that convergence times in case of link or node failure are minimized, in order to limit traffic disruption. 6.2. Complexity and Risks The proposed solution SHOULD not introduce complexity to the current LDP operations to such a degree that it would affect the stability and diminish the benefits of deploying such MP LDP solution. Le Roux et al. Reqs for multipoint extensions to LDP [Page 12] Internet Draft draft-leroux-mpls-mp-ldp-reqs-00.txt July 2005 7. Security Considerations This document does not introduce any new security issues beyond those inherent to LDP [LDP] and a MP LDP solution may use the same mechanisms. 8. Acknowledgment We would like to thank Christian Jacquenet (France Telecom) and Hitoshi Fukuda (NTT Communications) for their highly useful comments and suggestions. We would also like to thank authors of [P2MP-TE-REQ] from which some text of this document has been inspired. 9. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [BCP79] Bradner, S., "Intellectual Property Rights in IETF Technology", RFC 3979, March 2005. [LDP] L. Andersson et al. "LDP Specification", RFC 3036, January 2001 [L3VPN-MCAST] T. Morin, Ed., "Requirements for Multicast in L3 Provider-Provisioned VPNs", draft-ietf-l3vpn-ppvpn-mcast-reqts- 01.txt, work in progress. [L2VPN-MCAST] Y. Kamite et al. " Requirements for Multicast Support in Virtual Private LAN Services", draft-kamite-l2vpn-vpls-mcast- reqts-00.txt, work in progress [P2MP-TE-REQ] S. Yasukawa, et. al., "Requirements for Point-to- Multipoint capability extension to MPLS", draft-ietf-mpls-p2mp-sig- requirement-03.txt, work in progress. [P2MP-TE-RSVP] R. Aggarwal, et. al., "Extensions to RSVP-TE for Point to Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp-02.txt, work in progress. [PIM-MPLS] D. Farinacci, Y. Rekhter, E. Rosen, T. Qian, " Using PIM to Distribute MPLS Labels for Multicast Routes", draft-farinacci- mpls-multicast-03.txt. [MPLS-UPSTREAM-LABEL] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label Assignment and Context Specific Label Space", draft- raggarwa-mpls-upstream-label-00.txt, work in progress. Le Roux et al. Reqs for multipoint extensions to LDP [Page 13] Internet Draft draft-leroux-mpls-mp-ldp-reqs-00.txt July 2005 [LDP-MIB] J. Cuchiarra et al. " Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC3815, June 2004. [LDP-GR] M. Leelanivas, Y. Rekhter, R. Aggarwal, " Graceful Restart Mechanism for Label Distribution Protocol" RFC3478, February 2003. [LDP-FT] A. Farrel, " Fault Tolerance for the Label Distribution Protocol (LDP)", RFC3479, February 2003. 10. Authors' Addresses: Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: jeanlouis.leroux@francetelecom.com Thomas Morin France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: thomas.morin@francetelecom.com Vincent Parfait EQUANT 1041 Route des Dolines Sophia Antipolis 06560 Valbonne FRANCE Email: vincent.parfait@equant.com Luyuan Fang AT&T 200 Laurel Avenue Middletown, NJ 07748 USA Email: luyuanfang@att.com Lei Wang Telenor Snaroyveien 30 Fornebu 1331 NORWAY Email: lei.wang@telenor.com Yuji Kamite NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku, Le Roux et al. Reqs for multipoint extensions to LDP [Page 14] Internet Draft draft-leroux-mpls-mp-ldp-reqs-00.txt July 2005 Tokyo 163-1421, JAPAN Email: y.kamite@ntt.com Shane Amante Level 3 Communications, LLC 1025 Eldorado Blvd Broomfield, CO 80021 USA Email: shane@level3.net 11. Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Le Roux et al. Reqs for multipoint extensions to LDP [Page 15]