draft-ietf-mpls-mldp-in-band-signaling-00.txt   draft-ietf-mpls-mldp-in-band-signaling-01.txt 
Network Working Group I. Wijnands (Editor) Network Working Group I. Wijnands (Editor)
Internet-Draft T. Eckert Internet-Draft T. Eckert
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: July 22, 2010 N. Leymann Expires: August 30, 2010 N. Leymann
Deutsche Telekom Deutsche Telekom
M. Napierala M. Napierala
AT&T Labs AT&T Labs
January 18, 2010 February 26, 2010
mLDP based in-band signaling for Point-to-Multipoint and Multipoint-to- mLDP based in-band signaling for Point-to-Multipoint and Multipoint-to-
Multipoint Label Switched Paths Multipoint Label Switched Paths
draft-ietf-mpls-mldp-in-band-signaling-00 draft-ietf-mpls-mldp-in-band-signaling-01
Abstract
Suppose an IP multicast tree, constructed by Protocol Independent
Multicast (PIM), needs to pass through an MPLS domain in which
Multipoint LDP (mLDP) Point-to-Multipoint and/or Multipoint-to-
Multipoint Labels Switched Paths (LSPs) can be created. The part of
the IP multicast tree that traverses the MPLS domain can be
instantiated as a multipoint LSP. When a PIM Join message is
received at the border of the MPLS domain, information from that
message is encoded into mLDP messages. When the mLDP messages are
received at the border of the next IP domain, the encoded information
is used to generate PIM messages that can be sent through the IP
domain. The result is an IP multicast tree consisting of a set of IP
multicast sub-trees that are spliced together with a multipoint LSP.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 22, 2010. This Internet-Draft will expire on August 30, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
When an IP multicast tree needs to pass through an MPLS domain, it is This document may contain material from IETF Documents or IETF
advantageous to map the tree to a Point-to-Multipoint or Multipoint- Contributions published or made publicly available before November
to-Multipoint Label Switched Path. This document specifies a way to 10, 2008. The person(s) controlling the copyright in some of this
provide a one-one mapping between IP multicast trees and Label material may not have granted the IETF Trust the right to allow
Switched Paths using mLDP signaling. The IP multicast control modifications of such material outside the IETF Standards Process.
messages are translated into MPLS control messages when they enter Without obtaining an adequate license from the person(s) controlling
the MPLS domain, and are translated back into IP multicast control the copyright in such materials, this document may not be modified
messages at the far end of the MPLS domain. The IP multicast control outside the IETF Standards Process, and derivative works of it may
information is coded into the MPLS control information in such a way not be created outside the IETF Standards Process, except to format
as to ensure that a single Multipoint Label Switched Path gets set up it for publication as an RFC or to translate it into languages other
for each IP multicast tree. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . 4 1.1. Conventions used in this document . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. In-band signaling for MP LSPs . . . . . . . . . . . . . . . . 5 2. In-band signaling for MP LSPs . . . . . . . . . . . . . . . . 4
2.1. Transiting IP multicast source trees . . . . . . . . . . . 6 2.1. Transiting Unidirectional IP multicast Shared Trees . . . 5
2.2. Transiting IP multicast bidirectional trees . . . . . . . 6 2.2. Transiting IP multicast source trees . . . . . . . . . . . 5
2.3. Transiting IP multicast shared Trees . . . . . . . . . . . 7 2.3. Transiting IP multicast bidirectional trees . . . . . . . 6
3. LSP opaque encodings . . . . . . . . . . . . . . . . . . . . . 7 3. LSP opaque encodings . . . . . . . . . . . . . . . . . . . . . 7
3.1. Transit IPv4 Source TLV . . . . . . . . . . . . . . . . . 7 3.1. Transit IPv4 Source TLV . . . . . . . . . . . . . . . . . 7
3.2. Transit IPv6 Source TLV . . . . . . . . . . . . . . . . . 8 3.2. Transit IPv6 Source TLV . . . . . . . . . . . . . . . . . 7
3.3. Transit IPv4 bidir TLV . . . . . . . . . . . . . . . . . . 8 3.3. Transit IPv4 bidir TLV . . . . . . . . . . . . . . . . . . 8
3.4. Transit IPv6 bidir TLV . . . . . . . . . . . . . . . . . . 9 3.4. Transit IPv6 bidir TLV . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
7. Contributing authors . . . . . . . . . . . . . . . . . . . . . 10 7. Contributing authors . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The mLDP specification [I-D.ietf-mpls-ldp-p2mp] describes mechanisms The mLDP specification [I-D.ietf-mpls-ldp-p2mp] describes mechanisms
skipping to change at page 4, line 22 skipping to change at page 4, line 22
particular enduser multicast packets with any particular LSP. Other particular enduser multicast packets with any particular LSP. Other
drafts, like [I-D.ietf-l3vpn-2547bis-mcast], describe applications in drafts, like [I-D.ietf-l3vpn-2547bis-mcast], describe applications in
which out-of-band signaling protocols, such as PIM and BGP, are used which out-of-band signaling protocols, such as PIM and BGP, are used
to establish the mapping between an LSP and the multicast packets to establish the mapping between an LSP and the multicast packets
that need to be forwarded over the LSP. that need to be forwarded over the LSP.
This draft describes an application in which the information needed This draft describes an application in which the information needed
to establish the mapping between an LSP and the set of multicast to establish the mapping between an LSP and the set of multicast
packets to be forwarded over it is carried in the "opaque value" packets to be forwarded over it is carried in the "opaque value"
field of an mLDP FEC element. When an IP multicast tree (either a field of an mLDP FEC element. When an IP multicast tree (either a
source-specific tree or a bidirectional tree) enters the MPLS source-specific tree or a bidirectional tree) enters the MPLS network
network, the IP multicast control messages used to set up the tree the (S,G) or (*,G) information from the IP multicast control plane
are translated into mLDP messages. The (S,G) or (*,G) information state is carried in the opaque value field of the mLDP FEC message.
from the IP multicast control messages is carried in the opaque value As the tree leaves the MPLS network, this information is extracted
field of the mLDP FEC message. As the tree leaves the MPLS network, from the FEC element and used to build the IP multicast control
this information is extracted from the FEC element and used to build plane. PIM messages can be sent outside the MPLS domain. Note that
the IP multicast control messages that are sent outside the MPLS although the PIM control messages are sent periodically, the mLDP
domain. Note that although the IP multicast control messages are messages are not.
sent periodically, the mLDP messages are not.
Each IP multicast tree is mapped one-to-one to a P2MP or MP2MP LSP in Each IP multicast tree is mapped one-to-one to a P2MP or MP2MP LSP in
the MPLS network. This type of service works well if the number of the MPLS network. This type of service works well if the number of
LSPs that are created is under control of the MPLS network operator, LSPs that are created is under control of the MPLS network operator,
or if the number of LSPs for a particular service are known to be or if the number of LSPs for a particular service are known to be
limited in number. limited in number.
1.1. Conventions used in this document 1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 5, line 12 skipping to change at page 5, line 12
an source IP address and/or IP multicast destination address, also an source IP address and/or IP multicast destination address, also
refered to as (S,G) and (*,G). refered to as (S,G) and (*,G).
mLDP : Multicast LDP. mLDP : Multicast LDP.
Transit LSP : An P2MP or MP2MP LSP whose FEC element contains the Transit LSP : An P2MP or MP2MP LSP whose FEC element contains the
(S,G) or (*,G) identifying a particular IP multicast distribution (S,G) or (*,G) identifying a particular IP multicast distribution
tree. tree.
In-band signaling : Using the opaque value of a mLDP FEC element to In-band signaling : Using the opaque value of a mLDP FEC element to
signal multicast route information. carry the (S,G) or (*,G) indentifying a particular IP multicast
tree.
P2MP LSP: An LSP that has one Ingress LSR and one or more Egress P2MP LSP: An LSP that has one Ingress LSR and one or more Egress
LSRs. LSRs.
MP2MP LSP: An LSP that connects a set of leaf nodes, acting MP2MP LSP: An LSP that connects a set of leaf nodes, acting
indifferently as ingress or egress. indifferently as ingress or egress.
MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP. MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP.
Ingress LSR: Source of the P2MP LSP, also referred to as root node. Ingress LSR: Source of the P2MP LSP, also referred to as root node.
skipping to change at page 5, line 35 skipping to change at page 5, line 36
referred to as leaf node in the case of P2MP and MP2MP LSPs. referred to as leaf node in the case of P2MP and MP2MP LSPs.
Transit LSR: An LSR that has one or more directly connected Transit LSR: An LSR that has one or more directly connected
downstream LSRs. downstream LSRs.
2. In-band signaling for MP LSPs 2. In-band signaling for MP LSPs
Suppose an LSR, call it D, is attached to a network that is capable Suppose an LSR, call it D, is attached to a network that is capable
of MPLS multicast and IP multicast, and D has the desire to create IP of MPLS multicast and IP multicast, and D has the desire to create IP
multicast tree due to a certain IP multicast event, like a PIM Join, multicast tree due to a certain IP multicast event, like a PIM Join,
MSDP Source Announcement (SA) [RFC3618] or RP discovery. Suppose MSDP Source Announcement (SA) [RFC3618], BGP Source Active auto-
that D can determine that the IP multicast tree needs to travel discovery route [I-D.rekhter-pim-sm-over-mldp] or RP discovery.
through the MPLS network until it reaches some other LSR, U. For Suppose that D can determine that the IP multicast tree needs to
instance, when D looks up the route to the Source or Rendezvous Point travel through the MPLS network until it reaches some other LSR, U.
(RP) [RFC4601] of the IP multicast tree, it may discover that the For instance, when D looks up the route to the Source or Rendezvous
route is a BGP route with U as the BGP next hop. Then D may chose to Point (RP) [RFC4601] of the IP multicast tree, it may discover that
set up a P2MP or MP2MP LSP, with U as root, and to make that LSP the route is a BGP route with U as the BGP next hop. Then D may
become part of the IP multicast distribution tree. Note that other chose to set up a P2MP or MP2MP LSP, with U as root, and to make that
methods are possible to determine that an IP multicast tree is to be LSP become part of the IP multicast distribution tree. Note that
transported across an MPLS network using P2MP or MP2MP LSPs, these other methods are possible to determine that an IP multicast tree is
methods are outside the scope of this document. to be transported across an MPLS network using P2MP or MP2MP LSPs,
these methods are outside the scope of this document.
Source or RP addresses that are reachable in a VPN context are Source or RP addresses that are reachable in a VPN context are
outside the scope of this document. outside the scope of this document.
In order to send the multicast stream via a P2MP or MP2MP LSP using Multicast groups that operate in PIM Dense-Mode are outside the scope
in-band signaling the source and the group will be encoded into an of this document.
mLDP opaque TLV encoding [I-D.ietf-mpls-ldp-p2mp]. The type of
In order to transport the multicast tree via a P2MP or MP2MP LSP
using in-band signaling the source and the group will be encoded into
an mLDP opaque TLV encoding [I-D.ietf-mpls-ldp-p2mp]. The type of
encoding depends on the IP version. The tree type (P2MP or MP2MP) encoding depends on the IP version. The tree type (P2MP or MP2MP)
depends on whether this is a source specific or a bidirectional depends on whether this is a source specific or a bidirectional
multicast stream. The root of the tree is the BGP next-hop that was multicast tree. The root of the tree is the BGP next-hop that was
found during the route lookup on the source or RP. Using this found during the route lookup on the source or RP. Using this
information a mLDP FEC is created and the LSP is build towards the information a mLDP FEC is created and the LSP is build towards the
root of the LSP. root of the LSP.
When an LSR receives a label mapping or withdraw and discovers it is When an LSR receives a label mapping or withdraw and discovers it is
the root of the identified P2MP or MP2MP LSP, then the following the root of the identified P2MP or MP2MP LSP, then the following
procedure will be executed. If the opaque encoding of the FEC procedure is executed. If the opaque encoding of the FEC indicates
indicates this is an Transit LSP (indicated by the opaque type), the this is a Transit LSP (indicated by the opaque type), the opaque TLV
opaque TLV will be decoded and the multicast source and group is is decoded and the multicast source and group is passed to the
passed to the multicast code. If the multicast tree information was multicast code. If the multicast tree information is received via a
received via a label mapping, the multicast code will effectively label mapping, the multicast code will adds the downstream LDP
treat this as a positif indication to create a IP multicast tree neighbor to the olist of the corresponding (S,G) or (*,G) state,
based on the received information. If it was due to a label creating such state if it does not already exist. If it is due to a
withdraw, the multicast code will effectively treat this as having label withdraw, the multicast code will remove the downstream LDP
received a negative indication and it will remove the tree neighbor from the olist of the corresponding (S,G) or (*,G) state.
indentified by the encoded information. From this point on normal From this point on normal PIM processing will occur.
PIM processing will occur.
2.1. Transiting IP multicast source trees 2.1. Transiting Unidirectional IP multicast Shared Trees
Nothing prevents PIM shared trees, used by PIM-SM in the ASM service
model, from being transported across a MPLS core. However, it is not
possible to prune individual sources from the shared tree without the
use of an additional out-of-band signaling protocol, like PIM or BGP
[I-D.rekhter-pim-sm-over-mldp]. For that reason transiting Shared
Trees across a Transit LSP is outside the scope of this draft.
2.2. Transiting IP multicast source trees
IP multicast source trees can either be created via PIM operating in IP multicast source trees can either be created via PIM operating in
SSM mode [RFC4607] or ASM mode [RFC4601] (for example via last hop SSM mode [RFC4607] or ASM mode [RFC4601]. When PIM-SM is used in ASM
behavior or MSDP [RFC3618]) and MUST be transporting across the MPLS mode, the usual means of discovering active sources is to join a
network using a P2MP LSP. A Transit LSP may be setup to forward the sparse mode shared tree. However, this document does not provide any
IP multicast traffic across an MPLS core. If the multicast source is method of transporting a sparse mode shared tree across an MPLS
reachable in a global table the source and group addresses are network. To apply the technique of this document to PIM-SM in ASM
encoded into the a transit TLV. Depending on the IP version it is mode, there must be some other means of discovering the active
either Section 3.1 or Section 3.2. sources. One possible means is the use of MSDP [RFC3618]. Another
possible means is to use BGP Source Active auto-discovery routes, as
documented in [I-D.rekhter-pim-sm-over-mldp]. However, the method of
discovering the active sources is outside the scope of this document,
and as a result this document does not specify everything that is
needed to support the ASM service model using in-band signaling.
2.2. Transiting IP multicast bidirectional trees The source and group addresses are encoded into the a transit TLV as
specified in Section 3.1 and Section 3.2.
2.3. Transiting IP multicast bidirectional trees
Bidirectional IP multicast trees [RFC5015] MUST be transported across Bidirectional IP multicast trees [RFC5015] MUST be transported across
a MPLS network using MP2MP LSPs. A bidirectional tree does not have a MPLS network using MP2MP LSPs. A bidirectional tree does not have
a specific source address; only the group address and subnet mask are a specific source address; the group address, subnet mask and RP are
relevant for multicast forwarding. The RP for the group already relevant for multicast forwarding. This document does not provide
known by IP multicast is used to select the ingress PE and root of procedures to discover RP to group mappings dynamically across an
the LSP. The group address is encoded in either Section 3.3 or MPLS network and assumes the RP is statically defined. Support of
Section 3.4, depending on the IP version. The subnet mask associated dynamic RP mappings in combination with in-band signaling is outside
with the bidirectional group is encoded in the Transit TLV. There the scope of his document.
are two types of bidirection states in IP multicast, the group
specific state and the RPA state. The first type is typlically
created due to receiving a PIM join and has a subnet mask of 32 for
IPv4 and 128 for IPv6, the latter is typically created via the RP
mapping protocol and has a variable subnet mask. The RPA state is
used to build a tree to the RP and used for sender only branches.
Please see [RFC5015] for more details.
2.3. Transiting IP multicast shared Trees The RP for the group is used to select the ingress PE and root of the
LSP. The group address is encoded according to the rules of
Section 3.3 or Section 3.4, depending on the IP version. The subnet
mask associated with the bidirectional group is encoded in the
Transit TLV. There are two types of bidirectional states in IP
multicast, the group specific state and the RPA state. The first
type is typically created due to receiving a PIM join and has a
subnet mask of 32 for IPv4 and 128 for IPv6. The latter is typically
created via the static RP mapping and has a variable subnet mask.
The RPA state is used to build a tree to the RP and used for sender
only branches. Each state (group specific and RPA state) will result
in a separate MP2MP LSP. The merging of the two MP2MP LSPs will be
done by PIM on the root LSR. No speccial procedures are nessesary
for PIM to merge the two LSPs, each LSP is effectively treated as a
PIM enabled interface. Please see [RFC5015] for more details.
Nothing prevents PIM shared trees from being transported across a In order transport the packets of sender only branch to the root of
MPLS core. However, it is not possible to prune of individual the LSP a MP2MP is created. This will cause the sender only branches
sources from the shared tree without the use of an additional out-of- to receive each others packets. These packets will be dropped and
band signaling protocol, like PIM. For that reason transiting Shared not forwarded, if that affect is undesireable some other means of
Trees across a Transit LSP is outside the scope of this draft. transport has to be established to forward packets to the root of the
tree, like a Multi-Point to Point LSP for example. A technique to
unicast packets to the root of a P2MP or MP2MP LSP is documented in
[I-D.rosen-l3vpn-mvpn-mspmsi] section 3.2.2.1 and
[I-D.ietf-mpls-ldp-p2mp] section 3.
3. LSP opaque encodings 3. LSP opaque encodings
This section documents the different transit opaque encodings. This section documents the different transit opaque encodings.
3.1. Transit IPv4 Source TLV 3.1. Transit IPv4 Source TLV
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 36 skipping to change at page 12, line 16
8.1. Normative References 8.1. Normative References
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-mpls-ldp-p2mp] [I-D.ietf-mpls-ldp-p2mp]
Minei, I., "Label Distribution Protocol Extensions for Minei, I., Kompella, K., Wijnands, I., and B. Thomas,
Point-to-Multipoint and Multipoint-to-Multipoint Label "Label Distribution Protocol Extensions for Point-to-
Switched Paths", draft-ietf-mpls-ldp-p2mp-05 (work in Multipoint and Multipoint-to-Multipoint Label Switched
progress), June 2008. Paths", draft-ietf-mpls-ldp-p2mp-08 (work in progress),
October 2009.
8.2. Informative References 8.2. Informative References
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006. IP", RFC 4607, August 2006.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR- "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007. PIM)", RFC 5015, October 2007.
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
Protocol (MSDP)", RFC 3618, October 2003. Protocol (MSDP)", RFC 3618, October 2003.
[I-D.ietf-l3vpn-2547bis-mcast] [I-D.ietf-l3vpn-2547bis-mcast]
Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y.,
Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in
MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-07 (work MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work
in progress), July 2008. in progress), January 2010.
[I-D.rekhter-pim-sm-over-mldp]
Rekhter, Y. and R. Aggarwal, "Carrying PIM-SM in ASM mode
Trees over P2MP mLDP LSPs",
draft-rekhter-pim-sm-over-mldp-00 (work in progress),
November 2009.
[I-D.rosen-l3vpn-mvpn-mspmsi]
Boers, A., Cai, Y., Napierala, M., Rosen, E., and I.
Wijnands, "MVPN: Optimized use of PIM via MS-PMSIs",
draft-rosen-l3vpn-mvpn-mspmsi-06 (work in progress),
February 2010.
Authors' Addresses Authors' Addresses
IJsbrand Wijnands IJsbrand Wijnands
Cisco Systems, Inc. Cisco Systems, Inc.
De kleetlaan 6a De kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
Email: ice@cisco.com Email: ice@cisco.com
 End of changes. 25 change blocks. 
113 lines changed or deleted 166 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/