Network Working Group R. Aggarwal
Internet Draft Juniper Networks
Expiration Date: September 2007
Y. Kamite
NTT Communications
L. Fang
Cisco Systems, Inc
March 2007
Multicast in VPLS
draft-ietf-l2vpn-vpls-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.
Abstract
This document describes a solution for overcoming a subset of the
limitations of existing VPLS multicast solutions. It describes
procedures for VPLS multicast that utilize multicast trees in the
sevice provider (SP) network. One such multicast tree can be shared
between multiple VPLS instances. Procedures by which a single
multicast tree in the backbone can be used to carry traffic belonging
Raggarwa, Kamite & Fang [Page 1]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
only to a specified set of one or more IP multicast streams from one
or more VPLSs are also described.
Raggarwa, Kamite & Fang [Page 2]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
Table of Contents
1 Specification of requirements ......................... 4
2 Contributors .......................................... 4
3 Terminology ........................................... 4
4 Introduction .......................................... 5
5 Existing Limitations of VPLS Multicast ................ 5
6 Overview .............................................. 6
6.1 Inclusive and Selective Multicast Trees ............... 6
6.2 BGP-Based VPLS Membership Auto-Discovery .............. 7
6.3 IP Multicast Group Membership Discovery ............... 7
6.4 Advertising P-Tree to VPLS / C-Multicast Binding ...... 7
6.5 Aggregation ........................................... 8
6.6 Inter-AS VPLS Multicast ............................... 8
7 VPLS Multicast/Broadcast/Unknown Unicast Data Packet Treatment 9
8 Intra-AS Inclusive Multicast Tree Auto-Discovery/Binding ..10
8.1 Originating (intra-AS) auto-discovery routes .......... 10
8.2 Receiving (intra-AS) auto-discovery routes ............ 11
9 Demultiplexing Multicast Tree Traffic ................. 12
9.1 One Multicast Tree - One VPLS Mapping ................. 13
9.1.1 One Multicast Tree - Many VPLS Mapping ................ 13
10 Establishing Multicast Trees .......................... 14
10.1 RSVP-TE P2MP LSPs ..................................... 14
10.1.1 P2MP TE LSP - VPLS Mapping ............................ 14
10.1.2 Demultiplexing C-Multicast Data Packets ............... 14
10.2 Receiver Initiated MPLS Trees ......................... 15
10.2.1 P2MP LSP - VPLS Mapping ............................... 15
10.2.2 Demultiplexing C-Multicast Data Packets ............... 16
10.3 Encapsulation of the Aggregate Inclusive and Selective Tree 16
11 Inter-AS Inclusive Multicast Tree Auto-Discovery/Binding ..16
11.1 VSIs on the ASBRs ..................................... 16
11.1.1 VPLS Inter-AS Auto-Discovery Binding .................. 16
11.2 Segmented Inter-AS Trees .............................. 17
11.3 Segmented Inter-AS Trees VPLS Inter-AS Auto-Discovery/Binding 17
11.3.1 Propagating VPLS BGP Auto-Discovery routes to other ASes - Overview 18
11.3.1.1 Propagating Intra-AS VPLS Auto-Discovery routes in EBGP ...19
11.3.1.2 Auto-Discovery Route received via EBGP ................ 20
11.3.1.3 Leaf Auto-Discovery Route received via EBGP ........... 21
11.3.1.4 Inter-AS Auto-Discovery Route received via IBGP ....... 22
12 Selective Tree Instantiation .......................... 23
12.1 Selective Tree Leaf Discovery ......................... 23
12.2 Selective Tree - C-Multicast Stream Binding Advertisement .23
12.3 Switching to Aggregate Selective Trees ................ 24
Raggarwa, Kamite & Fang [Page 3]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
13 BGP Extensions ........................................ 24
13.1 Inclusive Tree/Selective Tree Identifier .............. 25
14 Aggregation Methodology ............................... 26
15 Data Forwarding ....................................... 27
15.1 MPLS Tree Encapsulation ............................... 27
16 Security Considerations ............................... 28
17 IANA Considerations ................................... 28
18 Acknowledgments ....................................... 28
19 Normative References .................................. 28
20 Informative References ................................ 29
21 Author Information .................................... 29
22 Intellectual Property Statement ....................... 30
23 Full Copyright Statement .............................. 30
1. Specification of requirements
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 [RFC2119].
2. Contributors
Rahul Aggarwal
Yakov Rekhter
Juniper Networks
Yuji Kamite
NTT Communications
Luyuan Fang
AT&T
Chaitanya Kodeboniya
3. Terminology
This document uses terminology described in [RFC4761] and [RFC4762].
Raggarwa, Kamite & Fang [Page 4]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
4. Introduction
[RFC4761] and [RFC4762] describe a solution for VPLS multicast that
relies on ingress replication. This solution has certain limitations
for certain VPLS multicast traffic profiles.
This document describes procedures for overcoming the limitations of
existing VPLS multicast solutions. It describes procedures for VPLS
multicast that utilize multicast trees in the sevice provider (SP)
network. The procedures described in this document are applicable to
both [RFC4761] and [RFC4762].
It provides mechanisms that allow a single multicast distribution
tree in the backbone to carry all the multicast traffic from a
specified set of one or more VPLSs. Such a tree is referred to as an
"Inclusive Tree" and more specifically as an "Aggregate Inclusive
Tree" when the tree is used to carry multicast traffic from more than
VPLS.
This document also provides procedures by which a single multicast
distribution tree in the backbone can be used to carry traffic
belonging only to a specified set of one or more IP multicast
streams, from one or more VPLSs. Such a tree is referred to as a
"Selective Tree" and more specifically as an "Aggregate Selective
Tree" when the IP multicast streams belong to different VPLSs. So
traffic from most multicast streams could be carried by an Inclusive
Tree, while traffic from, e.g., high bandwidth streams could be
carried in one of the "Selective Trees".
5. Existing Limitations of VPLS Multicast
One of the limitations of existing VPLS multicast solutions described
in [RFC4761] and [RFC4762] is that they rely on ingress replication.
Thus the ingress PE replicates the multicast packet for each egress
PE and sends it to the egress PE using a unicast tunnel.
This is a reasonable model when the bandwidth of the multicast
traffic is low or/and the number of replications performed on an
average on each outgoing interface for a particular customer VPLS
multicast packet is small. If this is not the case it is desirable to
utilize multicast trees in the SP network to transmit VPLS multicast
packets [MCAST-VPLS-REQ]. Note that unicast packets that are flooded
to each of the egress PEs, before the ingress PE performs learning
for those unicast packets, MAY still use ingress replication.
Raggarwa, Kamite & Fang [Page 5]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
6. Overview
This document describes procedures for using multicast trees in the
SP network to transport VPLS multicast data packets. RSVP-TE P2MP
LSPs described in [RSVP-P2MP] are an example of such multicast trees.
The use of multicast trees in the SP network can be beneficial when
the bandwidth of the multicast traffic is high or when it is
desirable to optimize the number of copies of a multicast packet
transmitted by the ingress. This comes at a cost of state in the SP
network to build multicast trees and overhead to maintain this state.
This document describes procedures for using multicast trees for VPLS
multicast when the provider tunneling technology is either P2MP RSVP-
PE or mLDP [MLDP]. The protocol architecture described herein is
considered to be flexible to support other P-tunneling technologies
as well.
This document uses the prefix 'C' to refer to the customer control or
data packets and 'P' to refer to the provider control or data
packets. An IP multicast source, group tuple is abbreviated to (S,
G).
6.1. Inclusive and Selective Multicast Trees
Multicast trees used for VPLS can be of two types:
1. Inclusive Trees. A single multicast distribution tree in the
SP network is used to carry all the multicast traffic from a
specified set of one or more VPLSs. A particular multicast
distribution tree can be set up to carry the traffic of a single
VPLS, or to carry the traffic of multiple VPLSs. The ability to carry
the traffic of more than one VPLS on the same tree is termed
'Aggregation'. The tree will include every PE that is a member of any
of the VPLSs that are using the tree. This implies that a PE may
receive multicast traffic for a multicast stream even if it doesn't
have any receivers on the path of that stream.
2. Selective Trees. A Selective Tree is used by a PE to send IP
multicast traffic for one or more multicast streams, that belong to
the same or different VPLSs, to a subset of the PEs that belong to
those VPLSs. Each of the PEs in the subset should be on the path to a
receiver of one or more multicast streams that are mapped onto the
tree. The ability to use the same tree for multicast streams that
belong to different VPLSs is termed have the ability to create
separate SP multicast trees for high bandwidth multicast groups. This
allows traffic for these multicast groups to reach only those PE
routers that have receivers in these groups. This avoids flooding
other PE routers in the VPLS.
Raggarwa, Kamite & Fang [Page 6]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
A SP can use both Inclusive Trees and Selective Trees or either of
them for a given VPLS on a PE, based on local configuration.
Inclusive Trees can be used for both IP and non-IP data multicast
traffic, while Selective Trees can be used only for IP multicast data
traffic.
A variety of transport technologies may be used in the backbone. For
inclusive trees, these transport technologies include point-to-
multipoint LSPs created by RSVP-TE or mLDP. For selective trees, only
unicast PE-PE tunnels (using MPLS or IP/GRE encapsulation) and
unidirectional single-source trees are supported, and the supported
tree signaling protocols are RSVP-TE, and mLDP.
This document also describes the data plane encapsulations for
supporting the various SP multicast transport options.
6.2. BGP-Based VPLS Membership Auto-Discovery
In order to establish Inclusive multicast trees for one or more VPLSs
the root of the tree must be able to discover the other PEs that have
membership in one or more of these VPLSs. This document uses the BGP-
based procedures described in [RFC4761] and [L2VPN-SIG] for
discovering the VPLS membership of all PEs.
6.3. IP Multicast Group Membership Discovery
The setup of a Selective P-tree for one or more IP multicast (S, G)s
requires the ingress PE to learn the PEs that have receivers in one
or more of these (S, G)s. For discovering the IP multicast group
membership, procedures described in [VPLS-CTRL] should be used.
Procedures in [VPLS-CTRL] can also be used with ingress replication
to send traffic for an IP multicast stream to only those PEs that are
on the path to receivers for that stream.
6.4. Advertising P-Tree to VPLS / C-Multicast Binding
This document also describes procedures based on BGP VPLS Auto-
Discovery that are used by the root of an Aggregate Tree to advertise
the Inclusive or Selective tree binding and the de-multiplexing
information to the leaves of the tree. A new BGP attribute called the
P-Tunnel Attribute is introduced for this purpose.
Once a PE decides to bind a set of VPLSes or customer multicast
groups to an Inclusive Tree or a Selective Tree, it needs to announce
this binding to other PEs in the network. This procedure is referred
Raggarwa, Kamite & Fang [Page 7]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
to as Inclusive Tree or Selective Tree binding distribution and is
performed using BGP. For an Inclusive Tree this discovery implies
announcing the binding of all VPLSs bound to the Inclusive Tree. The
inner label assigned by the ingress PE for each VPLS MUST be
included, if more than one VPLS is bound to the same tree. The
Inclusive Tree Identifier MUST be included. For a Selective Tree this
discovery implies announcing all the specific <C-Source, C-Group>
entries bound to this tree along with the Selective Tree Identifier.
The inner label assigned for each <C-Source, C-Group> MUST be
included if <C-Source, C-Group>s from different VPLSes are bound to
the same tree. The Selective Tree Identifier MUST be included.
6.5. Aggregation
As described above the ability to carry the traffic of more than one
VPLS on the same tree is termed 'Aggregation'. This enables the SP to
place a bound on the amount of multicast tree forwarding and control
plane state which the P routers must have. If each such tree supports
a set of VPLSs, the state maintained by the P routers is proportional
to the product of average number of VPLSes aggregated onto a tree and
the average number of PEs per VPLS. Thus the state does not grow
linearly with the number of VPLSes.
Aggregation requires a mechanism for the egresses of the tree to
demultiplex the multicast traffic received over the tree. This
document describes how upstream label allocation [MPLS-UPSTREAM] by
the root of the tree can be used to perform this demultiplexing. .
6.6. Inter-AS VPLS Multicast
This document specifies a model where Inter-AS VPLS service can be
offered without requiring a single P-multicast tree to span multiple
ASes. There are two variants of this model.
In the first variant, the ASBRs perform a MAC lookup, in addition to
any MPLS lookups, to determine the forwarding decision on a VPLS
packet. In this variant the multicast trees are confined to an AS.
Hence each AS may use a different P-tunneling technology. An ASBR on
receiving a VPLS packet from another ASBR is required to perform a
MAC lookup to determine how to forward the packet. Thus an ASBR is
required to keep a VSI for the VPLS.
In the second variant, an inter-AS multicast tree, rooted at a
particular PE for a particular VPLS instance, consists of a number of
"segments", one per AS, which are stitched together at Autonomous
System Border Routers (ASBRs). These are known as "segmented inter-AS
Raggarwa, Kamite & Fang [Page 8]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
trees". Each segment of a segmented inter-AS tree may use a
different multicast transport technology. In this variant, an ASBR is
not required to keep a a VSI for the VPLS and is not required to
perform a MAC lookup in order to forward the VPLS packet.
7. VPLS Multicast/Broadcast/Unknown Unicast Data Packet Treatment
If the destination MAC address of a VPLS packet received by a PE from
a VPLS site is a multicast adddress, a multicast tree SHOULD be used
to transport the packet, if possible. If the packet is an IP
multicast packet and a Selective tree exists for that multicast
stream, the Selective tree SHOULD be used. Else if an Inclusive tree
exists for the VPLS, it SHOULD be used.
If the destination MAC address of a VPLS packet is a broadcast
address, it is flooded. If Inclusive tree is already established, PE
SHOULD flood over it. If Inclusive Tree cannot be used for some
reason, PE MUST flood over multiple PWs, based on [RFC4761] or
[RFC4762].
If the destination MAC address of a packet is a unicast address and
it has not been learned, the packet MUST be sent to all PEs in the
VPLS. Inclusive multicast trees SHOULD be used for sending unknown
unicast MAC packets to all PEs. When this is the case the receiving
PEs MUST support the ability to perform MAC address learning for
packets received on a multicast tree. In order to perform such
learning, the receiver PE MUST be able to determine the sender PE
when a VPLS packet is received on a multicast tree. When a receiver
PE receives a VPLS packet with a source MAC address, that has not yet
been learned, on a multicast tree, the receiver PE determines the PW
to the sender PE. The receiver PE then creates forwarding state in
the VPLS instance with a destination MAC address being the same as
the source MAC address being learned, and the PW being the PW to the
sender PE.
It should be noted that when a sender PE that is sending packets
destined to an unknown unicast MAC address over a multicast tree
learns the PW to use for forwarding packets destined to this unicast
MAC address, it might immediately switch to transport such packets
over this particular PW. Since the packets were initially being
forwarded using a multicast tree, this could lead to packet
reordering. This contraint should be taken into consideration if
unknown unicast frames are forwarded using a Inclusive Tree, instead
of multiple PWs based on [RFC4761] or [RFC4762].
An implementation MUST support the ability to transport unknown
unicast traffic over Inclusive multicast trees. Further an
Raggarwa, Kamite & Fang [Page 9]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
implementation MUST support the ability to perform MAC address
learning for packets received on a multicast tree.
8. Intra-AS Inclusive Multicast Tree Auto-Discovery/Binding
This section specifies procedures for the intra-AS auto-discovery
(AD) of VPLS membership and the distribution of information used to
instantiate P-Multicast Tunnels.
VPLS auto-discovery/binding consists of two components: intra-AS and
inter-AS. The former provides VPLS auto-discovery/binding within a
single AS. The latter provides VPLS auto-discovery/binding across
multiple ASes. Inter-AS auto-discovery/binding is described in
section 11.
VPLS auto-discovery using BGP as described in [RFC4761, L2VPN-SIG]
enables a PE to learn the VPLS membership of other PEs. A PE that
belongs to a particular VPLS announces a BGP Network Layer
Reachability Information (NLRI) that identifies the Virtual Switch
Instance (VSI). This NLRI is constructed from the <Route-
Distinguisher (RD), VPLS Edge Device Identifier (VE-ID)> tuple. The
NLRI defined in [RFC4761] comprises the <RD, VE-ID> tuple and label
blocks for PW signaling. The VE-ID in this case is a two octet
number. While the NLRI defined in [L2VPN-SIG] comprises only the <RD,
VE-ID> where the VE-ID is a four octet number.
The procedures for constructing Inclusive intra-AS and inter-AS trees
as specified in this document require the BGP Auto-Discovery NLRI to
carry only the <RD, VE-ID>. Hence these procedures can be used for
both BGP-VPLS and LDP-VPLS with BGP Auto-Discovery.
8.1. Originating (intra-AS) auto-discovery routes
To participate in the VPLS auto-discovery/binding a PE router that
has a given VSI of a given VPLS originates an auto-discovery route
and advertises this route in IBGP. The route is constructed as
described in [RFC4761] and [L2VPN-SIG].
The route carries a single L2VPN NLRI with the RD set to the RD of
the VSI, and the VE-ID set to the VE-ID of the VSI.
If a P-Multicast tree is used to instantiate the provider tunnel for
VPLS multicast on the PE, and either (a) this tree exists at the time
of discovery, or (b) the PE doesn't need to know the leaves of the
tree before hand in order to advertise the P-Multicast tree
identifier, then the advertising PE SHOULD advertise the type and the
Raggarwa, Kamite & Fang [Page 10]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
identity of the P-Multicast tree in a new BGP attribute called the
the P-Tunnel attribute. This attribute is described in section 13.1.
If a P-Multicast tree is used to instantiate the provider tunnel for
VPLS multicast on the PE, and in order to advertise the P-Multicast
tree identifier the advertising PE needs to know the leaves of the
tree beforehand, then the PE obtains this information from the intra-
AS auto-discovery routes received from other PEs. Once the PE obtains
the information about the leaves (this information is obtained from
the auto-discovery routes received by the PE), the PE then advertises
the binding of the tree to the VPLS using the same route as the one
used for the auto-discovery, with the addition of carrying in the
route the P-Tunnel attribute that contains the type and the identity
of the P-Multicast tree. If at some later point a new PE advertises
participation in the same VPLS, the initial binding P-Tunnel binding
information SHOULD NOT change (though the leaves of the corresponding
P-Multicast tree may change).
A PE that uses a P-Multicast tree to instantiate the provider tunnel
MAY aggregate two or more VPLSs present on the PE onto the same tree.
If the PE already advertises intra-AS auto-discovery routes for these
VPLSs, then aggregation requires the PE to re-advertise these routes.
The re-advertised routes MUST be the same as the original ones,
except for the P-Tunnel attribute. If the PE has not previously
advertised intra-AS auto-discovery routes for these VPLSs, then the
aggregation requires the PE to advertise (new) intra-AS auto-
discovery routes for these VPLSs. The P-Tunnel attribute in the
newly advertised/re-advertised routes MUST carry the identity of the
P-Multicast tree that aggregates the VPLSs, as well as an MPLS
upstream assigned label [MPLS-UPSTREAM]. Each re-advertised route
MUST have a distinct label.
Discovery of PE capabilities in terms of what tunnels types they
support is outside the scope of this document. Within a given AS PEs
participating in a VPLS are expected to advertise tunnel bindings
whose tunnel types are supported by all other PEs that are
participating in this VPLS and are part of the same AS.
8.2. Receiving (intra-AS) auto-discovery routes
When a PE receives a BGP Update message that carries an auto-
discovery route such that (a) the route was originated by some other
PE within the same AS as the local PE, (b) at least one of the Route
Targets of the route matches one of the import Route Targets
configured for a particular VSI on the local PE, (c) the BGP route
selection determines that this is the best route with respect to the
NLRI carried by the route, and (d) the route carries the P-Tunnel
Raggarwa, Kamite & Fang [Page 11]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
attribute, the PE performs the following.
If the route carries the P-Tunnel attribute then:
+ If the Tunnel Type in the P-Tunnel attribute is set to LDP P2MP
LSP, the PE SHOULD join the P-Multicast tree whose identity is
carried in the P-Tunnel Attribute.
+ If the Tunnel Type in the P-Tunnel attribute is set to RSVP-TE
P2MP LSP, the receiving PE has to establish the appropriate state
to properly handle the traffic received over that LSP. The PE
that originated the route MUST establish an RSVP-TE P2MP LSP with
the local PE as a leaf. This LSP MAY have been established before
the local PE receives the route.
+ If the P-Tunnel attribute does not carry a label, then all
packets that are received on the P-Multicast tree, as identified
by the P-Tunnel attribute, are forwarded using the VSI that has
at least one of its import Route Targets that matches one of the
Route Targets of the received auto-discovery route.
+ If the P-Tunnel attribute has the Tunnel Type set to LDP P2MP LSP
or RSVP-TE P2MP LSP, and the attribute also carries an MPLS
label, then the egress PE MUST treat this as an upstream assigned
label, and all packets that are received on the P-Multicast tree,
as identified by the P-Tunnel attribute, with that upstream label
are forwarded using the VSI that has at least one of its import
Route Target that matches one of the Route Targets of the
received auto-discovery route.
Irrespective of whether the route carries the PMSI Tunnel
attribute, if the local PE uses RSVP-TE P2MP LSP for sending
(multicast) traffic from the VRF to the sites attached to other
PEs, then the local PE uses the Originating Router's IP address
information carried in the route to add the PE that originated
the route as a leaf node to the LSP.
9. Demultiplexing Multicast Tree Traffic
Demultiplexing received VPLS traffic requires the receiving PE to
determine the VPLS instance the packet belongs to. The egress PE can
then perform a VPLS lookup to further forward the packet.
Raggarwa, Kamite & Fang [Page 12]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
9.1. One Multicast Tree - One VPLS Mapping
When a multicast tree is mapped to only one VPLS, determining the
tree on which the packet is received is sufficient to determine the
VPLS instance on which the packet is received. The tree is determined
based on the tree encapsulation. If MPLS encapsulation is used, eg:
RSVP-TE P2MP LSPs, the outer MPLS label is used to determine the
tree. Penultimate-hop-popping MUST be disabled on the RSVP-TE P2MP
LSP.
9.1.1. One Multicast Tree - Many VPLS Mapping
As traffic belonging to multiple VPLSs can be carried over the same
tree, there is a need to identify the VPLS the packet belongs to.
This is done by using an inner label that corresponds to the VPLS for
which the packet is intended. The ingress PE uses this label as the
inner label while encapsulating a customer multicast data packet.
Each of the egress PEs must be able to associate this inner label
with the same VPLS and use it to demultimplex the traffic received
over the Aggregate Inclusive Tree or the Aggregate Selective Tree. If
downstream label assignment were used this would require all the
egress PEs in the VPLS to agree on a common label for the VPLS.
This document requires the use of upstream label assignment by the
ingress PE [MPLS-UPSTREAM]. Hence the inner label is assigned by the
ingress PE. Each egress PE maintains a separate label space for every
other PE that is the root of an Aggregate Tree. The egress PEs create
a forwarding entry for the inner VPLS label, assigned by the ingress
PE, in this label space. When the egress PE receives a packet over
an Aggregate Tree, the outer encapsulation [in the case of MPLS P2MP
LSPs, the outer MPLS label] specifies the label space to perform the
inner label lookup. The same label space may be used for all P-
multicast trees rooted at the same ingress PE, or an implementation
may decide to use a separate label space for every P-multicast tree
[MPLS-UPSTREAM].
If the tree uses MPLS encapsulation the outer MPLS label and the
incoming interface provides the label space of the label beneath it.
This assumes that penultimate-hop-popping is disabled. An example of
this is RSVP-TE P2MP LSPs. The outer label and incoming interface
effectively identifies the Tree [MPLS-UPSTREAM, MPLS-MCAST].
The ingress PE informs the egress PEs about the inner label as part
of the tree binding procedures described in section 12.
Raggarwa, Kamite & Fang [Page 13]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
10. Establishing Multicast Trees
This document does not place any fundamental restrictions on the
multicast technology used to setup P-multicast trees. However
specific procedures are specified currently only for RSVP-TE P2MP
LSPs and LDP P2MP LSPs.
A P-multicast tree can be either a source tree or a shared tree. A
source tree is used to carry traffic only for the VPLSs that exist
locally on the root of the tree i.e. for which the root has local
CEs. A shared tree on the other hand can be used to carry traffic
belonging to VPLSs that exist on other PEs as well. The shared tree
root participates in VPLS auto-discovery. Each of the PEs transport
the VPLS traffic to the shared tree root using ingress replication.
The shared root splices the traffic onto the shared tree.
10.1. RSVP-TE P2MP LSPs
This section describes procedures that are specific to the usage of
RSVP-TE P2MP LSPs for instantiating a multicast tree. The RSVP-TE
P2MP LSP can be either a source tree or a shared tree. Procedures in
[RSVP-TE-P2MP] are used to signal the P2MP LSP. The LSP is signaled
after the root of the P2MP LSP discovers the leaves. The egress PEs
are discovered using the procedures described in section 9.
Aggregation as described in this document is supported.
10.1.1. P2MP TE LSP - VPLS Mapping
P2MP TE LSP to VPLS mapping is learned at the egress PEs using BGP
based advertisements of the P2MP TE LSP - VPLS mapping. They require
that the root of the tree include the P2MP TE LSP identifier as the
tunnel identifier in the BGP advertisements. This identifier contains
the following information elements:
- The type of the tunnel is set to RSVP-TE P2MP LSP
- RSVP-TE P2MP LSP's SESSION Object
This Tunnel Identifier is described in section 13.1.
10.1.2. Demultiplexing C-Multicast Data Packets
Demultiplexing the C-multicast data packets at the egress PE requires
that the PE must be able to determine the P2MP TE LSP that the
packets are received on. The egress PE needs to determine the P2MP
LSP to determine the VPLS that the packet belongs to, as described in
section 10. To achieve this the LSP must be signaled with
Raggarwa, Kamite & Fang [Page 14]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
penultimate-hop-popping (PHP) off. This is because the egress PE
needs to rely on the MPLS label, that it advertises to its upstream
neighbor, to determine the P2MP LSP that a C-multicast data packet is
received on.
The egress PE relies on receiving the P-Tunnel Attribute in BGP to
determine the VPLS instance to P2MP TE LSP mapping.
Once the egress PE receives this mapping:
+ If the egress PE already has RSVP-TE state for the P2MP TE LSP,
it MUST begin to assign a MPLS label from the non-reserved label
range, for the P2MP TE LSP and signal this to the previous hop of
the P2MP TE LSP. Further it MUST create forwarding state to
forward packets received on the P2MP LSP.
+ If the egress PE does not have RSVP-TE state for the P2MP TE LSP,
it MUST retain this mapping. Subsequently when the egress PE
receives the RSVP-TE P2MP signaling message, it creates the RSVP-
TE P2MP LSP state. It MUST then assign a MPLS label from the
non-reserved label range, for the P2MP TE LSP, and signal this to
the previous hop of the P2MP TE LSP.
10.2. Receiver Initiated MPLS Trees
Receiver initiated MPLS trees can also be used. An example of such
trees are LDP setup P2MP MPLS Trees [MLDP].
The LDP P2MP LSP can be either a source tree or a shared tree.
Procedures in [MLDP] are used to signal the LSP. The LSP is signaled
once the leaves receive the LDP FEC for the tree from the root. The
egress PEs are discovered using the procedures described in section
9. Aggregation as described in this document is supported.
10.2.1. P2MP LSP - VPLS Mapping
P2MP LSP to VPLS mapping is learned at the egress PEs using BGP based
advertisements of the P2MP LSP - VPLS mapping. They require that the
root of the tree include the P2MP LSP identifier as the tunnel
identifier in the BGP advertisements. This identifier contains the
following information elements:
- The type of the tunnel is set to LDP P2MP LSP
- LDP P2MP FEC which includes an identifier generated by the
root.
Each egress PE "joins" the P2MP MPLS tree by sending LDP label
Raggarwa, Kamite & Fang [Page 15]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
mapping messages for the LDP P2MP FEC, that was learned in the BGP
advertisement, using procedures described in [MLDP].
10.2.2. Demultiplexing C-Multicast Data Packets
This follows the same procedures described above for RSVP-TE P2MP
LSPs.
10.3. Encapsulation of the Aggregate Inclusive and Selective Tree
An Aggregate Inclusive Tree or an Aggregate Selective Tree MUST use a
MPLS encapsulation. The protocol type in the data link header is as
described in [MPLS-MCAST].
11. Inter-AS Inclusive Multicast Tree Auto-Discovery/Binding
This document specifies a solution where Inter-AS VPLS service can be
offered without requiring a single P-multicast tree to span multiple
ASes. This allows individual ASes to potentially use different P-
tunneling technologies. There are two variants of this solution.
11.1. VSIs on the ASBRs
In this variant, the ASBRs perform a MAC lookup, in addition to any
MPLS lookups, to determine the forwarding decision on a VPLS packet.
In this variant the multicast trees are confined to an AS. An ASBR on
receiving a VPLS packet from another ASBR is required to perform a
MAC lookup to determine how to forward the packet. Thus an ASBR is
required to keep a VSI for the VPLS and is configured with its own VE
ID for the VPLS. This is equivalent to inter-AS option A described in
[RFC4364].
11.1.1. VPLS Inter-AS Auto-Discovery Binding
In this variant the BGP AD routes generated by PEs in an AS are not
propagated outside the AS. The only AD routes that are propagated
outside the AS are the ones originated by ASBRs. The ASBR - ASBR
inter-connect may be a MPLS PW or a layer-2 interface that maps to a
VPLS instance at the ASBR. If it is a MPLS PW, this MPLS PW is
signaled using the procedures defined in [RFC4361] or [RFC4362], and
connects the VSIs on the ASBRs
The multicast trees for a VPLS are confined to each AS and the VPLS
Raggarwa, Kamite & Fang [Page 16]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
auto-discovery/binding follows the intra-AS procedures described in
section 8.
11.2. Segmented Inter-AS Trees
In the second variant, an inter-AS multicast tree, rooted at a
particular PE for a particular VPLS instance, consists of a number of
"segments", one per AS, which are stitched together at Autonomous
System Border Routers (ASBRs). These are known as "segmented inter-AS
trees". Each segment of a segmented inter-AS tree may use a
different multicast transport technology. In this variant, an ASBR is
not required to keep a a VSI for the VPLS and is not required to
perform a MAC lookup in order to forward the VPLS packet. This
implies that an ASBR is not required to be configured with a VE ID
for the VPLS.
The construction of segmented Inter-AS trees requires the BGP-VPLS
Auto-Discovery NLRI described in [RFC4361, RFC4362]. A BGP-VPLS AD
route for a <RD, VE ID> tuple advertised outside the AS, to which the
originating PE belongs, will be referred to as an inter-AS auto-
discovery route.
In addition to this segmented inter-AS trees require support for the
P-Tunnel Attribute described in section 13.1. They also require
additional procedures in BGP to signal leaf AD routes between
Autonomous System Border Routers (ASBRs) as explained in subsequent
sections.
11.3. Segmented Inter-AS Trees VPLS Inter-AS Auto-Discovery/Binding
This section specifies the procedures for inter-AS VPLS Auto-
Discovery/binding for segmented inter-AS trees.
An ASBR must be configured to support a particular VPLS as follows:
+ An ASBR MUST be be configured with a set of (import) Route
Targets (RTs) that specifies the set of VPLSes supported by the
ASBR. These Route Targets control acceptance of BGP VPLS auto-
discovery routes by the ASBR.
+ The ASBR MUST be configured with the tunnel types for the intra-
AS segments of the VPLSes supported by the ASBR, as well as
(depending on the tunnel type) the information needed to create
the P-Tunnel attribute for these tunnel types.
Raggarwa, Kamite & Fang [Page 17]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
If an ASBR is configured to support a particular VPLS, the ASBR MUST
participate in the intra-AS VPLS auto-discovery/binding procedures
for that VPLS within the ASBR's own AS, as defined in this document.
Moreover, in addition to the above the ASBR performs procedures
specified in the next section.
11.3.1. Propagating VPLS BGP Auto-Discovery routes to other ASes -
Overview
An auto-discovery route for a given VPLS, originated by an ASBR
within a given AS, is propagated via BGP to other ASes. The precise
rules for distributing and processing the inter-AS auto-discovery
routes are given in subsequent sections.
Suppose that an ASBR A receives and installs an auto-discovery route
for VPLS "X" and VE ID "V" that originated at a particular PE, PE1.
The BGP next hop of that received route becomes A's "upstream
neighbor" on a multicast distribution tree for (X, V) that is rooted
at PE1. When the auto-discovery routes have been distributed to all
the necessary ASes, they define a "reverse path" from any AS that
supports VPLS X and VE ID V back to PE1. For instance, if AS2
supports VPLS X, then there will be a reverse path for VPLS X and VE
ID V from AS2 to AS1. This path is a sequence of ASBRs, the first of
which is in AS2, and the last of which is in AS1. Each ASBR in the
sequence is the BGP next hop of the previous ASBR in the sequence on
the given auto-discovery route.
This reverse path information can be used to construct a
unidirectional multicast distribution tree for VPLS X and VE ID V,
containing all the ASes that support X, and having PE1 at the root.
We call such a tree an "inter-AS tree". Multicast data originating in
VPLS sites for VPLS X connected to PE1 will travel downstream along
the tree which is rooted at PE1.
The path along an inter-AS tree is a sequence of ASBRs; it is still
necessary to specify how the multicast data gets from a given ASBR to
the set of ASBRs which are immediately downstream of the given ASBR
along the tree. This is done by creating "segments": ASBRs in
adjacent ASes will be connected by inter-AS segments, ASBRs in the
same AS will be connected by "intra-AS segments".
For a given inter-AS tree, there MUST be only one ASBR that accepts
traffic into a given AS. Further there MUST be only one ASBR that
sends traffic from a particular AS on the tree to another adjacent
AS.
Raggarwa, Kamite & Fang [Page 18]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
An ASBR initiates creation of an intra-AS segment when the ASBR
receives an auto-discovery route from an EBGP neighbor. Creation of
the segment is completed as a result of distributing via IBGP this
route within the ASBR's own AS.
For a given inter-AS tunnel each of its intra-AS segments could be
constructed by its own independent mechanism. Moreover, by using
upstream assigned labels within a given AS multiple intra-AS segments
of different inter-AS tunnels of either the same or different VPLSs
may share the same P-Multicast tree.
If the P-Multicast tree instantiating a particular segment of an
inter-AS tunnel is created by a multicast control protocol that uses
receiver-initiated joins (e.g, mLDP), and this P-Multicast tree does
not aggregate multiple segments, then all the information needed to
create that segment will be present in the inter-AS auto-discovery
routes received by the ASBR from the neighboring ASBR. But if the P-
Multicast tree instantiating the segment is created by a protocol
that does not use receiver-initiated joins (e.g., RSVP-TE, ingress
unicast replication), or if this P-Multicast tree aggregates multiple
segments (irrespective of the multicast control protocol used to
create the tree), then the ASBR needs to learn the leaves of the
segment. These leaves are learned from AD routes received from other
PEs in the AS, for the same VPLS (i.e. same VE-ID).
The following sections specify procedures for propagation of auto-
discovery routes across ASes in order to construct inter-AS segmented
trees.
11.3.1.1. Propagating Intra-AS VPLS Auto-Discovery routes in EBGP
For a given VPLS configured on an ASBR when the ASBR determines
(using the intra-AS auto-discovery procedures) that one or more PEs
of its own AS has (directly) connected site(s) of the VPLS, the ASBR:
originates an BGP VPLS auto-discovery route and advertises it in EBGP
for each of the BGP VPLS auto-discovery routes received by the ASBR
from the PEs in its own AS. Each of these routes is constructed as
follows:
+ The route carries a single BGP VPLS AD NLRI with the RD and VE ID
being the same as the received NLRI.
+ The Next Hop field of the MP_REACH_NLRI attribute is set to a
routable IP address of the ASBR.
Raggarwa, Kamite & Fang [Page 19]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
+ The route carries the P-Tunnel attribute with the Tunnel Type set
to Ingress Replication; the attribute carries no MPLS labels.
+ The route MUST carry the export Route Target used by the VPLS.
11.3.1.2. Auto-Discovery Route received via EBGP
When an ASBR receives from one of its EBGP neighbors a BGP Update
message that carries an auto-discovery route, if (a) at least one of
the Route Targets carried in the message matches one of the import
Route Targets configured on the ASBR, and (b) the ASBR determines
that the received route is the best route to the destination carried
in the NLRI of the route, the ASBR re-advertises this auto-discovery
route to other PEs and ASBRs within its own AS. The best route
selection procedures MUST ensure that for the same destination, all
ASBRs pick the same route as the best route. This ensures that if
multiple ASBRs receive the same inter-AS AD route from their EBGP
neighbors, only one of these ASBRs propagates this route in IBGP.
When re-advertising an inter-AS auto-discovery route the ASBR MUST
set the Next Hop field of the MP_REACH_NLRI attribute to a routable
IP address of the ASBR.
Depending on the type of a P-Multicast tree used to instantiate the
intra-AS segment of the inter-AS tunnel, the P-Tunnel attribute of
the re-advertised inter-AS auto-discovery route is constructed as
follows:
+ If the ASBR uses ingress replication to instantiate the intra-AS
segment of the inter-AS tunnel, the re-advertised route SHOULD
carry the P-Tunnel attribute with the Tunnel Type set to Ingress
Replication, but no MPLS labels.
+ If the ASBR uses a P-Multicast tree to instantiate the intra-AS
segment of the inter-AS tunnel, the PMSI Tunnel attribute MUST
contain the identity of the tree that is used to instantiate the
segment (note that the ASBR could create the identity of the tree
prior to the actual instantiation of the segment). If in order to
instantiate the segment the ASBR needs to know the leaves of the
tree, then the ASBR obtains this information from the auto-
discovery routes received from other PEs/ASBRs in ASBR's own AS.
+ An ASBR that uses a P-Multicast tree to instantiate the intra-AS
segment of the inter-AS tunnel MAY aggregate two or more MVPNs
present on the ASBR onto the same tree. If the ASBR already
advertises inter-AS auto-discovery routes for these MVPNs, then
aggregation requires the ASBR to re-advertise these routes. The
Raggarwa, Kamite & Fang [Page 20]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
re-advertised routes MUST be the same as the original ones,
except for the PMSI Tunnel attribute. If the ASBR has not
previously advertised inter-AS auto-discovery routes for these
MVPNs, then the aggregation requires the ASBR to advertise (new)
inter-AS auto-discovery routes for these MVPN. The PMSI Tunnel
attribute in the newly advertised/re-advertised routes MUST carry
the identity of the P-Multicast tree that aggregates the MVPNs,
as well as an MPLS upstream assigned label [MPLS-UPSTREAM]. Each
re-advertised route MUST have a distinct label.
In addition the ASBR MUST send to the EBGP neighbor, from whom it
receives the inter-AS auto-discovery route, a BGP Update message that
carries a "leaf auto-discovery route". The exact encoding of this
route will be described in the next revision. This route contains the
following information elements:
+ The route carries a single NLRI with the Route Key field set to
the <RD, VE ID> tuple of the BGP VPLS Auto-Discovery NLRI of the
inter-AS auto-discovery route received from that neighbor. The
NLRI also carries the IP address of the ASBR (this MUST be a
routable IP address).
+ The leaf auto-discovery route MUST include the P-Tunnel attribute
with the Tunnel Type set to Ingress Replication, and the Tunnel
Identifier set to a routable address of the advertising router.
The P-Tunnel attribute MUST carry a downstream assigned MPLS
label that is used to demultiplex the VPLS traffic received over
a unicast tunnel by the advertising router.
+ The Next Hop field of the MP_REACH_NLRI attribute of the route
SHOULD be set to the same IP address as the one carried in the
Originating Router's IP Address field of the route.
+ To constrain the distribution scope of this route the route MUST
carry the NO_ADVERTISE BGP community ([RFC1997]).
+ The Route Targets associated with the VPLS MUST be included in
the route.
11.3.1.3. Leaf Auto-Discovery Route received via EBGP
When an ASBR receives via EBGP a leaf auto-discovery route, the ASBR
accepts the route only if if (a) at least one of the Route Targets
carried in the message matches one of the import Route Targets
configured on the ASBR, and (b) the ASBR determines that the received
route is the best route to the destination carried in the NLRI of the
Raggarwa, Kamite & Fang [Page 21]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
route.
If the ASBR accepts the leaf auto-discovery route, the ASBR finds an
auto-discovery route whose BGP-VPLS AD NLRI has the same value as the
<RD, VE-ID> field of the the leaf auto-discovery route.
The MPLS label carried in the P-Tunnel attribute of the leaf auto-
discovery route is used to stitch a one hop ASBR-ASBR LSP to the tail
of the intra-AS tunnel segment associated with the found auto-
discovery route.
11.3.1.4. Inter-AS Auto-Discovery Route received via IBGP
In the context of this section we use the term "PE/ASBR router" to
denote either a PE or an ASBR router.
Note that a given inter-AS auto-discovery route is advertised within
a given AS by only one ASBR as described above.
When a PE/ASBR router receives from one of its IBGP neighbors a BGP
Update message that carries an inter-AS auto-discovery route, if (a)
at least one of the Route Targets carried in the message matches one
of the import Route Targets configured on the PE/ASBR, and (b) the
PE/ASBR determines that the received route is the best route to the
destination carried in the NLRI of the route, the PE/ASBR performs
the following operations.
If the router is an ASBR then the ASBR propagates the route to its
EBGP neighbors. When propagating the route to the EBGP neighbors the
ASBR MUST set the Next Hop field of the MP_REACH_NLRI attribute to a
routable IP address of the ASBR.
If the received inter-AS auto-discovery route carries the P-Tunnel
attribute with the Tunnel Type set to LDP P2MP LSP, the PE/ASBR
SHOULD join the P-Multicast tree whose identity is carried in the P-
Tunnel Attribute.
If the received inter-AS auto-discovery route carries the P-Tunnel
attribute with the Tunnel Identifier set to RSVP-TE P2MP LSP, then
the ASBR that originated the route MUST establish an RSVP-TE P2MP LSP
with the local PE/ASBRas a leaf. This LSP MAY have been established
before the local PE/ASBR receives the route, or MAY be established
after the local PE receives the route.
If the received inter-AS auto-discovery route carries the P-Tunnel
attribute with the Tunnel Type set to LDP P2MP LSP, or RSVP-TE P2MP
LSP, but the attribute does not carry a label, then the P-Multicast
Raggarwa, Kamite & Fang [Page 22]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
tree, as identified by the P-Tunnel Attribute, is an intra-AS LSP
segment that is part of the inter-AS Tunnel for the <VPLS, VE ID>
advertised by the inter-AS auto-discovery route and rooted at the PE
that originated the auto-discovery route. If the P-Tunnel attribute
carries a (upstream assigned) label, then a combination of this tree
and the label identifies the intra-AS segment. If the received router
is an ASBR, this intra-AS segment may further be stitched to ASBR-
ASBR inter-AS segment of the inter-AS tunnel. If the PE/ASBR has
local receivers in the VPLS, packets received over the intra-AS
segment must be forwarded to the local receivers using the local VSI.
12. Selective Tree Instantiation
This section describes the procedures for instantiating selective
trees.
12.1. Selective Tree Leaf Discovery
Constructing a selective tree for a given (C-S, C-G) requires the
ingress PE to learn the egress PEs that have receivers in the (C-S,
C-G). Procedures for learning this information are described in
[VPLS-CTRL].
12.2. Selective Tree - C-Multicast Stream Binding Advertisement
The root of an Aggregate Selective Tree maps one or more <C-Source,
C-Group> entries to the tree. These entries are advertised in BGP
along with the the Selective Tree identifier to which these entries
are mapped.
The following information is required in BGP to advertise the <C-
Source, C-Group> entries that are mapped to the Selective Tree. The
exact encoding of this information will be specified in the next
revision:
1. The RD configured for the VPLS instance. This is required to
uniquely identify the <C-Source, C-Group> as the addresses could
overlap between different VPLS instances.
2. The inner label allocated by the Selective Tree root for the
<C-Source, C-Group>. The usage of this label is described in section
9.
3. The C-Source address. This address can be a prefix in order to
allow a range of C-Source addresses to be mapped to the Selective
Tree.
4. The C-Group address. This address can be a range in order to
allow a range of C-Group addresses to be mapped to the Selective
Raggarwa, Kamite & Fang [Page 23]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
Tree.
When a PE distributes this information via BGP, it must include the
following:
1. An identifier of the Selective Tree using the P-Tunnel
Attribute.
2. Route Target Extended Communities attribute. This is used as
described in section 8.
12.3. Switching to Aggregate Selective Trees
Selective Trees provide a PE the ability to create separate P-
multicast trees for certain <C-S, C-G> entires. The source PE, that
originates the Selective Tree, and the egress PEs, MUST to switch to
the Selective Tree for the <C-S, C-G> entries that are mapped to it.
Once a source PE decides to setup an Selective Tree, it announces the
mapping of the <C-S, C-G> entries that are mapped on the tree to the
other PEs using BGP. Depending on the P-multicast technology used,
this announcement may be done before or after setting up the
Selective Tree. After the egress PEs receive the announcement they
setup their forwarding path to receive traffic on the Selective Tree
if they have one or more receivers interested in the <C-S, C-G>
entries mapped to the tree. This implies setting up the
demultiplexing forwarding entries based on the inner label as
described earlier. The egress PEs may perform this switch to the
Selective Tree once the advertisement from the ingress PE is received
or wait for a preconfigured timer to do so.
A source PE uses the following approach to decide when to start
transmitting data on the Selective tree. A certain pre-configured
delay after advertising the <C-S, C-G> entries mapped to an Selective
Tree, the source PE begins to send traffic on the Selective Tree. At
this point it stops to send traffic for the <C-S, C-G> entries, that
are mapped on the Selective Tree, on the Inclusive Tree. This traffic
is instead transmitted on the Selective Tree.
13. BGP Extensions
This section describes the encoding of the BGP extensions required by
this document.
Raggarwa, Kamite & Fang [Page 24]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
13.1. Inclusive Tree/Selective Tree Identifier
Inclusive Tree and Selective Tree advertisements carry the Tree
identifier.
This document defines and uses a new BGP attribute, called P-Tunnel
Attribute. This is an optional transitive BGP attribute. The format
of this attribute is defined as follows:
+---------------------------------+
| Flags (1 octet) |
+---------------------------------+
| Tunnel Type (1 octets) |
+---------------------------------+
| MPLS Label (3 octets) |
+---------------------------------+
| Tunnel Identifier (variable) |
+---------------------------------+
The Flags field has the following format:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| reserved |L|
+-+-+-+-+-+-+-+-+
This document defines the following flags:
+ Leaf Information Required (L)
The Tunnel Type identifies the type of the tunneling technology used
to establish the P-tunnel. The type determines the syntax and
semantics of the Tunnel Identifier field. This document defines the
following Tunnel Types:
+ 1 - RSVP-TE P2MP LSP
+ 2 - LDP P2MP LSP
+ 6 - Ingress Replication
If the MPLS Label field is non-zero, then it contains an MPLS
label encoded as 3 octets, where the high-order 20 bits contain
the label value. Absence of MPLS Label is indicated by setting
the MPLS Label field to zero.
When the type is set to RSVP-TE P2MP LSP, the Tunnel Identifier
contains the RSVP-TE P2MP LSP's SESSION Object.
Raggarwa, Kamite & Fang [Page 25]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
When the type is set to LDP P2MP LSP, the Tunnel Identifier is
<P-Root Node Address, Variable length opaque identifier>.
When the type is set to Ingress Replication the Tunnel Identifier
carries the unicast tunnel endpoint.
14. Aggregation Methodology
In general the herustics used to decide which VPLS instances or <C-S,
C-G> entries to aggregate is implementation dependent. It is also
conceivable that offline tools can be used for this purpose. This
section discusses some tradeoffs with respect to aggregation.
The "congruency" of aggregation is defined by the amount of overlap
in the leaves of the client trees that are aggregated on a SP tree.
For Aggregate Inclusive Trees the congruency depends on the overlap
in the membership of the VPLSs that are aggregated on the Aggregate
Inclusive Tree. If there is complete overlap aggregation is perfectly
congruent. As the overlap between the VPLSs that are aggregated
reduces, the congruency reduces.
If aggregation is done such that it is not perfectly congruent a PE
may receive traffic for VPLSs to which it doesn't belong. As the
amount of multicast traffic in these unwanted VPLSs increases
aggregation becomes less optimal with respect to delivered traffic.
Hence there is a tradeoff between reducing state and delivering
unwanted traffic.
An implementation should provide knobs to control the congruency of
aggregation. This will allow a SP to deploy aggregation depending on
the VPLS membership and traffic profiles in its network. If
different PEs or shared roots' are setting up Aggregate Inclusive
Trees this will also allow a SP to engineer the maximum amount of
unwanted VPLSs that a particular PE may receive traffic for.
The state/bandwidth optimality trade-off can be further improved by
having a versatile many-to-many association between client trees and
provider trees. Thus a VPLS can be mapped to multiple Aggregate
Trees. The mechanisms for achieving this are for further study. Also
it may be possible to use both ingress replication and an Aggregate
Tree for a particular VPLS. Mechanisms for achieving this are also
for further study.
Raggarwa, Kamite & Fang [Page 26]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
15. Data Forwarding
15.1. MPLS Tree Encapsulation
The following diagram shows the progression of the VPLS IP multicast
packet as it enters and leaves the SP network when MPLS trees are
being used for multiple VPLS instances. RSVP-TE P2MP LSPs are
examples of such trees.
Packets received Packets in transit Packets forwarded
at ingress PE in the service by egress PEs
provider network
+---------------+
|MPLS Tree Label|
+---------------+
| VPLS Label |
++=============++ ++=============++ ++=============++
||C-Ether Hdr || || C-Ether Hdr || || C-Ether Hdr ||
++=============++ >>>>> ++=============++ >>>>> ++=============++
|| C-IP Header || || C-IP Header || || C-IP Header ||
++=============++ >>>>> ++=============++ >>>>> ++=============++
|| C-Payload || || C-Payload || || C-Payload ||
++=============++ ++=============++ ++=============++
The receiver PE does a lookup on the outer MPLS tree label and
determines the MPLS forwarding table in which to lookup the inner
MPLS label. This table is specific to the tree label space. The inner
label is unique within the context of the root of the tree (as it is
assigned by the root of the tree, without any coordination with any
other nodes). Thus it is not unique across multiple roots. So, to
unambiguously identify a particular VPLS one has to know the label,
and the context within which that label is unique. The context is
provided by the outer MPLS label [MPLS-UPSTREAM].
The outer MPLS label is stripped. The lookup of the resulting MPLS
label determines the VSI in which the receiver PE needs to do the C-
multicast data packet lookup. It then strips the inner MPLS label and
sends the packet to the VSI for multicast data forwarding.
Raggarwa, Kamite & Fang [Page 27]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
16. Security Considerations
Security considerations discussed in [RFC4761] and [RFC4762] apply to
this document.
17. IANA Considerations
This document defines a new BGP optional transitive attribute, called
P-Tunnel Attribute.
18. Acknowledgments
Many thanks to Thomas Morin for his support of this work. We would
also like to thank authors of [BGP-MVPN] as the details of the inter-
AS segmented tree procedures in this document have benefited from
those in [BGP-MVPN].
19. Normative References
[RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels.", Bradner, March 1997
[RFC3107] Y. Rekhter, E. Rosen, "Carrying Label Information in
BGP-4", RFC3107.
[RFC4761] K. Kompella, Y. Rekther, "Virtual Private LAN Service",
draft-ietf-l2vpn-vpls-bgp-02.txt
[RFC4762] M. Lasserre, V. Kompella, "Virtual Private LAN Services
over MPLS", draft-ietf-l2vpn-vpls-ldp-03.txt
[MPLS-UPSTREAM] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream
Label Assignment and Context Specific Label Space", draft-ietf-mpls-
upstream-label-00.txt
[MPLS-MCAST] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, "MPLS
Multicast Encapsulations", draft-ietf-mpls-multicast-encaps-00.txt
[VPLS-MCAST-REQ] Y. kamite, et. al., "Requirements for Multicast
Support in Virtual Private LAN Services", draft-ietf-l2vpn-vpls-
mcast-reqts-00.txt
Raggarwa, Kamite & Fang [Page 28]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
20. Informative References
[VPLS-CTRL] R. Aggarwal, Y. Kamite, L. Fang, "Propagation of VPLS IP
Multicast Group Membership Information", draft-raggarwa-l2vpn-vpls-
mcast-ctrl-00.txt
[L2VPN-SIG] E. Rosen et. al., "Provisioning, Autodiscovery, and
Signaling in L2VPNs", draft-ietf-l2vpn-signaling-08.txt
[MVPN] E. Rosen, R. Aggarwal, "Multicast in 2547 VPNs", draft-ietf-
l3vpn-2547bis-mcast-02.txt"
[MVPN-BGP] R. Aggarwal, E. Rosen, Y. Rekhter, T. Morin, C.
Kodeboniya. "BGP Encodings for Multicast in 2547 VPNs", draft-ietf-
l3vpn-2547bis-mcast-bgp-02.txt
[RSVP-P2MP] R. Aggarwal et. al, "Extensions to RSVP-TE for Point to
Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp-07.txt
[MLDP] I. Minei et. al, "Label Distribution Protocol Extensions for
Point-to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", draft-ietf-mpls-ldp-p2mp-02.txt
[RFC4364] "BGP MPLS VPNs", E. Rosen, Y.Rekhter, February 2006
21. Author Information
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale,
CA 94089 Email: rahul@juniper.net
Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale,
CA 94089 Email: yakov@juniper.net
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
Luyuan Fang AT&T 200 Laurel Avenue, Room C2-3B35 Middletown, NJ 07748
Phone: 732-420-1921 Email: lufang@cisco.com
Chaitanya Kodeboniya
Raggarwa, Kamite & Fang [Page 29]
Internet Draft draft-ietf-l2vpn-vpls-mcast-01.txt March 2007
22. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
23. Full Copyright Statement
Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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.
Raggarwa, Kamite & Fang [Page 30]
