Network Working Group IJsbrand Wijnands
Internet Draft Bob Thomas
Expiration Date: September 2005 Cisco Systems, Inc.
Yuji Kamite
Hitoshi Fukuda
NTT Communications
March 2005
Multicast Extensions for LDP
draft-wijnands-mpls-ldp-mcast-ext-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."
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Wijnands, et al. [Page 1]
Internet Draft draft-wijnands-mpls-ldp-mcast-ext-00.txt March 2005
Abstract
Forwarding multicast packets efficiently over an MPLS core requires
Point-to-Multi-Point (P2MP) or Multi-Point-to-Multi-Point (MP2MP)
LSP's between one or more Ingress routers and one or more Egress
routers. For efficient forwarding core LSRs need to replicate
labeled multicast packets where the branches of the P2MP/MP2MP tree
diverge. This draft specifies LDP extensions that enable it to build
P2MP/MP2MP LSPs in a receiver initiated manner.
Table of Contents
1 Specification of Requirments ....................... 2
2 Terminology ........................................ 3
3 Introduction ....................................... 3
4 Label distribution ................................. 3
5 Label allocation ................................... 4
6 MP-T FEC element ................................... 4
7 In-band signaling using LDP ........................ 5
8 Out-of-band signaling with LDP ..................... 5
9 Building a P2MP LSP tree ........................... 6
9.1 Label mapping ...................................... 6
9.2 Label withdraw ..................................... 6
10 Building a MP2MP tree .............................. 7
11 Assigning Labels for MP2MP upstream Traffic ........ 9
12 Acknowledgments .................................... 10
13 References ......................................... 10
13.1 Normative References ............................... 10
13.2 Informational References ........................... 10
14 Authors' Addresses ................................. 11
15 Full Copyright Statement ........................... 11
16 Intellectual Property .............................. 12
1. Specification of Requirments
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.
Wijnands, et al. [Page 2]
Internet Draft draft-wijnands-mpls-ldp-mcast-ext-00.txt March 2005
2. Terminology
P2MP - Point to Multipoint Label Switched Tree.
MP2MP - Multipoint to Multipoint Label Switched Tree.
MP-T - Multipoint Tree, either a P2MP or MP2MP Tree.
Ingess - Router that is a sender on the MP-T.
Egress - Router that is a receiver of a MP-T.
Root - Router that acts as the Rendezvous point of the MP-T.
3. Introduction
Multicast trees are built using Protocol Indenpendent Multicast
[PIMv2]. PIM supports three different modes of operation: PIM
sparse-mode, PIM bidir [BIDIR] and PIM SSM. This draft specifies
extensions to LDP that enable it to build point-to-multipoint and
multipoint-to-multipoint trees for MPLS packet forwarding. These
P2MP and MP2MP MPLS trees are comparable to multicast PIM SSM and PIM
Bidir mode trees and may be used to support multicast over MPLS
LSP's. This draft does not specify procedures analogous to PIM
sparse-mode multicast.
PIM is a receiver driven soft state periodic protocol that builds
trees to a source or rendezvous point. Its receiver driven nature
allows it to scale well with dynamic multicast group membership and
large receiver populations. A router forwards tree membership
upstream, but does not forward any information about downstream
receivers. LDP extensions in this draft support receiver driven
construction of MP-T's. An advantage that the LDP extensions for
multicast have over PIM extensions for signaling labels is that LDP
has built-in reliability and flow control.
4. Label distribution
The labels which are mapped to MP-T LSPs are distributed by LDP in
Downstream Unsolicited Ordered Mode and retained using the
Conservative Label Retention mode. An LSR distributes the label for
an MP-T LSP to an upstream peer only if the peer is the its next hop
for the root of the MP-T.
Wijnands, et al. [Page 3]
Internet Draft draft-wijnands-mpls-ldp-mcast-ext-00.txt March 2005
5. Label allocation
Since the extensions for signaling MP-T's use downstream label
allocation MP-T LSPs may share the platform wide label space with
unicast LSPs. The MPLS forwarding engine is reponsible for deciding
to replicate packets using information supplied by LDP. Since MP-T
and unicast LSPs share the same label space there is no need for a
separate LDP session for MP-T's.
6. MP-T FEC element
The MP-T FEC element identifes an MP-T by means of the tree's root
address, the tree type and information that is opaque to core LSRs.
MP-T type FEC Element encoding:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MP-T Type(TBD)| Address Family | Address Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree Type(TBD)| Opaque Len | Opaque value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MP-T Type
MP-T type FEC element, value to be assigned by IANA.
Address family
Two octet quantity containing a value from ADDRESS FAMILY
NUMBERS in [RFC1700] that encodes the address family for the
Root address field.
Address Length
Length of the Root address value in octets.
Root Address
The root address of the MP-T. Used by receiving LSR to
determine the next-hop toward the MP-T root.
Tree Type
1 octet that identifies the tree type ie.
- P2MP LSP.
Wijnands, et al. [Page 4]
Internet Draft draft-wijnands-mpls-ldp-mcast-ext-00.txt March 2005
- MP2MP downstream LSP.
- MP2MP upstream LSP.
Opaque Len
Length of the opaque value in octets.
Opaque value
Variable length opaque value that uniquely identifies the MP-T.
The triple <Root Address, Tree Type, Opaque Value> uniquely identifies
the MP-T. LDP uses the Root Address to determine the upstream LSR
toward the MP-T; the Tree Type determines the nature of LDP
protocol interactions required to establish the MP-T LSP; and, the
Opaque Value carries information that may be meaningful to edge LSRs.
7. In-band signaling using LDP
LDP is used to build Label Switched paths through a network. The
packets that traverse the LSP are not of interest to LDP. Edge LSRs
may use the Opaque field of the MP-T FEC element to encode multicast
stream information. Egress LSRs may encode the source and group for
a multicast stream in the Opaque field. Of course, different Egress
LSRs which receive the same multicast stream must use the same
source/group encoding. Such an opaque value could be used to signal
the Root LSR which multicast stream is to be forwared on the MP-T.
Specification of such encodings is outside the scope of this draft.
The multicast component that wishes to receive multicast packets over
a LDP created MP-T creates the opaque FEC value. Depending on the
different applications there will be different Opaque FEC encodings.
Different FEC encodings are to be documented elsewhere.
8. Out-of-band signaling with LDP
When an egress router wishes to receive a multicast stream over a
MP-T it needs to know the identifier of that MP-T. Using in-band
signaling the egress router can create the MP-T identifier (Opaque
FEC) using a pre-defined algorithm, so there no need for other
signaling. If the egress router is not able to use in-band signaling,
for example when different multicast streams are aggregated over the
same MP-T then an out-of-band form of signaling is required to learn
the MP-T identifier. Such out-of-band signaling is beyond the scope
of this document.
Wijnands, et al. [Page 5]
Internet Draft draft-wijnands-mpls-ldp-mcast-ext-00.txt March 2005
9. Building a P2MP LSP tree
In order for a set of LSRs to become egress LSRs of the same P2MP or
MP2MP LSP, they must encode the same "root node" and "opaque
identifier" values into the FEC element of the LDP Mapping messages
that they send. How they determine what the proper root node and
opaque identifier values are is outside the scope of this
specification.
9.1. Label mapping
An LSR which is setting up a particular MP-T only sends a Label
Mapping Message for a P2MP LSP to the LSR which is to be its
"upstream neighbor" on that LSP. The upstream neighbor is the one
which is the next hop on the best path to the root. If there are
multiple paths to the root which are equally good, one is chosen.
However, once a label for a given P2MP LSP has been advertised to an
upstream LSR, no further label mapping messages for that LSP are sent
upstream, until such time as the label has been withdrawn, released,
or the LDP connection has failed.
When an LSR receives a Label Mapping it determines if it already has
state for this MP-T. If it does, it updates its MPLS forwarding
engine to reflect the new MP-T branch.
If the receiving LSR does not have state and is not the the Root LSR
for the MP-T it allocates a label, sends a Label Mapping for the MP-T
toward the Root LSR, and installs the binding on its chosen upstream
interface. This process is repeated until a Label Mapping message
for the MP-T reaches the Root LSR.
If the receiving LSR is the Root, it simply informs any subscribing
applicaton that the P2MP tree exists. How this is done is beyond the
scope of this document.
9.2. Label withdraw
When an MP-T egress LSR is no longer interested in an MP-T it
withdraws its label for the MP-T by means of a Label Withdraw message
using the MP-T FEC Element to identify the MP-T.
The LSR receiving a Label Withdraw message for an MP-T from a peer
updates its MPLS forwarding engine by removing the output information
for the MP-T that corresponds to the peer and sends a Label Release
message in reply. If no output information for the MP-T remains in
its MPLS forwarding engine the LSR sends a Label Withdraw for the
Wijnands, et al. [Page 6]
Internet Draft draft-wijnands-mpls-ldp-mcast-ext-00.txt March 2005
MP-T upstream.
10. Building a MP2MP tree
A MP2MP LSP is much like a P2MP LSP, is has a Root node and multiple
LSP-egress routers. The big difference compared with a P2MP tree is
that there will be multiple senders that can forward MPLS packets
upstream in the direction of the tree root. Each LSP-egress can be a
LSP-ingress router for the same tree. The root node for a P2MP tree
is always the same as the LSP-ingress router. This is not the case
for MP2MP trees, it can be an LSP-ingress router but can also be a
P-router in the core.
MPLS forwards packets based on the incoming label. The incomming
label identifies the next-hop(s) to which the MPLS packet should be
sent. For any MP-T tree there can be multiple next-hops. For an P2MP
tree there is only one interface that receives (i.e has forwarding
state for) packets belonging to the tree. For MP2MP there is some
set of interfaces which have state for the tree. Packets received on
any of these interfaces are replicated to each of the other members
of this set.
From the perspective of a given LSR, a MP2MP "tree" consists of n
P2MP LSPs, where n is the number of interfaces (upstream +
downstream) on the tree. Thus the forwarding state if O(number of
interfaces). If you instead used one P2MP LSP for each member of the
tree, your state would be O(number of members), which scales much
more poorly.
Root
+---+ +---+ +---+ +---+ +---+
Rcv |PE1|------|P1 |-------| P | -----|P3 |----|PE2| Rcv
+---+ +---+ +---+ +---+ +---+
|S0
|S1
+---+
|P2 |
+---+
S2 | | S3
+---+ +---+ | | +---+ +---+
Rcv |PE3|------|P4 |------- -----|P5 |----|PE4| Rcv
Src +---+ +---+ +---+ +---+
Figure 1.
Wijnands, et al. [Page 7]
Internet Draft draft-wijnands-mpls-ldp-mcast-ext-00.txt March 2005
Router P4 sends a label mapping to P2 and tells P2 to use label L2 for
downstream traffic. Router P5 does the same and makes P2 assigned L3
for downstream traffic. If we look at P2 the downstream state is as
follows.
Incoming Outgoing
----------------------------
| L1, S1 | L2, S2 |
| | L3, S3 |
----------------------------
Table 1.
Based on the label mapping send from P4 router P2 will send a label
mapping reply to P4 with a label that is required for upstream traffic
to P2. Same will happen for the upstream state from P5. Router P2
tells router P5 to use label L5 for upstream traffic.
From P2 to the root of the tree (P) the same protocol operations
occur. We send a label mapping including a downstream label L1 (see
table 1) and we receive an upstream label L6 mapping back for the
upstream state. The upstream label we received in the label mapping
reply is shared between the 2 upstream states since they both need to
go to the same root via the same path, so we merge them
together. Router P2 has the following upstream states:
Incoming Outgoing
----------------------------
| L4, S2 | L6, S1 |
----------------------------
Table 2.
Incoming Outgoing
----------------------------
| L5, S3 | L6, S1 |
----------------------------
Table 3.
The P (root) router will have the following upstream state.
Incoming Outgoing
----------------------------
| L6, S0 | |
----------------------------
Table 4.
Wijnands, et al. [Page 8]
Internet Draft draft-wijnands-mpls-ldp-mcast-ext-00.txt March 2005
The upstream state has been setup and packets can travel to the root
of the tree. However, while forwarding on a MP2MP tree we want to send
packets down the tree on intermediate nodes while packets travel
upstream. That means packets received from PE3 and PE4 need to be sent
to P5 via P2. We don't need to depend on the root to send the packets
downstream. We do this by merging the downstream state and the
upstream states. Each upstream state will copy the interfaces from the
downstream state replication list, except if it's the same as its
incoming interface. So the upstream state's on router P2 look like
this:
Incoming Outgoing
----------------------------
| L4, S2 | L6, S1 |
| | L3, S3 |
----------------------------
Table 5.
Incoming Outgoing
----------------------------
| L5, S3 | L6, S1 |
| | L2, S2 |
----------------------------
Table 6.
Using the technique of creating specific upstream states in
combination with merging the downstream replication list we are able to build a
full feature MP2MP LSP tree. The LSP tree does contain more then one
LSP path which costs extra labels, but the advantage is that the
forwarding logic does not need to deal with any specific forwarding
exceptions like we have in PIM bidir trees (forwarding packet that are
received on an Outgoing Interface List).
11. Assigning Labels for MP2MP upstream Traffic
To support MP2MP (bidirectional tree) LSP's we need to setup both a
downstream and a upstream LSP. The downstream path has the same
protocol operation as is used for P2MP LSP's, the upstream path is
different. The upstream path is setup in response to the downstream
path that is build. For a label mapping we sent to an upstream
router, the upstream router sends a label mapping in the opposite
direction to assign us a label for upstream traffic for this MP2MP
FEC.
The label mapping for the upstream path has the same encoding as the
downstream path. To be able to distinguish between the two we use the
Wijnands, et al. [Page 9]
Internet Draft draft-wijnands-mpls-ldp-mcast-ext-00.txt March 2005
Tree type encoded in the MP-T FEC. If an LSR receives a label
mapping of the type "upstream LSP" then this router will respond with
a label mapping of type "downstream LSP". When the downstream router
receives this label mapping it knows what this labbel mapping is for
the upstream path.
12. Acknowledgments
The authors would like to thank Arjen Boers, Eric Rosen, Nidhi
Bhaskar, Toerless Eckert and George Swallow for their contribution.
13. References
13.1. Normative References
[MPLS] "Multiprotocol Label Switching Architecture", Rosen, E.,
Viswanathan, A. and R. Callon, RFC 3031, January 2001.
[BIDIR] "Bi-directional Protocol Independent Multicast", Handley,
Kouvelas, Speakman, Vicisano, June 2002, <draft-ietf-pim-bidir-
04.txt>
[PIMv2] "Protocol Independent Multicast - Sparse Mode (PIM-SM)",
Fenner, Handley, Holbrook, Kouvelas, December 2002, draft-ietf-pim-
sm-v2-new-06.txt.
[LDP] "LDP Specification", Andersson, Doolan, Feldman, Fredette,
Thomas, January 2001, rfc3036.
13.2. Informational References
[MPLS-PIM] "Using PIM to Distribute MPLS Labels for Multicast
Routes", Farinacci, Rekhter, Rosen, Qian, November 2000, <draft-
farinacci-mpls-multicast-03.txt>
[RFC2547bis] "BGP/MPLS VPNs", Rosen, et. al., November 2002, draft-
ietf-ppvpn-rfc2547bis-03.txt
Wijnands, et al. [Page 10]
Internet Draft draft-wijnands-mpls-ldp-mcast-ext-00.txt March 2005
14. Authors' Addresses
IJsbrand Wijnands
Cisco Systems, Inc.
De kleetlaan 6a
1831 Diegem
Belgium
E-mail: ice@cisco.com
Bob Thomas
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA, 01719
E-mail: rhthomas@cisco.com
Yuji Kamite
NTT Communications Corporation
Tokyo Opera City Tower
3-20-2 Nishi Shinjuku, Shinjuku-ku,
Tokyo 163-1421,
Japan
Email: y.kamite@ntt.com
Hitoshi Fukuda
NTT Communications Corporation
1-1-6, Uchisaiwai-cho, Chiyoda-ku
Tokyo 100-8019,
Japan
Email: hitoshi.fukuda@ntt.com
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."
Wijnands, et al. [Page 11]
Internet Draft draft-wijnands-mpls-ldp-mcast-ext-00.txt March 2005
16. Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Wijnands, et al. [Page 12]