IETF Internet Draft Seisho Yasukawa
NTT Corporation
Expires: April 2006
Adrian Farrel
Old Dog Consulting
October 2005
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt
Support of LDP Multicast Label Switched Paths over
Point-to-Multipoint Label Switched Path Tunnels and
on Multi-Access Links
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.
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.
Abstract
Multiprotocol Label Switching (MPLS) includes the facility to
provision point-to-multipoint (P2MP) Traffic Engineered (TE) Label
Switched Paths (LSPs) which can be used to construct P2MP tunnels
across MPLS networks.
The Label Distribution Protocol (LDP) has also been extended to
support label distribution for multicast traffic by forming multicast
LSPs.
When traffic for a user network is carried across a provider network,
Yasukawa and Farrel Page 1
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
it is common practice for the traffic to be placed in tunnels. This
document examines the requirements to carry multicast LDP traffic
across a provider network within P2MP MPLS tunnels, and introduces
solution models that meet those requirements.
Note that the requirements and solutions discussed in this document
are also applicable to the use of multicast LDP on multi-access
networks.
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 [RFC2119].
Readers need to be familiar with the concepts of MPLS set out in
[RFC3031], with the mechanics of MPLS P2MP TE LSP establishment
described in [P2MP-RSVP], and with the proposals for multicast LDP
LSP signaling described in [P2MP-LDP].
Throughout this document, "P2MP" is used to refer to
point-to-multipoint traffic engineered LSPs, while "multicast" is
used to refer to LDP LSPs established in support of multicast traffic
flows.
Yasukawa and Farrel Page 2
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
Contents
1. Introduction ................................................... 4
2. Requirements ................................................... 4
2.1. Requirements for the use of Multi-Access Links ............... 6
3. Problem Statement .............................................. 7
4. Overview of Potential Solutions ................................ 8
5. Upstream Label Allocation ...................................... 8
5.1. Operational Procedures ....................................... 8
5.1.1. Agreement to Use Upstream Label Allocation ................. 9
5.1.2. Label Distribution ......................................... 9
5.1.3. Label Solicitation ......................................... 9
5.1.4. Determining the Participating Downstream LSRs .............. 9
5.1.5. Processing of Received Labels .............................. 9
5.2. Comparison with Previous LDP Mechanisms ..................... 10
5.3. Applicability ............................................... 10
5.3.1. P2MP TE Tunnels ........................................... 10
5.3.2. Multi-Access Links ........................................ 12
5.3.3. Mixing Upstream-Capable and Non-Upstream Capable LSRs ..... 12
5.4. Issues and Open Questions ................................... 13
6. Upstream Label Suggestion ..................................... 14
6.1. Operational Procedures ...................................... 14
6.1.1. Agreement to Use Upstream Label Suggestion ................ 14
6.1.2. Label Distribution ........................................ 15
6.1.3. Downstream on Demand ...................................... 15
6.1.4. Determining the Participating Downstream LSRs ............. 16
6.1.5. Processing of Received Labels ............................. 16
6.2. Protocol Extensions ......................................... 16
6.3. Comparison with Previous LDP Mechanisms ..................... 17
6.4. Applicability ............................................... 18
6.4.1. P2MP TE Tunnels ........................................... 18
6.4.2. Multi-Access Links ........................................ 19
6.4.3. Mixing Suggestion-Capable and Non-Suggestion Capable LSRs . 19
6.5. Issues and Open Questions ................................... 19
7. LSP Stitching ................................................. 21
7.1. Operational Procedures ...................................... 22
7.1.1. Dynamic Establishment and Maintenance of P2MP TE LSP ...... 22
7.1.2. Pre-Provisioned P2MP TE LSPs .............................. 23
7.2. Protocol Extensions ......................................... 24
7.3. Applicability ............................................... 24
7.3.1. Applicability to Multi-Access Links ....................... 25
8. Security Considerations ....................................... 25
9. IANA Considerations ........................................... 25
10. Acknowledgements ............................................. 25
11. Intellectual Property Considerations ......................... 26
12. Normative References ......................................... 26
13. Informational References ..................................... 27
14. Authors' Addresses ........................................... 27
15. Full Copyright Statement ..................................... 28
Yasukawa and Farrel Page 3
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
1. Introduction
The Label Distribution Protocol (LDP) [RFC3036] is a set of
procedures by which Label Switching Routers (LSRs) distribute labels
to support Multi Protocol Label Switching (MPLS) [RFC3031] forwarding
of unicast traffic along routing paths set by an IP unicast routing
protocol. Label Switched Paths(LSPs) are established to carry
traffic that is identified by its Forwarding Equivalence Class (FEC).
LDP has been extended [P2MP-LDP] to distribute labels to support MPLS
forwarding of multicast traffic by forming "multicast LSPs."
The establishment and use of point-to-point (P2P) MPLS Traffic
Engineered (TE) LSPs is described in [RFC3209]. These LSPs may be
treated as P2P tunnels across the network. The techniques described
in [RFC3209] have been extended to support point-to-multipoint (P2MP)
MPLS TE LSPs which can be used to construct P2MP tunnels across MPLS
networks [P2MP-RSVP].
When traffic for a user network is carried across a provider network,
it is common practice for the traffic to be placed in tunnels. This
is an established practice within MPLS networks where P2P LDP LSPs
may be carried across a core network in P2P TE LSPs [RFC3031].
This document examines the requirements to carry multicast LDP LSPs
across a provider network within P2MP MPLS tunnels, and introduces
solution models that meet those requirements with text clarifying the
applicability of the solutions to different environments and
requirements.
The problems associated with supporting multicast LDP LSPs over P2MP
MPLS-TE LSPs can be observed to be very similar to the problems of
supporting multicast LDP LSPs on multi-access links. This document
also examines the applicability of the solutions it introduces to
multi-access environments.
2. Requirements
Details of specific requirements for multicast LDP can be found in
[P2MP-LDP, P2MP-LDP-REQ]. Further details of the requirements for
P2MP TE LSPs can be found in [P2MP-SIG-REQ]. These requirements are
not directly within the scope of this document.
By way of illustration, the figure below demonstrates the type of
network to be considered. An MPLS TE network (LSRs A through G) lies
within an LDP network (LSRs s, r1 through r7, and a through h). A
multicast LDP LSP is to be established from source s to receivers r1
through r7. A P2MP TE LSP is established from A to the leaves D, E
and G as shown in the figure.
Yasukawa and Farrel Page 4
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
............ r2
: : |
: -D--c--d--r3
: / :
: / :
s--a--b--A---B---C---E--e--r4
| : \ :
| : \ :
r1 : F----G--f--g--r5
: : |
........... h--r6
|
r7
The requirements to transport multicast LDP LSPs using P2MP TE LSPs
may be simply stated.
- Aggregation.
If the ratio of transporting LSPs to transported LSPs is better
than 1:1 then there are processing savings in the core network.
These savings apply in the control plane where less LSP state needs
to be maintained, and in the data plane where fewer labels and
label swapping actions are required.
- Explicit Path Control.
The procedures for P2MP TE LSP establishment and maintenance
[P2MP-RSVP] allow for control of the path that the P2MP TE LSP
follows. This facilitates traffic engineering such that LSPs can be
routed around network faults or hot-spots. This facility is not
available in LDP [RFC3036] and is usually achieved by tunneling LDP
LSPs within MPLS-TE LSPs. The solutions described in this document
extend such tunneling techniques for the use of multicast LDP LSPs.
- Resource Reservation.
[RFC3209] allows resources to be allocated and dedicated to the
traffic of a particular P2P TE LSP. Not only does this mechanism
facilitate improved traffic engineering, but it provides a means to
offer quality of service guarantees for LSPs that traverse a core
network. This function is not available in LDP [RFC3036] and may be
enabled by tunneling LDP LSPs within MPLS-TE LSPs. The solutions
described in this document extend such resource reservation
techniques by tunneling multicast LDP LSPs through P2MP MPLS-TE
LSPs which also allow resource reservation [P2MP-RSVP].
There may also be resource savings associated with the aggregation
of multiple multicast LDP LSPs into a single P2MP TE LSP because
assumptions can be made about average traffic flows.
Yasukawa and Farrel Page 5
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
- Protection and Other Services.
P2P MPLS-TE LSPs [RFC3209] can provide a range of high-function
services such as end-to-end protection, segment protection, and
layered networking through a range of extensions to the base
protocol. These extensions are similarly available to P2MP MPLS-TE
LSPs since the signaling of these LSPs [P2MP-RSVP] is based on the
protocols described for P2P MPLS-TE LSPs [RFC3209].
These services are not available in LDP [RFC3036] and are often
achieved by tunneling LDP LSPs within MPLS-TE LSPs (for example,
fast re-route [RFC4090]). The solutions described in this document
extend such tunneling techniques for the use of multicast LDP LSPs
tunneled within P2MP MPLS-TE LSPs.
These requirements are no different from the requirements applied in
P2P MPLS. They do not need further description here, but can be seen
in further detail as applied to P2P MPLS in [RFC3031]. Note, however,
that the mechanisms for meeting these requirements are constrained by
the problem statement stated in section 3. This means that the
mechanisms used for the support of P2P LDP LSPs over P2P MPLS-TE LSPs
are not optimal.
Some further reasons for the existence and use of P2MP TE LSPs can be
found in [P2MP-SIG-REQ].
2.1. Requirements for the use of Multi-Access Links
Multi-access links (such as Ethernet links) are present to a limited
degree in some provider networks. Where multicast LDP is used there
is a resultant need to be able to establish multicast LDP LSPs that
traverse these multi-access links.
The figure in section 2 may be modified to show how a multicast LDP
LSP needs to be carried over a multi-access link.
............ r2
: : |
: -----D--c--d--r3
: | :
: | :
s--a--b--A-----+-----E--e--r4
| : | :
| : | :
r1 : -----G--f--g--r5
: : |
........... h--r6
|
r7
Yasukawa and Farrel Page 6
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
It will be observed that, for an individual flow, a multi-access link
presents many of the same characteristics as a P2MP tunnel. That is,
there is a single entry point onto the link for the flow (this
corresponds to the ingress of the P2MP tunnel) and one or more exit
points from the link (corresponding to the leaves of the P2MP
tunnel).
In general, there may be some scaling differences between a network
in which P2MP tunnels are used, and a multi-access link. A
multi-access link in a provider network is likely to have a
relatively small number of stations, while P2MP tunnels may have
very many leaves, and an individual leaf may be present on very
many tunnels established from a large number of different roots.
3. Problem Statement
Multicast LSP traffic can be carried over an MPLS-TE network or a
multi-access link by having the upstream node replicate each packet
for each of the downstream nodes. Thus, on a multi-access link, the
upstream LSR would send a separate packet to each of the LSRs on the
link that participate in the multicast flow. Similarly, individual
P2P TE LSPs could be established through an MPLS-TE network to carry
the traffic across the network to remote LDP peers. However, in both
of these cases inefficient use is made of the network resources and
this may result in congestion on the links or in the sending node.
The intention is to avoid this problem by using a P2MP TE LSP in the
MPLS-TE network or utilizing the multicast facilities of the layer 2
technology of the multi-access link. If this is done, only a single
copy of the packet needs to be transmitted, and the packet will be
carried to all receivers in the most efficient way.
It should be obvious that if only one copy of an LDP packet is
transmitted, it can only carry one LDP label. Since this packet will
be replicated by the underlying technology (the P2MP TE LSP or the
layer 2 transfer mechanism) an identical copy of the packet will be
received by all next-hop LDP LSRs. That means that each next-hop LDP
LSR will be required to process the same label for the multicast
flow.
LDP labels are conventionally assigned by the downstream LSR
[RFC3031, RFC3036] which means that to efficiently carry multicast
LDP traffic over P2MP TE LSPs or multi-access links we need some
additional mechanism to ensure that the downstream next-hop LDP LSRs
can all use the same label for the same multicast flow.
Yasukawa and Farrel Page 7
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
4. Overview of Potential Solutions
This document examines three categories of solution.
- Upstream label allocation is proposed in [UPSTREAM]. In this
solution, which is applicable to P2MP TE tunnels and to
multi-access links, the upstream LSR is responsible for
coordinating, allocating, and distributing the labels used by the
downstream LSRs so that a single copy of the labeled packet may be
sent to all downstream LSRs.
- Upstream label suggestion re-uses the label suggestion procedures
of [RFC3473] to allow the upstream LSR to coordinate label
allocation through suggestion, but leaves the responsibility for
label allocation and distribution with the downstream LSR as in
[RFC3036]. This solution is also applicable to P2MP TE tunnels and
to multi-access links.
- The third solution is applicable only to P2MP TE LSPs, and involves
stitching multicast LSP segments to P2MP TE LSPs. This technique
avoids the requirement for label coordination by the upstream LSR,
but looses some of the benefits of aggregation within P2MP TE LSPs
in the core network.
Note that the procedures described in this document are such that
upstream label allocation, upstream label suggestion, and LSP
stitching could be used in other circumstances, but this document is
limited to considerations of multicast LSPs operating over P2MP
tunnels and multi-access links.
5. Upstream Label Allocation
A technique to solve the issue of coordination of labels between
downstream LSRs for multicast LDP LSPs is to have those labels
allocated and advertised by the upstream LSR [UPSTREAM].
This represents a change to the MPLS architecture [RFC3031] where
labels were assigned and advertised only by the downstream LSR, and
this change is documented in [UPSTREAM-ARCH].
5.1. Operational Procedures
The operational procedures for this solution are described fully in
[UPSTREAM] and are only summarized here for comparison with the other
suggested solutions. The reader should refer to [UPSTREAM] for a
definitive description of these procedures.
Yasukawa and Farrel Page 8
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
5.1.1. Agreement to Use Upstream Label Allocation
LDP peers agree that upstream label allocation may be used between
them by exchanging a capability indication on the LDP Hello message.
Neither LDP peer may use upstream label allocation unless both peers
have indicated that they support upstream label allocation.
5.1.2. Label Distribution
Labels for a particular multicast flow are allocated and distributed
by the upstream LSR. A new TLV is used to identify the label as an
upstream label allocation, and this is sent together with the
multicast FEC [P2MP-LDP] on a LabelMapping message from the upstream
LSR to each of the downstream LSRs.
5.1.3. Label Solicitation
A downstream LSR may request upstream label allocation for a specific
multicast FEC by sending a LabelRequest message to the upstream LSR
containing the multicast FEC TLV and a new TLV that requests upstream
label allocation. The upstream LSR responds using the procedures
described in 5.1.2.
5.1.4. Determining the Participating Downstream LSRs
To alternatives may be used. In the first case, the upstream LSR may
wait for a specific request for a label for a multicast flow. In this
case the downstream LSR determines that it is part of the multicast
flow, determines which is its upstream neighbor, and sends a
LabelRequest message as described in section 5.1.2. This procedure
may be termed Upstream-On-Demand label distribution.
Alternatively, the upstream LSR may distribute labels to all
connected downstream LSRs as described in section 5.1.2. This
procedure may be termed Upstream-Unsolicited label distribution.
5.1.5. Processing of Received Labels
An LSR that receives a labeled packet must determine the context for
the label before performing switching operations. If the LSR supports
its own label allocation (downstream label allocation) and also
supports label allocation by its upstream neighbor, it is possible
that the same label will be allocated by the LSR and its upstream
neighbor for different LSPs on the same link. The labels (and so the
LSPs) can be differentiated by the use of different Ethertypes that
indicate whether the labeled packet that is carried in a layer 2
frame uses an upstream or downstream allocated label.
Yasukawa and Farrel Page 9
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
Since a downstream LSR may have more than one upstream neighbor on
the same interface (either because the interface connects to a
multi-access link, or because the interface connects to a network in
which P2MP TE LSPs are used) and since these upstream neighbors
assign upstream labels independently, it is possible for two LSPs to
use the same incoming, upstream-allocated label on the same
interface. In order to distinguish the LSPs, the labels must be
managed according to the upstream neighbor; this gives rise to the
concept of "per-neighbor label spaces."
5.2. Comparison with Previous LDP Mechanisms
- As is made clear in [UPSTREAM-ARCH], upstream label allocation
represents a change to the MPLS architecture [RFC3031] in that
labels may now also be allocated and distributed by the upstream
LSR.
- As described in section 5.1.4, upstream label allocation requires
the use of the layer 2 Ethertype to distinguish LSPs using upstream
allocated labels from LSPs using downstream allocated labels.
- As described in section 5.1.4, upstream label allocation requires
the use of per-neighbor label spaces to differentiate LSPs using
labels allocated by different upstream neighbors.
- Upstream label distribution (on-demand or unsolicited) re-uses the
LabelRequest and LabelMapping messages (and all other LDP messages)
with their semantics preserved. It should be noted, however, that
the direction of exchange of such messages is reversed in upstream
label distribution compared to LDP as specified in [RFC3036]. That
is, the LabelRequest message is used by an LSR to request label
allocation, and the LabelMapping message is used by an LSR to
supply a label. The direction of flow these messages and of all
other label control LDP messages is altered depending on whether it
is the upstream or downstream LSR that allocates the label.
5.3. Applicability
5.3.1. P2MP TE Tunnels
The upstream label allocation technique is applicable to the use of
multicast LDP over P2MP TE Tunnels. In this case the upstream LSR is
the root of the tunnel, and the downstream LSRs are the leaves of the
tunnel. The root must have a targeted LDP session with each of the
leaves of the tunnel which means that the root must know about each
of the leaves, but this is normal for P2MP MPLS-TE tunnels.
Yasukawa and Farrel Page 10
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
Each leaf may be the leaf of multiple tunnels from the same root. In
this case, it is not necessary for the leaf to maintain a separate
label space for each tunnel as the upstream neighbor is the same in
each case.
An alternative implementation would be to treat each tunnel as an
interface and to manage labels per interface. This might give better
scaling properties where very many multicast LDP flows are aggregated
onto each tunnel, but would, however, require a separate LDP session
per tunnel which might negate any scaling benefits.
Each leaf may also be the leaf of multiple tunnels from different
roots. In this case, each root is a different upstream neighbor and
its labels are managed from separate per-neighbor label spaces.
The P2MP TE LSPs used to carry LDP multicast LSPs may be dynamically
established or pre-provisioned. P2MP TE LSPs can be pre-provisioned
according to management requests. For example, such LSPs can be set
up to connect LSRs that have targeted LDP adjacencies.
Alternatively, when an upstream LSR receives a targeted LabelRequest
message requesting an upstream label allocation for a new multicast
LSP as described in section 5.1.4, it SHOULD select a suitable
P2MP TE LSP to carry it. The mechanism for such a selection is out of
scope of this document, however, a significant issue with the dynamic
choice between existing P2MP TE LSPs is that it is not known, at the
time of receipt of the first LabelRequest message, which other leaves
will participate in the multicast LDP LSP. It is important that a
P2MP TE LSP be chosen that reaches each of the leaves that will
require to receive the LDP multicast LSP. The option of adding new
leaves to an existing P2MP TE LSP is functional.
A better applicability may be realized with the knowledge that core
networks typically serve to deliver traffic between remote sites that
have a strong association (for example, between sites of a multicast
VPN). In this case, a P2MP TE LSP may be sensibly pre-established
between the source site and each of the receiver sites, and all
multicast LDP LSPs associated with the VPN may be assigned to that
tunnel. Leaves may be added to or pruned from the P2MP TE LSP either
dynamically depending on demand from the LDP messages, or more
probably as a management action.
A P2MP TE LSP can be provisioned on demand according to the
requirements of the multicast LDP LSPs that it carries. If no
suitable pre-provisioned (either through configuration or through
dynamic operation) P2MP TE LSP exists, a new one can be established
in reaction to the exchange of LDP messages according to the
following rules.
Yasukawa and Farrel Page 11
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
- The upstream LSR that receives a LabelRequest message for a
multicast LDP LSP and cannot select an existing P2MP TE LSP,
establishes a new P2MP TE LSP with itself as the root and its
remote LDP peer as the only leaf. Once this LSP has been
established, the LDP message exchange can continue as previously
described.
- As new remote LDP peers send further LabelRequest messages for the
same LDP multicast LSP, the root of the P2MP TE LSP can simply add
leaves to the P2MP TE LSP. Leaves can also be pruned from the P2MP
TE LSP when they no longer participate in any multicast LDP LSPs
that use the P2MP TE LSP.
5.3.2. Multi-Access Links
Upstream label allocation is applicable to, and was developed
specifically for use on multi-access links. In this case, the
upstream LSR is just one hop away from the downstream LSRs across the
multi-access link. The upstream LSR has a normal LDP session with
each of the downstream LSRs which must be configured.
Each station on the multi-access link may act as an upstream LSR for
one or more multicast LSPs, and each may be a downstream LSR in one
or more multicast LSPs.
5.3.3. Mixing Upstream-Capable and Non-Upstream Capable LSRs
It is possible that an upstream LSR will have LDP sessions with
downstream LSRs some of which are capable of supporting upstream
label allocation, and some of which are not.
On a multi-access link this can be resolved. The upstream LSR uses an
upstream allocated label when sending a single packet for receipt by
all downstream LSRs that are capable of receiving such a label, and
uses pre-existing downstream label allocation techniques for all
other downstream LSRs. In this way packets are duplicated on the link
only for those downstream LSRs that cannot handle upstream allocated
labels.
Note, however, that because of the nature of the multi-access link, a
downstream LSR that is not capable of handling upstream allocated
labels will still receive packets from the upstream LSR labeled with
the upstream label if it is used for other downstream LSRs. This can
be overcome either by establishing specific broadcast groups for the
upstream label allocation capable LSRs within the layer 2 technology,
or by identifying the packets that carry upstream-allocated labels
through a new Ethertype: this second option is used in [UPSTREAM].
Yasukawa and Farrel Page 12
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
It is not possible to mix LSRs (leaves) that support upstream label
allocation with those that don't on P2MP TE tunnels because all
packets injected into the tunnel are delivered to all leaves (there
is no unicast technique within the tunnel as there is on a
multi-access link). If there is a requirement to support TE tunneling
of multicast LDP traffic from a root to a set of leaves some of which
can support upstream label allocation and some of which cannot, a
P2MP TE tunnel would be used between the root and all those leaves
that can support upstream label allocation, and individual P2P TE
tunnels would be used from the root to each of the leaves that did
not support the function.
5.4. Issues and Open Questions
Several questions remain unanswered in the current version of
[UPSTREAM]. The inclusion of these questions here does not imply a
criticism of this technique, but is provided to help complete the
analysis of this mechanism and to compare it to others.
1. How is the label space (upstream neighbor) identified within the
forwarding plane?
The issue here is that the downstream LSR must disambiguate labels
on received packets according to the upstream neighbor in order to
apply the per-neighbor label space. It knows that it must do this
because of the received Ethertype.
An option here is to use the source address from the layer 2 frame
in which the packet was received. This assumes that this
information is available in the layer 2 frame and is accessible to
the MPLS component.
2. How is an upstream allocated label identified within a label
stack?
While the use of an upstream label can be easily detected using
the new Ethertype if the label is at the top of the label stack,
this is not possible for labels lower down the stack (for example
when multicast LDP flows are carried within P2MP MPLS-TE tunnels).
It remains important to make this distinction to correctly process
the labels.
An option is to restrict the use of labels within a tunnel to be
only upstream allocated, or only downstream allocated. This
information can be exchanged during the signaling that establishes
the tunnel.
Yasukawa and Farrel Page 13
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
3. How does upstream label allocation work for Fast Re-Route?
This is probably relatively simple to achieve, but needs
specification.
4. What are the procedures if a downstream LSR rejects an upstream
allocated label?
This may happen if, for some reason, the downstream LSR cannot
process the supplied label value. In this case the downstream LSR
would reject the supplied label and the upstream LSR could either
move the entire LSP to a new label, or establish a P2P LSP hop for
the uncooperative downstream LSR.
6. Upstream Label Suggestion
At first glance, upstream label suggestion looks similar to upstream
label allocation in that the labels are coordinated by the upstream
LSR, but the mechanism borrows from label suggestion techniques
developed in GMPLS [RFC3473] while preserving the MPLS architecture
by retaining label allocation at the downstream LSR. In these ways,
upstream label suggestion is actually considerably different from
upstream label allocation and should be considered as a separate
technique, not a derivative solution.
Note that GMPLS includes the concept of an Upstream Label, but in
GMPLS, this concept applies to the label used for the reverse flow
of a bidirectional LSP. Care must be taken to avoid confusing the
two concepts.
6.1. Operational Procedures
The procedures for upstream label suggestion are currently supplied
in this document.
6.1.1. Agreement to Use Upstream Label Suggestion
Upstream label suggestion is requested on a per-LSP basis by the
downstream LSR (see subsequent sections). No prior agreement to use
upstream label suggestion is needed. A downstream LSR that does not
support the process will simply not request its use. An upstream LSR
that does not support the process will reject the requested process
as unknown.
Yasukawa and Farrel Page 14
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
6.1.2. Label Distribution
Label distribution for this model is from the downstream LSR. The
downstream LSR must, however, seek help from the upstream LSR to
coordinate the choice of a single label across multiple downstream
LSRs.
An LSR that wishes to use an LDP multicast LSP over a P2MP tunnel (or
over a multi-access link) sends a LabelMapping message to its
upstream neighbor using a targeted LDP session and including the
appropriate multicast FEC. However, instead of advertising the label
it wishes to see used for incoming traffic, it uses a special label
value (TBD) from the reserved range 0 to 15 to indicate that it
wishes the upstream LSR to suggest a label.
When the upstream LSR receives a LabelMapping containing a multicast
FEC and the label value that indicates that an upstream label
suggestion is required, it responds with a LabelRequest message. A
new "Suggested Label" TLV is added to the message (see definition
below), and the message MUST also contain the multicast FEC as
received in the LabelMapping message. If the upstream LSR is unable
or unwilling to suggest a label, it MUST respond with a LabelRelease
message indicating the received multicast FEC and the special label
value.
When a downstream LSR receives a LabelRequest message carrying a
Suggested Label TLV, it responds with a LabelMapping message using
that label if it is appropriate and suitable, or with an advisory
Notification message indicating the new status code "Suggested Label
not Accepted". At any time, the downstream LSR may decide to allocate
a label itself without coordination through the upstream LSR - in
this case, the upstream LSR will use that label for traffic to the
downstream LSR even if that means it must replicate packets.
In this way, no change to the sense of the LDP messages is required,
but an additional message exchange is needed. The label distribution
is essentially Downstream Unsolicited, but an extra consultation
exchange is used to achieve coordination of the allocated labels.
6.1.3. Downstream on Demand
An upstream LSR may also request label allocation by a downstream LSR
in Downstream On-Demand mode. If the upstream LSR is aware of the
need for a label for a multicast LDP to a particular downstream
neighbor it may send a LabelMapping with a Suggested Label TLV
without waiting for a LabelRequest message. The downstream LSR
responds as described in the previous section.
Yasukawa and Farrel Page 15
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
6.1.4. Determining the Participating Downstream LSRs
To alternatives may be used. In the first case, the upstream LSR may
wait for a specific request for a label for a multicast flow. In this
case the downstream LSR determines that it is part of the multicast
flow, determines which is its upstream neighbor, and sends a
LabelMapping message as described in section 6.1.2. This procedure
may be termed Downstream Unsolicited With Suggestion label
distribution.
Alternatively, the upstream LSR may suggest and request labels from
all connected downstream LSRs as described in section 6.1.3. This
procedure may be termed Downstream On-Demand With Suggestion label
distribution.
6.1.5. Processing of Received Labels
There is no substantial change to the processing of received labeled
packets described in section 5.1.5 except to note that because the
labels are allocated by the downstream LSR it is able to chose
whether or not it maintains per-neighbor or per-interface label
spaces. Further, this choice can even be made per-LSP. The trade-off
of packet replication versus per-neighbor label spaces is obvious,
but in this mode, the choice can be made by the downstream LSR.
Note that if it is determined to use per-neighbor label spaces then
the comparison between upstream label allocation and upstream label
suggestion may be simply made and depends on message flows and
architectural considerations, and not on data plane factors.
6.2. Protocol Extensions
An overview of protocol extensions is included here because there is
currently no other document describing this process.
The procedures described above require several minor protocol
extensions to LDP as described in [RFC3036] and [P2MP-LDP].
- Allocation of a reserved label value to indicate that upstream
label allocation is request. The value TBD is suggested.
- Acceptance of the Multicast FEC (as defined by [P2MP-LDP]) on a
LabelRequest message.
- Definition of a new Suggested Label TLV for inclusion on a
LabelRequest message. The format of this TLV is shown below.
Yasukawa and Farrel Page 16
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
- The definition of a new status code for use on an advisory
Notification message as follows:
Status Code E Status Data
Suggested Label not/ x TBD
Accepted
The Suggested Label TLV has the following format. The TLV type number
is TBD; it is suggested that it comes from the range 0x0200-0x02FF.
Note that the U bit is set and the F bit is clear.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| Suggested Label (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suggested Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Suggested Label
This is a 20-bit label value as specified in [RFC3032] represented
as a 20-bit number in a 4 octet field.
6.3. Comparison with Previous LDP Mechanisms
- Upstream label suggestion does not require a change to the MPLS
architecture. Labels are allocated and advertised by the downstream
LSR.
- Despite the fact that all labels are downstream allocated, it may
be necessary to distinguish between multicast and unicast labels
using a new layer 2 Ethertype so that a downstream LSR that does
not support these procedures can tell that it should ignore a
labeled packet on a multi-cast link.
- Per-neighbor label spaces may be used to differentiate LSPs using
labels allocated by different upstream neighbors.
- The semantics and direction of flow of the LDP messages are
retained and the LDP state machine may be preserved with only very
minor changes.
- A new message exchange is required over the existing LDP
procedures. The message exchange for Downstream Unsolicited With
Suggestion label distribution is shown in the figure below. It
should be contrasted with Downstream Unsolicited label distribution
where only the third message is used, and Downstream On-Demand
label distribution where the second and third messages are used.
Yasukawa and Farrel Page 17
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
Upstream LSR Downstream LSR
| |
| LabelMapping (special label) | (request a suggestion)
|<------------------------------|
| |
| LabelRequest (Suggested Label)| (make a suggestion)
|------------------------------>|
| |
| LabelMapping (label) | (advertise a label)
|<------------------------------|
6.4. Applicability
6.4.1. P2MP TE Tunnels
The technique of upstream label suggestion is applicable to the use
of multicast LDP over P2MP TE Tunnels. In this case the upstream LSR
is the root of the tunnel, and the downstream LSRs are the leaves of
the tunnel. The root must have a targeted LDP session with each of
the leaves of the tunnel which means that the root must know about
each of the leaves, but this is normal for P2MP MPLS-TE tunnels.
Each leaf may be the leaf of multiple tunnels from the same root. In
this case, it is not necessary for the leaf to maintain a separate
label space for each tunnel as the upstream neighbor is the same in
each case.
An alternative implementation would be to treat each tunnel as an
interface and to manage labels per interface. This might give better
scaling properties where very many multicast LDP flows are aggregated
onto each tunnel, but would, however, require a separate LDP session
per tunnel which might negate any scaling benefits.
Each leaf may also be the leaf of multiple tunnels from different
roots. In this case, each root is a different upstream neighbor and
its labels may be managed from separate label spaces.
As described for upstream label allocation, the P2MP TE LSPs used to
carry multicast LDP LSPs may be dynamically established or
pre-provisioned. The trigger for selection of a tunnel or dynamic
establishment of a new MPLS TE LSP is the receipt at the upstream LSR
of a targeted LabelMapping message requesting an upstream label
suggestion for a new multicast LDP LSP.
The same issue about the pre-knowledge of leaves exists and can be
approached in the same way as described in section 5.3.1.
Yasukawa and Farrel Page 18
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
6.4.2. Multi-Access Links
Upstream label suggestion is also applicable to use on multi-access
links. In this case, the upstream LSR is just one hop away from the
downstream LSRs across the multi-access link. The upstream LSR has a
normal LDP session with each of the downstream LSRs.
Each station on the multi-access link may act as an upstream LSR for
one or more multicast LSPs, and each may be a downstream LSR in one
or more multicast LSPs.
6.4.3. Mixing Suggestion-Capable and Non-Suggestion Capable LSRs
It is possible that an upstream LSR will have LDP sessions with
downstream LSRs some of which are capable of supporting upstream
label suggestion, and some of which are not.
On a multi-access link this does not cause any problems. The
downstream LSRs that want to use upstream label suggestion will
request its use, while the others will use existing [RFC3036]
behavior. In this way packets are duplicated on the link only for
those downstream LSRs that cannot handle upstream suggested labels.
Note, however, that because of the nature of the multi-access link, a
downstream LSR that is not capable of handling upstream suggested
labels will still receive packets from the upstream LSR labeled with
the suggested label if it is used for other downstream LSRs. This can
be overcome either by establishing specific broadcast groups for the
suggestion-capable LSRs within the layer 2 technology, or by
identifying the packets that carry these labels through a new
Ethertype as for upstream allocated labels described in section 5.
P2MP TE tunnels have the same issue as described for upstream
allocated labels in section 5.3.3. That is, only a single label can
be used for the multicast LDP traffic for a given flow when it is
carried in the tunnel. The solutions are as described in section
5.3.3.
6.5. Issues and Open Questions
As with upstream label allocation, several questions remain
unanswered in the work on upstream label suggestion to date. Some of
these questions are common with upstream label allocation because the
techniques have some elements in common. The inclusion of these
questions here does not imply a criticism of this technique, but is
provided to help complete the analysis of this mechanism and to
compare it to others.
Yasukawa and Farrel Page 19
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
1. How is the label space (upstream neighbor) identified within the
forwarding plane?
The issue here is the same as for upstream label allocation
(section 5.4, issue 1), but does not necessarily arise at all in
upstream label suggestion. That is, although the labels are
suggested on a per-neighbor basis, they are actually allocated by
the downstream LSR. Thus the downstream LSR can choose to maintain
per-interface or even global label spaces. In this case it is
neither necessary to identify that the label belongs to a
per-neighbor label space (using a new Ethertype) nor to identify
the neighbor itself.
There are obvious trade-offs to not using per-neighbor label
spaces that manifest themselves in the potential for more packet
duplication, more "label negotiation" during LSP establishment,
and increased configuration.
2. How do label stacks work?
As commented in the previous issue, labels are allocated by the
downstream LSR and may be taken from per-interface or global label
spaces (that is, not from per-neighbor label spaces). This means
that there is no requirement to identify that the label belongs to
a per-neighbor label space nor to identify the neighbor. This
makes label stacking operate as normal.
3. How does Fast Re-Route work?
More text is required to describe FRR, but because the labels are
allocated by the downstream LSRs, this is probably relatively
simple to achieve.
4. What are the procedures if a downstream LSR rejects an upstream
suggested label?
These procedures are described in section 6.1.
5. How is label contention handled?
Upstream label allocation with per-root-neighbor label space
resolves label contention by forcing coordination through the
upstream LSR. Upstream label suggestion avoids certain issues
with upstream label allocation, but the price is that although the
process described in the previous sections can arrange for the
same label to be allocated, it cannot handle the case where one of
the LSP's leaves cannot utilize the suggested label. In order to
understand the scope of this issue it is necessary to examine the
circumstances under which it can arise.
Yasukawa and Farrel Page 20
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
a If a downstream LSR is using the global label space, it is very
possible that a suggested label is already in use for some other
LSP.
b If devices have significantly different switching capabilities
it is possible that they will support only subsets of the full
label range and those subsets might not overlap.
c If there are multiple upstream LSRs that can communicate with
the same (or an overlapping) set of downstream LSRs then
per-interface label spaces do not solve the problem a., above.
This might arise on a multi-access network, but it can also
occur where multiple P2MP TE LSPs from different roots include
the same leaf, since those roots are all upstream LDP neighbors
of the leaf and are accessed through the same interface.
It may be argued that problem b. is not a soluble problem, but
that it is also unlikely to occur with MPLS packet switches that
can usually handle the full range of labels.
A solution to the remaining issues is to arrange for some form of
label set negotiation between the leaves and the root of any P2MP
TE LSP that may carry an LDP multicast LSP. This negotiation makes
the set of suitable labels for any LDP multicast LSP a property of
the P2MP TE LSP that is, a property of the P2MP tunnel that
connects the root to the leaves. With the knowledge of this label
set (which is the intersection of the label sets that each leaf is
willing to see used for an LDP multicast LSP), the root is able to
select a suitable label and suggest it using the techniques
described above.
A mechanism for label set negotiation for each P2MP TE LSP is TBD,
but it should be noted that GMPLS signaling [RFC3473] contains
mechanisms for label set negotiation and indication of acceptable
label sets.
7. LSP Stitching
LSP Stitching is defined in [STITCHING] as a mechanism where an
end-to-end MPLS LSP can use an intermediate LSP to provide a segment
of the path. Within the control plane the techniques applied are
similar to those used for tunneling, but within the data plane the
LSP segments are 'stitched' together so that there is a one-to-one
relationship between LSP segments, and no tunneling is used. In a
packet network, the use of stitching does not result in the
imposition of an additional label. LSP stitching is applicable to
the transport of a multicast LDP LSP across a network that supports
P2MP MPLS traffic engineering. In particular, a P2MP MPLS TE LSP may
be established across the core network, and the multicast LDP LSP
Yasukawa and Farrel Page 21
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
segments may be stitched to the P2MP TE LSP at the edges of the
network.
By way of illustration, the figure in section 2 may be used. Recall
that a multicast LSP is to be established from source s to receivers
r1 through r7. A P2MP TE LSP is established from A to the leaves D, E
and G as shown in the figure. The multicast LSP is established as
shown and is stitched to the P2MP TE LSP at the root (A) and at the
leaves D, E, and G.
Modifications to existing operational and signaling procedures are
required as described below.
7.1. Operational Procedures
This section sets out the operational mechanisms necessary to support
stitching of multicast LSPs to P2MP TE LSPs. Two approaches are
presented: in the first, the P2MP TE LSP is established and
maintained on demand; in the second, the P2MP TE LSP is
pre-provisioned (perhaps through management action) and is used by
the multicast LDP LSP as necessary.
7.1.1. Dynamic Establishment and Maintenance of P2MP TE LSP
Consider the first receiver wishing to join a multicast LDP LSP. It
advertises its availability and a label using the mechanisms
described in [P2MP-LDP]. For example, in the figure above, r4 may
advertise a label to LSR e. In its turn, LSR e will advertise a label
to LSR E.
When the multicast LDP label advertisement reaches the LSR at the
edge of the TE network, it is necessary to establish the TE LSP, but
this must be done using the processes described in [P2MP-RSVP] which
are initiated by the root of the TE LSP, in our example, LSR A. LSR
E, therefore, establishes a targeted LDP session with LSR A and
advertises the multicast FEC as for normal multicast LDP. The LSR on
the other side of the TE network (LSR A) then establishes the P2MP TE
LSP back across the network (from LSR A to LSR E). When the leaf of
the P2MP TE LSP (LSR E) returns a Resv message to say that it has
established the LSP, it stitches the P2MP TE LSP to the LDP multicast
LSP making the appropriate entries in its LFIB. When the root of the
P2MP TE LSP (LSR A) receives the Resv to say that the TE LSP has been
fully established, it continues the multicast LDP advertisement
upstream, and stitches the LDP multicast LSP to the P2MP TE LSP.
Further leaves are added to the P2MP TE LSP using the same process.
If the root of the P2MP TE LSP receives a targeted LabelMapping
message from an LDP peer advertising another branch to the LDP
multicast LSP it simply adds a new leaf to the P2MP TE LSP using the
Yasukawa and Farrel Page 22
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
techniques described in [P2MP-RSVP]. The new leaf will stitch the
LSPs together, and no further action will be required at the root of
the P2MP TE LSP.
Pruning operations follow similar principles. When the root of a P2MP
TE LSP receives a LabelWithdraw for a multicast LDP LSP, it prunes
the associated leaf form the P2MP TE LSP. Note that a root MAY choose
to delay this pruning operation if it believes that there is a high
likelihood of a new receiver causing the leaf to re-join the P2MP TE
LSP. Unstitching activity happens at the P2MP TE LSP leaf as a
condition of it sending the LabelWithdraw, and at the P2MP TE LSP
root when it removes the final leaf from the P2MP TE LSP (that is,
when it tears the LSP down).
Note that it is assumed that the downstream leaf LSR (LSR E in the
example) knows how to find the upstream root (LSR A) and to establish
a targeted LDP session across the TE network. This process is
similar to the way in which a downstream router determines the
upstream router that is the next hop on the path towards a multicast
source, and may be achieved through configuration or routing
protocols, but is outside the scope of this document. The targeted
LDP sessions MAY be established ahead of time as a result of
configuration or some membership protocol exchange, or MAY be
established on-demand.
7.1.2. Pre-Provisioned P2MP TE LSPs
The stitching technique described here can also make use of
pre-provisioned P2MP TE LSPs. Such LSPs can be set up as a result of
management action, and when a leaf sends a targeted LabelMapping
message to the root, there is no further requirement for RSVP-TE
signaling: all that is required is that the LSPs should be stitched.
Note that care is needed when a targeted LabeWithdraw is received at
the root of the P2MP TE LSP since it SHOULD NOT prune the associated
leaf from a pre-provisioned P2MP TE LSP. This feature, however, is a
matter for the implementation and is outside the scope of any
protocol procedures.
Note further that it is possible to mix the techniques described in
this section with the dynamic mechanism set out in the previous
section. That is, it is possible to dynamically add leaves to a
pre-provisioned LSP, and this can be done without requiring any
additional protocol procedures. Again, the root of the P2MP TE LSP
will need to take care when processing a received LabelWithdraw since
it SHOULD only prune those leaves that were added dynamically.
Yasukawa and Farrel Page 23
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
7.2. Protocol Extensions
Two protocol extensions are required for this technique.
- The targeted Label Advertisement from the P2MP TE LSP leaf to root
does not need to carry a label since the labels used will be
advertised using the P2MP RSVP-TE procedures. This issue should be
compared with the similar issue expressed in [STITCHING] and may be
solved by allowing the downstream LSR (the leaf) to proceed with
LDP label allocation and advertisement as normal, and having the
upstream LSR (the root) ignore the advertised label. The details of
this mechanism are to be completed depending on the developments of
[P2MP-LDP] and [STITCHING].
- The P2MP TE LSP leaf must be able to correlate the new P2MP TE LSP
with the LabelMapping message that it previously send to the P2MP
TE LSP root. This is achieved by adding a new, optional piece of
information to the destination-specific information signaled in the
Path message extensions defined in [P2MP-RSVP].
A new object, the Multicast FEC Payload object, is defined to carry
the multicast FEC as advertised in the LabelMapping. The precise
format of this object is for future study depending on the
developments of [P2MP-LDP].
Note that as an alternative, the S2L SUB-LSP Objects [P2MP-RSVP]
could be defined to allow TLVs. The required information could then
be included in a TLV in this object.
7.3. Applicability
Note that upstream label choice is not an issue in this technique,
and this is a considerable advantage. That is, there is no need to
coordinate the labels used to send traffic to each of the leaves of
the P2MP TE LSP because the P2MP TE LSP is not being used as a
tunnel.
On the other hand, it is in the nature of LSP stitching that traffic
cannot be aggregated. That is, each P2MP TE LSP can carry the traffic
for precisely one multicast LSP. In some circumstances this may be
considered a major disadvantage, but aggregation is also one of the
objectives identified in section 2.
This mechanism, therefore, is a benefit where there is a desire to
provide advanced network functions (traffic engineering, protection,
resource reservations, etc.) for multicast MPLS traffic as it is
carried across the core, but is of no value where it is important to
collect that traffic together to achieve benefits of aggregation.
Yasukawa and Farrel Page 24
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
Note that in many circumstances the choice of a suitable P2MP TE LSP
to carry multiple multicast LDP LSPs may be ambiguous because each
multicast LDP LSP may have a different set of receivers requiring
different leaves for the P2MP TE LSP. In this case a 1:1 relationship
between P2MP TE LSP and LDP multicast LSP may not be considered an
impediment.
7.3.1. Applicability to Multi-Access Links
The stitching solution is not immediately applicable to multi-access
links because it depends on the existence of a transit P2MP TE LSP.
It is possible to consider installing P2MP TE LSPs on the
multi-access link however, this will simply push all of the questions
and issues into the signaling procedures for that LSP. For example,
the P2MP TE LSP will need to be established so that only a single
packet is sent on the multi-access link and this will require
coordination of labels within the signaling used for the P2MP TE LSP
(RSVP-TE).
[UPSTREAM] starts to suggest some appropriate signaling extensions
for RSVP-TE on multi-access links for upstream label allocation, and
the label suggestion techniques of [RFC3473] might be used to offer
upstream label suggestion.
The only obvious advantage to this approach would be if it proved to
be necessary to extend only one protocol for upstream label
allocation/suggestion. That is, if stitching was selected as the only
solution for carrying multicast LDP over P2MP TE LSPs and
multi-access links, and if RSVP-TE needed anyway to be extended to
establish P2MP TE LSPs over multi-access links.
8. Security Considerations
TBD
This section will need to evaluate the comparative security issues
for all three proposed solutions.
9. IANA Considerations
This document will propose some minor extensions to LDP that may
require the allocation of new code points under the care of IANA. A
future version of this document will include the relevant
information.
10. Acknowledgements
The authors would like to thank Dean Cheng, Ina Minei and Eric Rosen
for their comments on this document.
Yasukawa and Farrel Page 25
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
11. Intellectual Property Considerations
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.
12. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling - Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[P2MP-RSVP] Aggarwal, R., Papadimitriou, D., and Yasukawa, S.,
"Extensions to RSVP-TE for Point to Multipoint TE
LSPs", draft-ietf-mpls-rsvp-te-p2mp, work in
progress.
[P2MP-LDP] Minei, I., et al., "Label Distribution Protocol
Extensions for Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths",
draft-minei-wijnands-mpls-ldp-p2mp, work in progress.
[STITCHING] Ayyangar, A., and Vasseur, J-P., "LSP Stitching with
Generalized MPLS TE", draft-ietf-ccamp-lsp-stitching,
work in progress.
Yasukawa and Farrel Page 26
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
[UPSTREAM] Aggarwal, R., and Le Roux, J-L., "MPLS Upstream Label
Assignment for LDP", draft-raggarwa-mpls-ldp-upstream
work in progress.
[UPSTREAM-ARCH] Aggarwal, R., Rekhter, Y., and Rosen, E., "MPLS
Upstream Label Assignment and Context Specific Label
Space", draft-raggarwa-mpls-upstream-label, work in
progress.
13. Informational References
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon,
"Multiprotocol Label Switching Architecture",
RFC 3031, January 2001.
[RFC3036] Andersson, L. et al., "LDP Specification", RFC 3036,
January 2001.
[RFC3209] Awduche, et al, "Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001.
[P2MP-SIG-REQ] Yasukawa, S. (Editor), "Signaling Requirements for
Point to Multipoint Traffic Engineered MPLS LSPs",
draft-ietf-mpls-p2mp-sig-requirement, work in
progress.
[P2MP-LDP-REQ] J-L. Le Roux et al,. "Requirements for
point-to-multipoint extensions to the Label
Distribution Protocol", draft-leroux-mpls-mp-ldp-reqs
work in progress.
14. Authors' Addresses
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
Adrian Farrel
Old Dog Consulting
EMail: adrian@olddog.co.uk
Yasukawa and Farrel Page 27
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005
15. Full 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.
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.
Yasukawa and Farrel Page 28