Internet DRAFT - draft-ietf-pals-ldp-vpls-broadcast-exten
draft-ietf-pals-ldp-vpls-broadcast-exten
Network Working Group Simon Delord (editor), Telstra
Internet Draft Raymond Key (editor), AusNet Services
Category: Standard Track Frederic Jounay, Orange CH
Expires: December 2015 Yuji Kamite, NTT Communications
Zhihua Liu, China Telecom
Manuel Paul, Deutsche Telekom
Ruediger Kunze, Deutsche Telekom
Mach Chen, Huawei
Lizhong Jin
June 5, 2015
Extension to LDP-VPLS for Ethernet Broadcast and Multicast
draft-ietf-pals-ldp-vpls-broadcast-exten-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 December 5, 2015.
Abstract
This document proposes a simple extension to LDP-VPLS to improve
bandwidth efficiency for Ethernet broadcast/multicast traffic
within a carrier's network. It makes use of unidirectional
point-to-multipoint PseudoWires to minimise payload frame duplication
on physical links.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Delord & Key Expires Dec 2015 [Page 1]
Internet Draft Ext to LDP-VPLS for broadcast multicast June 2015
Table of Contents
1. Introduction.....................................................2
2. Problem Statement & Motivation...................................3
2.1. Requirements for Broadcast/Multicast Support in VPLS...........3
2.2. Motivation.....................................................4
2.3. Scope of the proposed solution.................................5
3. Terminology......................................................5
4. Relevant IETF technologies for the proposed solution.............6
4.1. P2MP LSPs......................................................6
4.2. P2MP PWs.......................................................6
5. Proposed extension to [RFC4762]..................................7
5.1. VPLS Reference Model...........................................7
5.2. Choosing PEs for a specific VPLS to be connected by a P2MP PW..9
5.3. Create and associate the P2MP PW to a specific VPLS instance...9
5.4. Mapping more than one P2MP PW to a specific VPLS Instance
on a specific root PE.........................................10
5.5. Flooding and Forwarding.......................................10
5.6. Address Learning..............................................11
5.7. Loop Free Topology............................................11
5.8. Hierarchical VPLS.............................................11
5.9. P2MP PW Status................................................11
6. Local PE Implementation.........................................12
7. Security Considerations.........................................12
8. IANA Considerations.............................................12
9. Acknowledgments.................................................12
10. References.....................................................13
10.1. Normative References.........................................13
10.2. Informative References.......................................13
Author's Addresses.................................................14
Appendix A. One example for broadcast video delivery...............15
1. Introduction
This document proposes a simple extension to LDP-VPLS [RFC4762] to
improve bandwidth efficiency for Ethernet broadcast/multicast traffic
within a carrier's network. This bandwidth improvement is achieved by
adding to the existing full-mesh of bidirectional point-to-point
PseudoWires (P2P PWs) unidirectional point-to-multipoint PseudoWires
(P2MP PWs) between selected PEs within a VPLS instance. With P2MP
PWs, the ingress PE is not responsible for replicating the payload
frame on each P2P PW towards the egress PE, instead the network
elements along the physical path participate in the replication
process. The replication is done by the underlying point-to-multi-
point label switched path. This proposal allows for a large number
of P2MP PWs to be carried through a single MPLS P2MP tunnel, thus,
it is never necessary to maintain state in the network core for
individual P2MP PWs.
Delord & Key Expires Dec 2015 [Page 2]
Internet Draft Ext to LDP-VPLS for broadcast multicast June 2015
2. Problem Statement & Motivation
2.1. Requirements for Broadcast/Multicast Support in VPLS
[RFC5501] provides an in-depth discussion on broadcast/multicast
related requirements for VPLS. It highlights two specific issues:
- issue A: replication to non-member site.
- issue B: replication of PWs on shared physical path.
2.1.1. Issue A: replication to non-member site
The current standard VPLS is a L2VPN service agnostic to customer's
Layer 3 traffic, hence does not maintain any information about IP
multicast group membership. Although a Layer 3 IP multicast packet
is encapsulated in a Layer 2 Ethernet multicast frame, the current
standard VPLS treats Ethernet multicast frame in exactly the same way
as Ethernet broadcast frame. There is therefore an issue that
multicast traffic is sent to sites with no members. Since the
upstream PE does not maintain downstream membership information, it
simply floods frames to all downstream PEs, and the downstream PEs
forward them to directly connected CEs; however, those CEs might not
be the members of any multicast group.
There are therefore two elements to Issue A:
- the PE to CE section (e.g. the AC), where a CE will receive
unintended traffic.
- the PE to PE section within a VPLS instance, where a PE will
receive multicast traffic even when it has no CE being member of
any multicast group.
To address the PE to CE part, a PE might have to maintain multicast
group information for CEs that are not kept in the existing VPLS
solutions.
To address the PE to PE part and limit the flooding scope across the
backbone, a PE needs to discover multicast group information from
other remote PEs.
Both elements will present scalability concerns about state resources
(memory, CPU, etc.) and their maintenance complexity.
Finally, if Layer-3 information is checked for transport, the
following [RFC4665] requirement "a L2VPN service SHOULD be agnostic
to customer's Layer3 traffic" can no longer be met.
Delord & Key Expires Dec 2015 [Page 3]
Internet Draft Ext to LDP-VPLS for broadcast multicast June 2015
2.1.2. Issue B: replication of PWs on shared physical path
Issue B on the other hand can still be improved without making use of
any Layer-3-related information.
Issue B may still be considered acceptable when:
- Ethernet broadcast/multicast traffic volume is low; and
- The number of replications on each outgoing physical interface for
a VPLS instance is small (e.g. not many PEs per VPLS instance).
However, with more broadcast/multicast applications (e.g. broadcast
TV), Ethernet broadcast/multicast traffic volume may increase to a
significant level. Assuming HDTV requires 10Mbps per channel, a
bundle of 100 channels will require 1Gbps.
Furthermore, as MPLS networks expand from the core towards
aggregation/access, more PEs may participate in a single VPLS
instance. The number of replications on each outgoing physical
interface for a VPLS instance is likely to increase.
2.2. Motivation
Based on the previous section, it may still be desirable for some
carriers to look at improving issue B without having to look at Layer
3 information (Issue A).
One reason for this is that sometimes there is no L3 data to snoop.
Another reason may be that some carriers may not be allowed to look
above the L2 header, for example there may be regulatory issues with
inspecting the customer payload. Also, some carriers may not want to
do L3 snooping as Operations will naturally become more complicated
if the number of managed objects (e.g. multicast groups) increases.
Another important point is that some carriers may want a manual and
granular optimisation process that allows optimizations to certain
services or areas but does not impact the rest of the network. For
example, the bandwidth improvement process may only be required at
specific locations in the network where bandwidth-intensive multicast
broadcast Ethernet flows exist. It would also be beneficial if the
optimisation process were incrementally deployable, so that the
optimisation can still be leveraged even if there are portions of the
network that are not able to support the features required by the
optimisation process. A potential case would be a VPLS instance
composed of both PEs supporting the proposed protocol extension and
PEs not supporting it, the enhancement is then achieved between the
compliant PEs only.
Delord & Key Expires Dec 2015 [Page 4]
Internet Draft Ext to LDP-VPLS for broadcast multicast June 2015
Finally, some carriers may also prefer a deterministic process to an
entirely automated path selection algorithm that is network driven.
[RFC5501] gives several reasons on why this may be the case:
- Accounting for various operator policies where the logical
multicast topology within a carrier's network does not change
dynamically in conjunction with a customer's multicast routing.
- Operations will naturally become more complicated if topology
changes occur more frequently.
- Troubleshooting will tend to be difficult if a solution supports
frequent dynamic membership changes with optimized transport within
the carrier's network.
[RFC7117] is a solution that looks at solving both Issue A and Issue
B. However, [RFC7117] proposes that, even for carriers who currently
use [RFC4762] without auto-discovery mechanisms, BGP be introduced.
This may also present operational challenges and complexities for
some carriers, or this feature may simply not be supported on some of
the network elements deployed.
2.3. Scope of the proposed solution
This draft therefore explores whether there is a way to improve
Layer 2 Ethernet broadcast/multicast bandwidth simply and predictably
with:
- Minimal extension to [RFC4762] and without the need to add BGP
(e.g. no auto-discovery)
- Minimal impact to existing [RFC4762] deployed networks
- Operator driven optimisation (i.e. the operator decides where and
how the bandwidth improvement should occur) to minimise the number
of states and the potential operational complexities associated
with dynamic changes within a carrier's core network.
3. Terminology
This document uses terminology described in [RFC4762] and [RFC7338].
Delord & Key Expires Dec 2015 [Page 5]
Internet Draft Ext to LDP-VPLS for broadcast multicast June 2015
4. Relevant IETF technologies for the proposed solution
The proposed solution relies on [RFC4762] existing mechanisms and
complements them with extensions (P2MP LSPs and P2MP PWs) already
standardised ([RFC4875]) or currently under development by the IETF
([RFC6388] and [P2MP-PW-LDP]).
4.1. P2MP LSPs
Similarly to what is defined in [RFC4762] where P2P PWs are
multiplexed onto P2P LSPs, before the operator can start deploying
P2MP PWs, an appropriate underlying layer made of P2MP LPSs needs to
be configured (section 3.2 of [RFC7338]).
P2MP LSPs are used to minimise packet replication on specific
physical links and to allow P routers in an MPLS domain to be
transparent to services (e.g. a P Router will join the P2MP PSN
tunnel operation but will have no knowledge of the P2MP PWs, same
as [RFC4762]).
The mapping of the P2MP LSP over the physical topology is a
key component of the bandwidth enhancement exercise and the operator
needs to carefully consider where and how these P2MP LSPs should be
deployed (see Appendix A for an example of a possible deployment).
Once configured, it is then possible to aggregate P2MP PWs over a
particular P2MP LSP (similar to [RFC4762]).
4.2. P2MP PWs
P2MP PWs can be configured statically (e.g. by the operator) or via
LDP on top of the P2MP LSPs. This configuration is done on a per PE
per VPLS instance basis.
In a P2MP PW, the operator decides to connect one Root PE to at least
two Leaf PEs (section 3.1 of [RFC7338]).
The Root PE is the headend of the P2MP PW (where a big Ethernet
multicast/broadcast talker is connected - see example in Appendix A).
The Leaf PEs are the endpoints of the P2MP PW (they constitute
the receivers where the broadcast/multicast traffic needs to be
distributed to).
A Root PE may map more than one P2MP PW to a specific VPLS instance.
In this case, the Root PE MUST NOT associate a leaf PE to more than
one P2MP PW for a specific VPLS instance (this is to avoid a Leaf PE
to receive duplicate copies of the same Ethernet frame from different
P2MP PWs).
P2MP PWs are defined in [RFC7338] and one solution using LDP as
the signalling mechanism between PEs is defined in [P2MP-PW-LDP].
Delord & Key Expires Dec 2015 [Page 6]
Internet Draft Ext to LDP-VPLS for broadcast multicast June 2015
5. Proposed extension to [RFC4762]
This section updates [RFC4762] by describing the extra rules to be
applied within a VPLS when unidirectional P2MP PWs are added to the
existing full-mesh of P2P PWs.
5.1. VPLS Reference Model
Figure 1 shows a topological model (not the physical topology)
of a VPLS between four PEs with an arbitrary set of ACs attached to
each VSI.
+---------+ +---------+
| PE1 | | PE2 |
| +---+ | | +---+ |
| | | | | | +-------AC4---
| | V | | | | V | |
| | | | | | | |
----AC1----+--+ | | Ethernet | | +--+----AC5---
| | S +--+-----PW-----+--+ S | |
| | | | | | | |
----AC2----+--+ | | | | | |
| | I | | | | I | |
| | | | Ethernet | | | |
----AC3----+--+ | | PW +-----+--+ | |
| +-+-+ | / | +-+-+ |
| | \ | / | | |
+----+---\+ / +----+----+
| \ / |
Ethernet| \/ |Ethernet
PW| /\ |PW
| / \Ethernet |
+----+---/+ \PW +----+----+
|PE3 | / | \ |PE4 | |
| +-+-+ | \ | +-+-+ |
----AC6----+--+ | | \ | | +--+----AC8----
| | V | | +----+--+ V | |
| | | | | | | |
----AC7----+--+ | | Ethernet | | +--+----AC9----
| | S +--+-----PW-----+--+ S | |
| | | | | | | |
| | | | | | | |
| | I | | | | I | |
| | | | | | | |
| | | | | | | |
| +---+ | | +---+ |
| | | |
+---------+ +---------+
Figure 1: Reference Diagram for VPLS
Delord & Key Expires Dec 2015 [Page 7]
Internet Draft Ext to LDP-VPLS for broadcast multicast June 2015
Figure 2 shows the proposed extensions to VPLS for Ethernet broadcast
and multicast. On top of the topology presented in Figure 2, two
P2MP PWs have been added to the existing set of P2P PWs.
+---------+ +---------+
| PE1 | | PE2 |
| +---+ | | +---+ |
| | | | | | +-------AC4---
| | V | | Ethernet | | V | |
| | | | P2MP | | | |
----AC1----+--+ | | PW1 | | +--+----AC5---
| | S +--+->--+-->----+--+ S | |
| | | | | | | | |
----AC2----+--+ | | | | | | |
| | I | | | +->-+--+ I | |
| | | | | | | | | |
----AC3----+--+ | | | | | | | |
| +---+ | | | | +---+ |
| | | | | |
+---------+ | | +---------+
| |
| |
| |
| |
+---------+ | | +---------+
|PE3 | | | |PE4 |
| +---+ | | | | +---+ |
----AC6----+--+ | | +->-----+--+ +--+----AC8----
| | V | | | | | V | |
| | | | | | | | |
----AC7----+--+ | | | | | +--+----AC9----
| | S +--+->------+->-+--+ S | |
| | | | Ethernet | | | |
| | | | P2MP | | | |
| | I | | PW2 | | I | |
| | | | | | | |
| | | | | | | |
| +---+ | | +---+ |
| | | |
+---------+ +---------+
Figure 2: Proposed Extensions to VPLS for Ethernet broadcast/multicast
P2MP PW1 is composed of PE1 as the root PE and PE2 and PE4 as leaf
PEs.
P2MP PW2 is composed of PE3 as the root PE and PE2 and PE4 as leaf
PEs.
Note that for sake of clarity, Figure 2 does not show the full-mesh
of P2P PWs presented in Figure 1.
Delord & Key Expires Dec 2015 [Page 8]
Internet Draft Ext to LDP-VPLS for broadcast multicast June 2015
Also note that the solution does not require that P2MP PWs be used on
all PEs in the VPLS. For example, PE3 is not leaf of P2MP PW1 and PE1
is not leaf of P2MP PW2 and therefore, there is only a P2P PW between
PE1 and PE3, and a P2P PW between PE2 and PE4.
5.2. Choosing PEs for a specific VPLS to be connected by a P2MP PW
This updates section 4.3 of [RFC4762].
VPLS is a full-mesh of P2P PWs and optionally a number of
unidirectional P2MP PWs. At the difference of P2P PWs, not all PEs in
a VPLS instance need to be connected via P2MP PWs.
For each P2MP PW on this VPLS instance:
- The operator selects one PE as the Root of the P2MP PW.
- The operator also selects two or more PEs belonging to the same
VPLS instance to be Leafs of the P2MP PW
- Because there is already a full-mesh of bidirectional P2P PWs
between all PEs, the P2MP PW is unidirectional only (e.g. from
the Root PE to all the Leaf PEs connected to it).
- The operator also needs to make sure that there is an active P2MP
LSP setup between the Root PE and the Leaf PEs:
- If there is already an active P2MP LSP setup between the Root
PE and the Leaf PEs, then procedures described in 5.3 can be
followed.
- If there is no P2MP LSP between the Root PE and the Leaf PEs
then the operator needs to create first a P2MP LSP in order for
procedures in 5.3 to be followed. Procedures to setup a P2MP LSP
will vary based on the technology used and are described in
[RFC6388] and [RFC4875].
5.3. Create and associate the P2MP PW to a specific VPLS Instance
This updates section 4.3 of [RFC4762].
Once that the endpoints of the P2MP PW have been selected and that
there is an active P2MP LSP between them, the operator can then
create and associate the P2MP PW to a specific VPLS instance.
This activity can be done statically or via LDP [P2MP-PW-LDP].
Because P2MP PWs are used to demultiplex encapsulated Ethernet frames
from multiple VPLS instances that are aggregated over the same P2MP
transport LSP, it is necessary that a Leaf PE can associate
unambiguously a P2MP PW aggregated within a P2MP LSP to both a
specific VPLS instance and a Root PE.
Delord & Key Expires Dec 2015 [Page 9]
Internet Draft Ext to LDP-VPLS for broadcast multicast June 2015
In the static case, the operator is responsible for configuring all
the required information on all PEs belonging to the P2MP PW.
In the LDP case, the P2MP PW is initiated by the Root PE by sending a
P2MP PW LDP Label Mapping Message to each of the Leaf PEs.
This label mapping contains, the VPLS instance the P2MP PW is
associated to, the P2MP LSP used to transport the P2MP PW and the
P2MP PW MPLS Label.
The P2MP PW MPLS Label is upstream assigned and allocated according
to the rules in [RFC5331].
The root PE imposes the upstream-assigned label on the outbound
packets sent over the P2MP-PW and using this label a Leaf PE can
identify the inbound packets arriving over the P2MP PW.
Detailed LDP message formats and P2MP PW setup procedures are
described in [P2MP-PW-LDP].
5.4. Mapping more than one P2MP PW to a specific VPLS Instance on a
specific Root PE
The proposed solution allows for a Root PE to map more than one P2MP
PW to a specific VPLS instance (see example in Appendix A).
However in this case, the Root PE MUST NOT associate a leaf PE to
more than one P2MP PW for a specific VPLS instance (this is to avoid
a Leaf PE to receive duplicate copies of the same Ethernet frame from
different P2MP PWs).
5.5. Flooding and Forwarding
This section updates section 4.1. of [RFC4762].
A root PE MUST NOT flood frames simultaneously over P2MP PW and P2P
PW toward the same leaf PE.
For the flooding of an Ethernet broadcast/multicast frame over PWs to
remote PEs participating in the VPLS:
- If there is P2MP PW towards a remote PE, the P2P PW
associated with this remote PE will not be used. One copy
of the frame will be forwarded on the P2MP PW for all the
remote PEs associated with it.
- If there is no P2MP PW towards a remote PE, the P2P PW
associated with this remote PE is used.
It should be noted that local policy on the Root PE at the operator's
operational request can override any decision to flood and forward
traffic over a P2MP PW for a VPLS instance. In that case, normal
flooding procedures over P2P PWs described in 4.1 of [RFC4762] apply.
Delord & Key Expires Dec 2015 [Page 10]
Internet Draft Ext to LDP-VPLS for broadcast multicast June 2015
5.5.1. Flooding and Forwarding for Ethernet unknown unicast
In traditional Ethernet switched networks unknown unicast frames are
handled the same way as broadcast and multicast Ethernet traffic
(e.g. flooding). Similarly, current VPLS standards also handle
unknown unicast traffic by flooding it across all P2P PWs.
The main purpose of this document is to address Ethernet broadcast
and multicast traffic. For Ethernet unknown unicast frames there are
two possibilities:
(1) forward the unknown unicast traffic on the P2MP PW, same as for
Ethernet broadcast and multicast.
(2) keep the existing mechanism of [RFC4762] and flood over the mesh
of P2P PWs.
A Root PE SHOULD support both the above as configurable options per
VPLS instance. For a particular VPLS instance where frame reordering
is considered unacceptable, option (2) is recommended.
5.6. Address Learning
This section updates section 4.2. of [RFC4762].
A Leaf PE MUST support the ability to perform MAC address learning
for packets received on a P2MP PW.
When a Leaf PE receives an Ethernet frame on a P2MP PW it:
- First determines the VSI associated to the P2MP PW
- Then determines the Root PE of the P2MP PW
- Then determines the P2P PW associated with that Root PE
- Finally, creates a forwarding state in the VPLS instance for
the P2P PW associated with the Root PE with a destination
MAC address being the same as the source MAC address being
learned.
5.7. Loop Free Topology
This updates section 4.4. of [RFC4762]
Paragraph 2 "must not forward from one PW to another" is applicable
to P2MP PW & P2P PW.
5.8. Hierarchical VPLS
This refers to section 10 and 11 in [RFC4762]. No change is required.
5.9 P2MP PW Status
In case of a P2MP PW status change to not operational as per
[P2MP-PW-LDP], then this should be treated as if this P2MP PW does
not exist.
Delord & Key Expires Dec 2015 [Page 11]
Internet Draft Ext to LDP-VPLS for broadcast multicast June 2015
6. Local PE Implementation
This section is OPTIONAL.
As described in section 2.1.1, a PE receiving an IP multicast frame,
will forward it to all ACs, including those with no member of the
specific IP multicast group attached.
Unnecessary traffic consumes bandwidth on the access link and may
become a concern from the customer perspective. In some cases, it may
also be a security concern as the multicast frame may be forwarded to
an endpoint other than the intended destinations.
Consequently, the use of some L3 related supplementary information in
order to improve bandwidth consumption on the AC may be considered.
Enabling L3 snooping on an AC basis only has an impact on the PE
where the AC belongs, it does not impact the number of P2MP PW/LSPs
used within the carrier's network and the state resources or the
maintenance complexity associated with it.
Alternatives to L3 snooping such as static configuration of multicast
Ethernet addresses & ports / interfaces for example are also
possible.
7. Security Considerations
This document does not introduce any new security issues beyond those
already described in [RFC4762].
8. IANA Considerations
This document does not require IANA assignment.
9. Acknowledgments
The authors would like to thank Marc Lasserre, Cesar Garrido, Lucy
Yong, Neil Harrison, Samer Salam, Nocolai Leymann, Florin Balus, Olen
Stokes, Ali Sajassi, Phil Bedard, Thomas Beckhaus, Linda Dunbar, Max
Ng, Asaf Henig, Mark Whalley and Cary Wright for their valuable
comments.
Delord & Key Expires Dec 2015 [Page 12]
Internet Draft Ext to LDP-VPLS for broadcast multicast June 2015
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4762] Lasserre & Kompella, "Virtual Private LAN Service (VPLS)
Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007.
[P2MP-PW-LDP] Sivabalan, et. al, "Signaling Root-Initiated
Point-to-Multipoint Pseudowires using LDP",
draft-ietf-pwe3-p2mp-pw-04, work in Progress,
March 2012.
[RFC6388] Wijnands, et. al, "Label Distribution Protocol Extensions
for Point-to-Multipoint and Multipoint-to-Multipoint Label
Switched Paths", RFC 6388, November 2011.
[RFC4875] R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed.,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label
Assignment and Context Specific Label Space", RFC 5331,
August 2008.
10.2. Informative References
[RFC5501] Kamite, et al., "Requirements for Multicast Support in
Virtual Private LAN Services", RFC 5501, March 2009.
[RFC7338] Jounay, et. al, "Requirements and Framework for
Point-to-Multipoint Pseudowires over MPLS PSNs",
RFC 7338, September 2014
[RFC7117] Raggarwa, Kamite & Fang, "Multicast in VPLS", RFC 7117,
February 2014.
[RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for
Layer 2 Provider-Provisioned Virtual Private Networks",
RFC 4665, September 2006.
Delord & Key Expires Dec 2015 [Page 13]
Internet Draft Ext to LDP-VPLS for broadcast multicast June 2015
Author's Addresses
Simon Delord (editor)
Telstra
EMail: simon.delord@gmail.com
Raymond Key (editor)
AusNet Services
EMail: raymond.key@ieee.org
Frederic Jounay
Orange CH
4 rue caudray 1020 Renens
Switzerland
EMail: frederic.jounay@orange.ch
Yuji Kamite
NTT Communications Corporation
Granpark Tower
3-4-1 Shibaura, Minato-ku
Tokyo 108-8118
Japan
EMail: y.kamite@ntt.com
Zhihua Liu
China Telecom
109 Zhongshan Ave.
Guangzhou 510630
China
EMail: zhliu@gsta.com
Manuel Paul
Deutsche Telekom
Winterfeldtstr. 21-27
10781 Berlin, Germany
EMail: manuel.paul@telekom.de
Ruediger Kunze
Deutsche Telekom
Winterfeldtstr. 21-27
10781 Berlin, Germany
EMail: ruediger.kunze@telekom.de
Mach(Guoyi) Chen
Huawei Technology Co., Ltd.
Q14 Huawei Campus, No. 156 Beiqing Road
Hai-dian District, Beijing 100095
China
EMail: mach.chen@huawei.com
Lizhong Jin
EMail: lizho.jin@gmail.com
Delord & Key Expires Dec 2015 [Page 14]
Internet Draft Ext to LDP-VPLS for broadcast multicast June 2015
Appendix A. One example for broadcast video delivery
This section describes one deployment scenario in relation to
broadcast video delivery and how the proposed solution would work.
One requirement of the model is that the application needs unicast
data exchange (IP unicast transfer or control messages etc.) as a
background environment. MAC-learning (and therefore VPLS) is
effective to support it.
A.1. Broadcast Video Delivery Topology
Figure 3 presents the physical topology of one broadcast video
deployment.
| | |
AC AC AC
| | |
+---+ +---+ +---+
|PE3| |PE4| |PE5|
+---+ +---+ +---+
\ | /
\ | / +----+
\ | / +---|PE9 |--AC--
\ | / / +----+
Ethernet +---+ +---+ +---+/ +----+
Broadcast->-AC--|PE1|----------|P1 |--------|P3 |------|PE10|--AC--
Source +---+\ /+---+ +---+\ +----+
\ / | | \ +----+
\ / | | +---|PE11|--AC--
\ / | | +----+
\/ | |
/\ | |
/ \ | | +----+
/ \ | | +---|PE12|--AC--
/ \ | | / +----+
Ethernet +---+/ \+---+ +---+/ +----+
Broadcast->-AC--|PE2|----------|P2 |--------|P4 |------|PE13|--AC--
Source +---+ +---+ +---+\ +----+
/ | \ \ +----+
/ | \ +---|PE14|--AC--
/ | \ +----+
/ | \
+---+ +---+ +---+
|PE6| |PE7| |PE8|
+---+ +---+ +---+
| | |
AC AC AC
| | |
Figure 3 - Physical Topology for Broadcast video
Delord & Key Expires Dec 2015 [Page 15]
Internet Draft Ext to LDP-VPLS for broadcast multicast June 2015
Figure 3 is split in three logical components:
- The Core network composed of P1, P2, P3 & P4. These 4 network
elements are P routers connected in a ring.
- The Data Centers. These are a few large PoPs with high resiliency
that hold the video content. PE1 & PE2 are located in one Data
Center and are dual-homed to the core network. An Ethernet
broadcast source is connected to each PE in the Data Center.
- The Aggregation network. The Aggregation network is responsible
for aggregating last mile technology towards endusers (direct
fiber, GPON, DSL, etc.). PE3, PE4, until PE14 are VPLS PE routers
in an aggregation PoP and single-homed to the Core network.
There are two different video distribution services organised as
follows:
- PE1 is connected to PE3, PE4, ... PE14 via VPLS instance-1.
- One Ethernet broadcast source is connected to PE1 into VPLS
instance-1.
- PE2 is connected to PE3, PE4 ...PE14 via VPLS instance-2.
- One Ethernet broadcast source is connected to PE2 into VPLS
instance-2.
A.2. Impact of Physical Topologies on Ethernet Broadcast/multicast
replication
Following the standard VPLS flooding mechanism, each time PE1
receives one broadcast frame from the Ethernet broadcast source on
VPLS-1, PE1 will replicate 12 times the incoming frame.
Similarly, each time PE2 receives one broadcast frame from the
Ethernet broadcast source on VPLS-2, PE2 will replicate 12 times the
incoming frame.
Delord & Key Expires Dec 2015 [Page 16]
Internet Draft Ext to LDP-VPLS for broadcast multicast June 2015
A.3. Proposed enhancement of Ethernet broadcast/multicast
The proposed enhancements are done in three steps:
- create P2MP LSPs for the infrastructure. These P2MP LSPs are
used to carry one or more P2MP PWs.
- create unidirectional P2MP PWs by selectively choosing PEs where
the optimisation should occur.
- forward Ethernet broadcast/multicast frames onto the P2MP PWs
where these P2MP PWs have been created.
It is up to the network operator to decide how the distribution of
the loading on physical link should occur.
Two different examples are presented below.
A.3.1. One possible enhancement scenario
A.3.1.1. Initial Deployment
In this scenario, the operator decides to create the following P2MP
LSPs:
- PE1->PE3-5 via P1 called LSP1
- PE1->PE6-8 via P2 called LSP2
- PE1->PE9-11 via P3 called LSP3
- PE2->PE3-5 via P1 called LSP4
- PE2->PE6-8 via P2 called LSP5
- PE2->PE9-11 via P3 called LSP6
The operator then creates the following P2MP PWs:
- PE1->PE3-5 via P2MP PW1 over LSP1
- PE1->PE6-8 via P2MP PW2 over LSP2
- PE1->PE9-11 via P2MP PW3 over LSP3
- PE2->PE3-5 via P2MP PW4 over LSP4
- PE2->PE6-8 via P2MP PW5 over LSP5
- PE2->PE9-11 via P2MP PW6 over LSP6
There is no P2MP PWs between PE1 and PE12, PE13 and PE14.
There is no P2MP PWs between PE2 and PE12, PE13 and PE14.
Delord & Key Expires Dec 2015 [Page 17]
Internet Draft Ext to LDP-VPLS for broadcast multicast June 2015
There are several reasons why a P2MP PW may not be available on this
part of the network (e.g. PE12, PE13 and PE14), for example:
- the hardware/software may not allow the support of the
required features (P2MP LSPs and/or P2MP PWs).
- the operator does not need to improve multicast/broadcast
services there (e.g. no specific bandwidth issue).
- the operator is currently under a migration phase where only
part of the network is migrated at a time.
In this case, when PE1 receives one broadcast frame from the
Ethernet broadcast source on VPLS-1:
- PE1 sends one copy of the broadcast frame onto P2MP PW1
- PE1 sends one copy of the broadcast frame onto P2MP PW2
- PE1 sends one copy of the broadcast frame onto P2MP PW3
- PE1 sends one copy onto the P2P PW towards PE12
- PE1 sends one copy onto the P2P PW towards PE13
- PE1 sends one copy onto the P2P PW towards PE14
PE1 only replicates 6 copies now (this is an improvement from 12
copies if only using P2P PWs).
A.3.1.2 Multiple P2MP PWs
Let's assume now that a new broadcast service is targeted at covering
endusers geographically connected to PE9, PE10 and PE11.
For example, this could be a wholesale service, where another carrier
with limited footprint for the region covered by PE9, PE10 and PE11
is seeking access for deploying its own broadcast application.
Based on the proposal in this document, and assuming that the
application also needs unicast data exchange, if the new broadcast
source is connected to PE1, it is then possible to:
- Create a new VPLS instance on PE1, PE9, PE10 and PE11 and a full-
mesh of P2P PWs between all 4 PEs.
- Build a new P2MP PW, called P2MP PW7 between PE1, PE9, PE10 & PE11
that uses the existing P2MP LSP - LSP3.
This proposal allows for both P2MP PW3 and P2MP PW7 to be carried
through a single MPLS P2MP tunnel, thus, removing the need to
maintain state in the network core for individual P2MP PWs. The P
routers in the core only need to be aware of the P2MP LSPs.
Delord & Key Expires Dec 2015 [Page 18]
Internet Draft Ext to LDP-VPLS for broadcast multicast June 2015
A.3.2. Another possible enhancement scenario
In this scenario, the operator decides to create the following two
P2MP LSPs:
- PE1-> PE3-14 via LSP1:
- P1 as a branch towards PE3, PE4, PE5, P2 and P3
- P2 as a branch towards PE6, PE7, PE8 and P4
- P3 as a branch towards PE9, PE10 and PE11
- P4 as a branch towards PE12, PE13 and PE14
- PE2-> PE3-14 via LSP2:
- P2 as a branch towards PE6, PE7, PE8, P1 and P4
- P1 as a branch towards PE3, PE4, PE5 and P3
- P3 as a branch towards PE9, PE10 and PE11
- P4 as a branch towards PE12, PE13 and PE14
The operator then creates the following P2MP PWs:
- PE1-> PE3-14 via P2MP PW1 over LSP1
- PE2-> PE3-14 via P2MP PW2 over LSP2
This case improves the P2P PW scenario as PE1 only replicates a
single copy of the broadcast frame received from the Ethernet
broadcast source.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
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 Simplified BSD License.
Delord & Key Expires Dec 2015 [Page 19]
