Internet DRAFT - draft-xu-l3vpn-2547bis-mcast
draft-xu-l3vpn-2547bis-mcast
L3VPN Working Group Xiaohu Xu
Internet Draft HUAWEI
Expires: April 2006 October 17, 2005
Multicast in BGP/MPLS VPN
draft-xu-l3vpn-2547bis-mcast-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
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
This Internet-Draft will expire on April 17, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document describes a set of procedures and protocols that allow
IP multicast traffic in Border Gateway Protocol (BGP4)/ Multiprotocol
Label Switching (MPLS) Virtual Private Network (VPN) to travel from
one VPN site to another in MPLS Label Switching Path (LSP) tunnel.
Xu Expires April 17, 2006 [Page 1]
Internet-Draft Multicast in BGP/MPLS VPN 10/17/2005
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
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 . [1].
Table of Contents
1. Introduction..................................................3
2. Implementing multicast in BGP/MPLS VPN........................3
2.1. Discovery of PEs within the same MVPN....................3
2.1.1. BGP-based auto-discovery mechanism..................3
2.1.1.1. Auto-discovery with VPN-IPv4 address family....4
2.1.1.2. Auto-discovery with new address family.........4
2.2. Establishment of pseudo-wires............................4
2.2.1. Establishment of PW via targeted LDP................5
2.2.1.1. Format of VC FEC...............................5
2.2.2. Establishment of PW via BGP.........................6
2.3. Transmission of multicast traffic........................6
2.3.1. PIM-SM instance.....................................6
2.3.2. PIM-DM instance.....................................8
2.4. Compatibility............................................8
2.5. Scalability..............................................8
2.6. QoS......................................................8
2.7. TTL......................................................9
2.8. Extranet.................................................9
2.9. Inter-AS MVPN............................................9
2.10. Carrier's Carrier.......................................9
3. Formal Syntax................................................10
4. Security Considerations......................................10
5. IANA Considerations..........................................10
6. Conclusions..................................................10
7. Acknowledgments..............................................10
8. References...................................................10
8.1. Normative References....................................10
8.2. Informative References..................................11
Author's Addresses..............................................11
Intellectual Property Statement.................................11
Disclaimer of Validity..........................................12
Copyright Statement.............................................12
Xu Expires April 17, 2006 [Page 2]
Internet-Draft Multicast in BGP/MPLS VPN 10/17/2005
1. Introduction
[RFC2547bis] defines a set of procedures to provide an IP unicast
Virtual Private Network (VPN) service in MPLS/IP networks. However,
it does not provide a way to provide multicast service in BGP/MPLS
VPN, also called MVPN.
This document will specify a set of procedures to provide MVPN
service.
2. Implementing multicast in BGP/MPLS VPN
To provide MVPN service, the following three basic procedures are
required:
First, discover all the PEs which are attached to a particular MVPN.
The PE attached to a particular MVPN can also be described as PE
within that MVPN.
Second, Full-meshed pseudo wires (PW) are established between each
pair of the above PEs, and these PWs are bound to a particular MVRF
(Multicast Virtual Routing Forwarding) related to the MVPN.
Lastly, multicast control messages and multicast data traffic can be
transmitted through those PWs.
The above three procedures will be described in detail in the
following section of this document.
2.1. Discovery of PEs within the same MVPN
Like the procedure to discover PEs within the same VSI (Virtual
Switching Instance) defined in VPLS related IETF drafts and RFCs, PEs
within the same MVPN could also be discovered automatically via BGP.
Manually configuring the addresses of the remote PEs within the same
MVPN is also an option. However, this method is not scalable to a
large MVPN with a large number of PEs.
Each PE within a particular MVPN will create a MVRF table to maintain
multicast routing information for that MVPN.
2.1.1. BGP-based auto-discovery mechanism
The BGP Multi-protocol Extensions allow BGP to carry routes from
multiple "address families". We use the following two methods to
implement auto-discovery.
Xu Expires April 17, 2006 [Page 3]
Internet-Draft Multicast in BGP/MPLS VPN 10/17/2005
2.1.1.1. Auto-discovery with VPN-IPv4 address family
A VPN-IPv4 address is a 12-byte quantity, beginning with an 8-byte
"Route Distinguisher (RD)" and ending with a 4-byte IPv4 address.
To realize auto-discovery of MVPN membership via BGP, each PE
attached to a particular MVPN must issue a special BGP update message
containing NLRI for VPN-IPv4 address family. The only difference with
the unicast VPN-IPv4 route update is that the IPv4 address part of
VPN-IPv4 address is specified as ''224.0.0.0'' and the prefix length is
specified as ''4''. This special VPN-IPv4 address prefix belonged to a
particular VRF means multicast is enabled for that VRF.
2.1.1.2. Auto-discovery with new address family
BGP-based auto-discovery can also be done with a new address family
named MVPN (to be assigned by IANA). Each PE attached to a particular
MVPN must issue a BGP update message containing NLRI for this MVPN
address family, as well as specific attributes.
Each such BGP update must contain the following information:
- IPv4 address of the originating PE, which is also the address
used for establishing BGP session.
- An RD of the VPN-related VRF, which is bound to the above
IPv4 address to form a unique VPN-IPv4 address of the PE.
- One or more Route Target attributes. If any other PE has a
VRF associated with one of these Route Targets, it will treat
the advertising PE as a member in the MVPN to which the VRF
belongs. This allows each PE to discover the PEs that belong
to a given MVPN.
Other optional information can also be contained in that update
message according to need.
2.2. Establishment of pseudo-wires
Once discovery is done, each pair of PEs within the MVPN will
establish pseudo-wires to each other, i.e., exchange demultiplexors.
This process is known as signaling of VC label.
In the context of MVPN, the VC label as demultiplexor not only says
to which specific VMPN a packet belongs, but also identifies the
ingress PE. For this reason, there is no need to carry ingress PE's
address in multicast traffic with a special encapsulation such as GRE
Xu Expires April 17, 2006 [Page 4]
Internet-Draft Multicast in BGP/MPLS VPN 10/17/2005
for the purpose of RPF checking and other purposes. That is to say,
each PE will assign a unique label to each one of the other PEs
within the above MVPN, and those unique labels are associated to a
particular MVRF related to the above MVPN.
These PWs could be established via targeted LDP or BGP.
2.2.1. Establishment of PW via targeted LDP
The VC label information is distributed, with a new type of FEC
element named MVRF FEC (to be assigned by IANA), in downstream-
unsolicited mode. Only a single VC FEC element MUST be advertised per
LDP VC label.
2.2.1.1. Format of VC FEC
The VC FEC element is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VC tlv | VC Type |RT info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Target |
| Route Target |
| '' |
| '' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- VC tlv
A new value is to be assigned by IANA for MVRF FEC.
- VC Type
16 bit, and the value 0x0001 represents a MVRF instance.
- RT information length
Xu Expires April 17, 2006 [Page 5]
Internet-Draft Multicast in BGP/MPLS VPN 10/17/2005
8 bit, it specifies the length of the Route Target field.
- Route Target
This variable length field is used to carry the Route Target
attributes of the particular MVRF.
2.2.2. Establishment of PW via BGP
BGP can also be used to establish PW between each pair of the PEs.
The mapping of VC label and PE neighbor per MVPN can be carried in
BGP update containing NLRI for the MVPN address family.
2.3. Transmission of multicast traffic
After the PWs bound to a particular MVRF are established between each
pair of those PEs, multicast control messages and multicast data
traffic can be transmitted through them.
Now let's take PIM-SM and PIM-DM as examples to explain in brief how
multicast control messages and multicast data traffic are transmitted
in MVPN. Note that the following text is not normative for the
specification.
2.3.1. PIM-SM instance
As a (S,G)PIM join message is received by an ingress PE via a VRF
attachment circuit, the PIM instance for that VRF will process this
message. First, it will search the VRF table to find out the best
route to S. If the next hop of that route is a loopback address of
the other PE, also called egress PE, it will send a (S,G)PIM join
message to that egress PE through the PW bound to that VRF between
these two PEs. The (S,G)PIM join message is encapsulated in a MPLS
frame with two layers of label, and the inner label is the VC label
which is assigned to the ingress PE by the egress PE and is
associated to a particular MVRF related to the above MVPN, and the
outer label is the label of the LSP tunnel from the ingress PE to the
egress PE.
Meanwhile, the ingress PE will create a (S,G) routing entry in the
above MVRF, and the outgoing interface is that VRF interface
connected to the CE, and the incoming interface is the PW virtual
interface bound to the above MVRF between those two PEs. This virtual
interface can be expressed as Li, which is the VC label assigned to
the egress PE by the ingress PE and is associated to a particular
MVRF on ingress PE related to the above MVPN.
Xu Expires April 17, 2006 [Page 6]
Internet-Draft Multicast in BGP/MPLS VPN 10/17/2005
As the above (S,G) PIM join message is received by the egress PE, it
will determine from which MVPN and from which PE this message is
transmitted, then it will search the determined VRF table to find out
the best route to S and send a (S,G) PIM join message to the
particular CE on the best path to S.
At the same time, the egress PE will also create a (S,G) routing
entry in the above MVRF, and the incoming interface is the VRF
interface connected to the CE, and the outgoing interface is the
particular PW virtual interface which is destined to a special MVRF
on the ingress PE. This virtual interface can be expressed as (Li,Lo),
and the Li is the VC label which is assigned to the egress PE by the
ingress PE and is associated to a particular MVRF related to the
above MVPN, and the Lo is the label of the LSP tunnel from the egress
PE to the ingress PE.
PIM prune messages travel in a MVPN in the similar way with PIM join
messages, so detailed procedure will not be described in this
document.
PIM hello messages can also be transmitted periodically through PWs
between each pair of the PEs within the same MVPN in order to find
out PIM neighbors in a particular MVRF associated with that MVPN. Of
course, the hello mechanism between each pair of the PEs within the
same MVPN can also be cancelled so as to reduce the periodical
multicast traffic within the MVPN.
PIM bootstrap messages can also be flooded to all the other PEs
through PWs between each pair of PEs within the same MVPN when they
are received from a CE by an ingress PE. The bootstrap messages
received by egress PE through PW should be checked by RPF mechanism.
Only if the PW through which the bootstrap messages are received is
the one that is destined to the BSR indicated in the bootstrap
messages, will the RPF checking succeed, otherwise, the RPF checking
will fail. As full-meshed PWs are formed between each pair of the PEs
within the same MVPN, the Bootstrap messages received through PW need
not to be flooded to other PEs, this is known as ''horizon-splitting''.
PIM assert mechanism is not needed on those PWs because full-meshed
PWs are formed between each pair of the PEs within the same MVPN.
PIM Candidate-RP-Advertisement messages (C-RP-Advs) are forwarded to
the BSR of that MVPN in unicast mode by candidate RPs periodically,
so there is no difference from the forwarding behavior defined in
[RFC2547bis].
Xu Expires April 17, 2006 [Page 7]
Internet-Draft Multicast in BGP/MPLS VPN 10/17/2005
As soon as the multicast distributing tree is established within the
MVPN, multicast data traffic will be able to travel along the
multicast distributing tree.
The implementing procedure of PIM-SSM is similar to that of PIM-SM,
so the procedures of processing PIM-SSM control messages in MVPN will
not be described in this document.
2.3.2. PIM-DM instance
PIM-DM can also be supported in this MVPN. As PIM-DM is a data-driven
multicast routing protocol, which is different from the control-
driven multicast routing protocol PIM-SM, so the procedure of
implementing PIM-DM in MVPN is described as follows: first, as the
multicast data traffic is received via a VRF attachment circuit, the
traffic will be flooded to all the other PEs within that VRF related
MVPN. Second, the multicast data traffic received by any one of the
egress PEs within the MVPN will be checked by RPF mechanism. Only if
the peer PE of the PW through which the traffic traveled is the next
hop of the best route to the multicast source, the RPF checking will
succeed, otherwise, the RPF checking will be failed. Third, once the
RPF checking succeed, the multicast data traffic will be flooded to
all the attached CEs via VRF attachment circuits, this is known
as ''horizon-splitting''.
2.4. Compatibility
From the above description, it can be seen that multicast in BGP/MPLS
VPN is similar with ordinary multicast behaviors as long as the full-
meshed PWs between each pair of the PEs within the same MVPN are
looked as virtual interfaces with a binding to a particular VRF. That
is to say, any kinds of current multicast routing protocols can be
run within this MVPN.
2.5. Scalability
As there is not special requirement on P routers, the scalability of
this MVPN solution is good. In addition, the multicast traffic in
MVPN could be distributed accurately to the necessary PEs.
2.6. QoS
Diff-Serv can be implemented for multicast traffic in BGP/MPLS VPN
traveling through PW by using the DSCP bits in IP head of the IP-
based tunnel or the EXP bits in MPLS head of the MPLS LSP tunnel. In
addition, if RSVP-TE tunnel is used as the tunnel of PW, the
Xu Expires April 17, 2006 [Page 8]
Internet-Draft Multicast in BGP/MPLS VPN 10/17/2005
multicast traffic can inherits the features including bandwidth
assurance, TE and FRR from RSVP-TE.
2.7. TTL
[RFC3031] defined TTL as a way to suppress loops in MPLS networks.
The value of TTL field in the header of MPLS frame will be reduced as
it travels through LSP tunnel. Generally the TTL value of protocol
packet is set to 1. In order to transmit multicast control messages
with TTL of 1 through PW, the TTL value of routing protocol packet
with TTL of 1 should not be copied to IP header of the IP-based
tunnel or the MPLS header of the MPLS LSP tunnel by the ingress PE.
2.8. Extranet
As Route Target attributes, but not VPN ID, are used in auto-
discovery mechanism of MVPN membership, Extranet can be supported
natively. The PE with a particular VRF belonged to more than one VPN
can establish PWs separately with other PE members within different
MVPNs.
Once Extranet is deployed with MVPN, horizon-splitting function
should be disabled on the PEs with a particular VRF belonged to more
than one VPN.
2.9. Inter-AS MVPN
[RFC2547bis] defines three different options for supporting Inter-AS
VPN. Among of them, option a) supports MVPN in nature by separately
deploying the procedure described above in every AS, and procedure of
implementing MVPN in option b) is still under consideration. Option c)
creates an LSP from a PE in one AS to another PE in another AS. These
PEs can establish PW across AS via multi-hop EBGP or targeted LDP,
and the multicast traffic in that MVPN will be tunneled through the
inter-AS LSP established between PEs as described above.
2.10. Carrier's Carrier
The MVPN solution defined in this document supports the carrier's
carrier model in native because there is no special requirement on P
routers of sub-carrier.
Xu Expires April 17, 2006 [Page 9]
Internet-Draft Multicast in BGP/MPLS VPN 10/17/2005
3. Formal Syntax
4. Security Considerations
The MVPN solution defined in this document inherits all of the
security features of BGP/MPLS VPN.
5. IANA Considerations
A new address family for MVPN in BGP (see section 2.1.1.2) and a new
FEC for MVRF in LDP (see section 2.2.1.1) need to be assigned by IANA.
6. Conclusions
The set of procedures to provide MVPN service specified in this
document are compatible with any current multicast routing protocol,
such as PIM-SM, PIM-SSM and PIM-DM. That is to say, any multicast
routing protocol can run in BGP/MPLS VPN as long as the PWs between
each pair of the PEs within the same MVPN are viewed as virtual
interfaces with a binding to a particular VRF.
7. Acknowledgments
The author would like to acknowledge the following individuals for
their helpful comments and suggestions: Spencer Dawkins, Xudong Liang,
Le Zhang and Yu Yi.
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
Xu Expires April 17, 2006 [Page 10]
Internet-Draft Multicast in BGP/MPLS VPN 10/17/2005
8.2. Informative References
[3] [RFC2547bis] Rosen, Rekhter, et. al. ''draft-ietf-l3vpn-
rfc2547bis-01.txt'', September 2003,
[4] [PIM-SM] Fenner, Handley, Holbrook, Kouvelas, "Protocol
Independent Multicast - Sparse Mode (PIM-SM)", '' draft-ietf-
pim-sm-v2-new-08.txt'',October 2003,
[5] [MVPN-FW] Eric C. Rosen, Rahul Aggarwal,''draft-ietf-l3vpn-
2547bis-mcast-00.txt'', May 2005
[6] [VPLS-BGP] K. Kompella, Y. Rekhter,''draft-ietf-l2vpn-vpls-bgp-
04'', February 2005
[7] [VPLS-LDP] Marc Lasserre, Vach Kompella, ''draft-ietf-l2vpn-
vpls-ldp-05.txt'' September 2004
[8] [BGP-DISC] Lasserre, Kompella, "Using BGP as an Auto-Discovery
Mechanism for Network-based VPNs", draft-ietf-l3vpn-bgpvpn-
auto-02.txt, April 2004.
[9] [RFC3031] E. Rosen, A. Viswanathan, R. Callon, ''Multiprotocol
Label Switching Architecture'', January 2001
Author's Addresses
Xiaohu Xu
HUAWEI
Hua Wei Bld.,No.3 Xinxi Rd.,
Shang-Di Information Industry Base
Hai-Dian District
Beijing P.R.China
Phone: +86 010 82882457
Email: xuxh@huawei.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
Xu Expires April 17, 2006 [Page 11]
Internet-Draft Multicast in BGP/MPLS VPN 10/17/2005
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Xu Expires April 17, 2006 [Page 12]
