Network Working Group J.-L. Le Roux
Internet Draft T. Morin
Category: Informational France Telecom
Expires: January 2006
Vincent Parfait
Equant
Luyuan Fang
AT&T
Lei Wang
Telenor
Yuji Kamite
NTT Communications
Shane Amante
Level 3 Communications
July 2005
Requirements for point-to-multipoint extensions to
the Label Distribution Protocol
draft-leroux-mpls-mp-ldp-reqs-01.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 P2MP extensions to LDP [Page 1]
Internet Draft draft-leroux-mpls-mp-ldp-reqs-01.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) 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 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.......................................6
5.1. P2MP LSPs...................................................6
5.2. P2MP LSP FEC................................................6
5.3. Setting up, tearing down and modifying P2MP LSPs............7
5.4. Label Advertisement.........................................7
5.5. Data Duplication............................................8
5.6. Avoiding loops..............................................8
5.7. P2MP LSP routing............................................8
5.8. P2MP LSP Re-routing.........................................8
5.8.1. Rerouting on a Better Path..................................8
5.8.2. Rerouting upon Network Failure..............................9
5.8.3. Rerouting upon Planned Maintenance..........................9
5.9. Support for LAN interfaces..................................9
5.10. Support for encapsulation in P2P and P2MP TE tunnels........9
5.11. Label spaces................................................9
5.12. IPv4/IPv6 support..........................................10
5.13. Multi-Area LSPs............................................10
5.14. OAM........................................................10
5.15. Graceful Restart and Fault Recovery........................10
5.16. Robustness.................................................10
5.17. Scalability................................................11
5.17.1. Orders of magnitude of the expected numbers of P2MP
LSPs and leaves per LSP in operational networks..........11
5.18. Backward Compatibility.....................................11
6. Shared Trees...............................................11
7. Evaluation criteria........................................12
7.1. Performances...............................................12
Le Roux et al. Reqs for P2MP extensions to LDP [Page 2]
Internet Draft draft-leroux-mpls-mp-ldp-reqs-01.txt July 2005
7.2. Complexity and Risks.......................................12
8. Security Considerations....................................12
9. Acknowledgments............................................12
10. References.................................................12
11. Authors' Addresses:........................................14
12. 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
Leaf LSR: Egress LSR of a P2MP LSP
Transit LSR: A LSR of a P2MP LSP that has one or more downstream
LSRs
Branch LSR: A LSR of a P2MP LSP that has more than one downstream
LSRs
Bud LSR: A LSR of a P2MP LSP that is an egress but also has one or
more directly connected downstream LSRs
Le Roux et al. Reqs for P2MP extensions to LDP [Page 3]
Internet Draft draft-leroux-mpls-mp-ldp-reqs-01.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-REQ] and [L2VPN-MCAST-REQ].
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. 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, so as to deliver P2MP traffic over a MPLS
infrastructure.
It is intended that solutions that specify LDP procedures for P2MP
LSP setup, satisfy these requirements.
Note that generic requirements for P2MP 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 LSPs.
Other mechanisms could be used for setting up P2MP 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 P2MP extensions to LDP [Page 4]
Internet Draft draft-leroux-mpls-mp-ldp-reqs-01.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-REQ] and
[L2VPN-MCAST-REQ]).
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.
RSVP-TE extensions for setting up P2MP TE LSPs, which meet
requirements expressed in [P2MP-TE-REQ], 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 P2MP extensions to LDP [Page 5]
Internet Draft draft-leroux-mpls-mp-ldp-reqs-01.txt July 2005
3.2. Requirements overview
The P2MP 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.
The P2MP LDP mechanism MUST allow the arbitrary addition or removal
of leaves associated with a P2MP LSP.
The P2MP LDP mechanism MUST interoperate seamlessly with existing P2P
and MP2P LDP mechanisms.
It is of paramount importance that the P2MP LDP mechanism MUST NOT
impede the operation of existing P2P/MP2P LSPs.
Note that the P2MP LDP mechanism MAY also allow setting up
multipoint-to-multipoint (MP2MP) LSPs connecting a group of Leaf LSRs
acting indifferently as Ingress LSR or Egress LSR. This may allow
reducing the amount of LDP state to be maintained by a LSR. Detailed
requirements for MP2MP LSPs are left for further study.
4. Application scenarios
To be completed in next revision
5. Detailed Requirements
5.1. P2MP LSPs
The P2MP 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.2. P2MP LSP FEC
As with P2P MPLS technology [LDP], traffic MUST be classified into a
FEC in this P2MP extension. All packets which belong to a particular
P2MP FEC and which travel from a particular node MUST use the same
P2MP LSP.
Le Roux et al. Reqs for P2MP extensions to LDP [Page 6]
Internet Draft draft-leroux-mpls-mp-ldp-reqs-01.txt July 2005
As such, a solution MUST specify a FEC that is suitable for P2MP
forwarding. Such P2MP FEC MUST be distinguished clearly from the
exiting P2P/MP2P FEC.
5.3. Setting up, tearing down and modifying P2MP LSPs
The P2MP LDP mechanism MUST support the establishment, maintenance
and teardown of P2MP LSPs in a scalable manner. This MUST include
both the existence of a large amount of P2MP LSPs within a single
network and a large amount of leaf LSRs for a single P2MP 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 P2MP LSP
identifier. The way a Leaf LSR discovers P2MP LSPs identifiers SHOULD
not be part of P2MP LDP extensions. Instead this SHOULD be part of
the applications that will use P2MP LSPs, and it is out of the scope
of this document.
The P2MP LDP mechanism MUST allow the dynamic addition and removal of
leaves to and from a P2MP 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 LSR to the added or
removed Leaf LSR.
5.4. Label Advertisement
The P2MP 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, the P2MP LDP
mechanism SHOULD support the Ordered label distribution control mode.
Note that the Independent control mode is not relevant in a P2MP
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 P2MP LSP,
or when encapsulating the P2MP LSP into a P2MP TE tunnel.
Hence the P2MP 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.
Note that the existing base LDP specification [RFC3036] does not
specify upstream solicited label advertisement. Hence specific
extensions SHOULD be defined.
Le Roux et al. Reqs for P2MP extensions to LDP [Page 7]
Internet Draft draft-leroux-mpls-mp-ldp-reqs-01.txt July 2005
5.5. 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 P2MP LSP
rerouting is being performed (See also section 5.6).
5.6. Avoiding loops
The P2MP LDP mechanism SHOULD have a mechanism to avoid routing loops
even during transient events. Furthermore, the P2MP 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.
5.7. P2MP LSP routing
As with P2P and MP2P LDP LSPs, the P2MP LDP mechanism MUST support
hop-by-hop LSP routing. P2MP 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. Note that unlike P2P/MP2P LDP routing, Equal Cost Multi
Path (ECMP) MUST be avoided with P2MP LDP routing.
5.8. P2MP LSP Re-routing
The P2MP LDP mechanism MUST support the rerouting of a P2MP LSP in
the following cases:
-A better path exists (e.g. new link, metric change)
-Network failure (link or node)
-Planned maintenance
5.8.1. Rerouting on a Better Path
The P2MP LDP mechanism MUST allow for rerouting of a P2MP 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
P2MP LSPs to minimize traffic disruption.
It SHOULD be feasible to avoid packet loss during such rerouting.
Unnecessary data duplication during such rerouting MUST also be
minimized.
Le Roux et al. Reqs for P2MP extensions to LDP [Page 8]
Internet Draft draft-leroux-mpls-mp-ldp-reqs-01.txt July 2005
5.8.2. Rerouting upon Network Failure
The P2MP LDP mechanism MUST allow for rerouting of a P2MP 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 P2MP LSP teardown and
rebuild which may be caused by the instability of a specific
link/node in the network.
5.8.3. Rerouting upon Planned Maintenance
The P2MP LDP mechanism MUST support planned maintenance operations.
It SHOULD be possible to reroute a P2MP 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.9. Support for LAN interfaces
The P2MP LDP mechanism MUST provide a way for a 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.10. Support for encapsulation in P2P and P2MP TE tunnels
The P2MP LDP mechanism MUST support nesting P2MP LSPs into P2P and
P2MP TE tunnels.
The P2MP LDP mechanism MUST provide a way for a Branch LSR of a P2MP
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 P2MP 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 P2MP LDP LSP. In order to ease such
negotiation, an upstream label allocation approach may be used.
5.11. Label spaces
Labels for P2MP 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.
Note that dedicated label spaces will require the establishment of
separate P2MP LDP sessions.
Le Roux et al. Reqs for P2MP extensions to LDP [Page 9]
Internet Draft draft-leroux-mpls-mp-ldp-reqs-01.txt July 2005
5.12. IPv4/IPv6 support
The P2MP 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 P2MP LSP facility.
Also the P2MP LDP mechanism MUST support the establishment of LDP
sessions over both IPv4 and IPv6 control planes.
5.13. Multi-Area LSPs
The P2MP LDP mechanism MUST support the establishment of multi-area
P2MP 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.14. OAM
LDP management tools ([LDP-MIB]
) MUST be enhanced to support P2MP
LDP extensions. This may yield a new MIB module, which may possibly
be inherited from the LDP MIB.
In order to facilitate correct management, P2MP LDP LSPs MUST have
unique identifiers, otherwise it is impossible to determine which LSP
is being managed.
OAM facilities will have special demands in P2MP MPLS environments
especially within the context of tracing the paths and determining
the connectivity of P2MP LSPs. Further and precise requirements and
mechanisms for OAM purpose are out of the scope of this document and
are addressed in [P2MP-OAM-REQ].
5.15. Graceful Restart and Fault Recovery
LDP Graceful Restart mechanisms [LDP-GR] and Fault Recovery [LDP-FT]
mechanisms SHOULD be enhanced to support P2MP 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.16. Robustness
A solution SHOULD avoid whatever single points of failures or propose
some technical solutions for a failover mechanism.
Le Roux et al. Reqs for P2MP extensions to LDP [Page 10]
Internet Draft draft-leroux-mpls-mp-ldp-reqs-01.txt July 2005
5.17. Scalability
Scalability is a key requirement for the P2MP 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 P2MP LSP
- number of Branch LSRs per P2MP LSP
- number of P2MP LSPs per LSR
In order to scale well with an increase in the number of leaves, it
is RECOMMENDED that the size of a P2MP LSP state on a LSR, for one
particular LSP, depend only on the number of adjacent LSRs on the
LSP.
5.17.1. Orders of magnitude of the expected numbers of P2MP LSPs and
leaves per LSP in operational networks
To be completed in next revision
5.18. Backward Compatibility
In order to allow for a smooth migration, the P2MP LDP mechanism
SHOULD offer as much backward compatibility as possible. In
particular, the solution SHOULD allow the setup of a P2MP LSP along
non Branch Transit LSRs that do not support P2MP LDP extensions.
Also, the P2MP LDP solution MUST interoperate seamlessly with current
LDP mechanisms and inherit its capability sets from [LDP]. The P2MP
LDP solution MUST not impede the operation of P2P/MP2P LSPs. A P2MP
LDP solution MUST be designed in such a way that it allows P2P/MP2P
and P2MP LSPs to be signalled on the same interface.
6. Shared Trees
For traffic delivery between a group of N LSRs which are acting
indifferently as Ingress or Egress LSR, it may be useful to
setup a multipoint-to-multipoint (MP2MP) LSP connecting all these
LSRs, instead of having N P2MP LSPs. This would reduce the amount of
state that has to be maintained on a given LSR.
Hence the P2MP LDP mechanism MAY also allow setting up MP2MP LSPs.
Detailed requirements for MP2MP LSPs are left for further study
Note that the setup of such shared trees, with as objective to reduce
the amount of state, could also rely on the application protocols
that uses LDP LSPs, rather than on LDP itself. For instance with
Multicast L3 VPN applications, it would be possible to build a shared
tree that relies on a set of unicast LDP LSPs, from each PE of the
group to a particular PE, acting as tree root, and one P2MP LDP LSP
from the root to all PEs of the group (see [2547-MCAST]).
Le Roux et al. Reqs for P2MP extensions to LDP [Page 11]
Internet Draft draft-leroux-mpls-mp-ldp-reqs-01.txt July 2005
7. Evaluation criteria
7.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 P2MP LSP in case of link or node
failure;
(3) Scalability (state size, number of messages, message size).
Particularly, the P2MP LDP mechanism SHOULD be designed so that
convergence times in case of link or node failure are minimized, in
order to limit traffic disruption.
7.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 P2MP LDP solution.
8. Security Considerations
This document does not introduce any new security issue beyond those
inherent to LDP, and a P2MP LDP solution may rely on the security
mechanisms defined in [LDP] (e.g. TCP MD-5).
9. Acknowledgments
We would like to thank Christian Jacquenet (France Telecom),
Hitoshi Fukuda (NTT Communications), Ina Minei (Juniper) and Dean
Cheng (Cisco Systems) 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.
10. 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, P. Doolan, N. Feldman, A. Fredette, B. Thomas,
"LDP Specification", RFC 3036, January 2001
Le Roux et al. Reqs for P2MP extensions to LDP [Page 12]
Internet Draft draft-leroux-mpls-mp-ldp-reqs-01.txt July 2005
[L3VPN-MCAST-REQ] T. Morin, Ed., "Requirements for Multicast in L3
Provider-Provisioned VPNs", draft-ietf-l3vpn-ppvpn-mcast-reqts-
01.txt, work in progress.
[L2VPN-MCAST-REQ] 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, D. Papadimitriou, S. Yasukawa, 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.
[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.
[2547-MCAST] E. Rosen, R. Aggarwal, et. al., "Multicast in MPLS/BGP
IP VPNs", draft-ietf-l3vpn-2547bis-mcast, work in progress.
[P2MP-OAM-REQ] S. Yasukawa, A. Farrel, D. King, T. Nadeau, "OAM
Requirements for Point-To-Multipoint MPLS Networks", draft-yasukawa-
mpls-p2mp-oam-reqs-00.txt, work in progress.
Le Roux et al. Reqs for P2MP extensions to LDP [Page 13]
Internet Draft draft-leroux-mpls-mp-ldp-reqs-01.txt July 2005
11. 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,
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
Le Roux et al. Reqs for P2MP extensions to LDP [Page 14]
Internet Draft draft-leroux-mpls-mp-ldp-reqs-01.txt July 2005
12. 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 P2MP extensions to LDP [Page 15]