One document matched: draft-ietf-l2vpn-etree-reqt-04.txt
Differences from draft-ietf-l2vpn-etree-reqt-03.txt
Network Working Group Raymond Key (editor), Huawei
Internet Draft Simon Delord, Telstra
Category: Informational Frederic Jounay, Orange CH
Expires: October 2013 Lu Huang, China Mobile
Zhihua Liu, China Telecom
Manuel Paul, Deutsche Telekom
Ruediger Kunze, Deutsche Telekom
Nick Del Regno, Verizon
Josh Rogers, Time Warner Cable
April 4, 2013
Requirements for MEF E-Tree Support in L2VPN
draft-ietf-l2vpn-etree-reqt-04
Abstract
This document provides functional requirements for Metro Ethernet
Forum (MEF) Ethernet Tree (E-Tree) support in multipoint L2VPN
solutions (referred to as simply L2VPN). It is intended that
potential solutions will use these requirements as guidelines.
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 October 4, 2013.
Key, et al. Expires October 2013 [Page 1]
Internet Draft Requirement E-Tree in L2VPN April 2013
Table of Contents
1. Introduction....................................................3
2. IETF Multipoint Ethernet L2VPN Services.........................3
2.1. VPLS..........................................................3
2.2. E-VPN.........................................................3
3. MEF Multipoint Ethernet Services................................3
3.1. Similarity between E-LAN and E-Tree...........................3
3.2. Difference between E-LAN and E-Tree...........................4
3.3. E-Tree Use Cases..............................................4
3.4. Generic E-Tree Service........................................5
4. Problem Statement...............................................5
4.1. Motivation....................................................5
4.2. Leaf-to-Leaf Communication Restriction........................5
5. Requirements....................................................6
5.1. Functional Requirements.......................................6
5.2. Applicability.................................................6
5.3. Backward Compatibility........................................7
5.4. External Network Network Interface............................7
6. Security Consideration..........................................7
7. IANA Considerations.............................................7
8. Acknowledgements................................................7
9. References......................................................7
9.1. Normative References..........................................7
9.2. Informative References........................................8
Appendix
A. Frequently Asked Questions......................................9
A.1. Are E-Tree requirements addressed in the Virtual
Private Multicast Service (VPMS) requirements?................9
A.2. Are there any potential deployment scenarios for
a "VPLS Only" solution?......................................10
Authors' Addresses................................................13
Intellectual Property and Copyright Statements....................14
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].
Key, et al. Expires October 2013 [Page 2]
Internet Draft Requirement E-Tree in L2VPN April 2013
1. Introduction
This document provides functional requirements for Metro Ethernet
Forum (MEF) Ethernet Tree (E-Tree) support in multipoint L2VPN
solutions (referred to as simply L2VPN). It is intended that
potential solutions will use these requirements as guidelines.
Considerable number of service providers have adopted VPLS to provide
MEF Ethernet LAN (E-LAN) services to customers. Service Providers
currently need a simple and effective solution to emulate E-Tree
services in addition to E-LAN services on their MPLS networks.
Service providers also expect E-Tree support in any newly developed
L2VPN technologies.
2. IETF Multipoint Ethernet L2VPN Services
2.1. VPLS
VPLS [RFC4761] [RFC4762] is a L2VPN service that provides multipoint-
to-multipoint connectivity for Ethernet across an IP or MPLS-enabled
IP Packet Switched Network (PSN). VPLS emulates the Ethernet Virtual
Local Area Network (VLAN) functionality of traditional Ethernet
networks. Thus, in VPLS, the customer Ethernet frame is transported
over the IP/MPLS PSN from the ingress Provider Edge (PE) to the
egress PE where the destination is connected based on the Ethernet
frame destination MAC address.
2.2. E-VPN
E-VPN is an enhanced Layer-2 service that emulates an Ethernet VLAN
across a PSN, primarily targeted to support large scale L2VPNs with
resiliency requirements not satisfied by other L2VPN solutions.
E-VPN is currently under development. Please refer to [Draft EVPN
Req].
3. MEF Multipoint Ethernet Services
MEF has defined two multipoint Ethernet Service types:
- E-LAN (Ethernet LAN), multipoint-to-multipoint service
- E-Tree (Ethernet Tree), rooted-multipoint service
For full specification, please refer to [MEF6.1] [MEF10.2].
3.1. Similarity between E-LAN and E-Tree
Following are the similarities between E-LAN and E-Tree services.
- Data frame is Ethernet frame.
- Data forwarding can be MAC-based forwarding, to be specified by
service provider as service frame delivery attributes in the
particular service definition.
Key, et al. Expires October 2013 [Page 3]
Internet Draft Requirement E-Tree in L2VPN April 2013
- A generic E-LAN/E-Tree service is always bidirectional in the
sense that ingress frames can originate at any endpoint in the
service.
3.2. Difference between E-LAN and E-Tree
Within the context of a multipoint Ethernet service, each endpoint is
designated as either a Root or a Leaf. A Root can communicate with
all other endpoints in the same multipoint Ethernet service, however
a Leaf can only communicate with Roots but not Leafs.
The only difference between E-LAN and E-Tree is:
- E-LAN has Root endpoints only, which implies there is no
communication restriction between endpoints.
- E-Tree has both Root and Leaf endpoints, which implies there is a
need to enforce communication restriction between Leaf endpoints.
3.3. E-Tree Use Cases
Table 1 below presents some major E-Tree use cases.
+---------------------------+--------------+------------+
| Use Case | Root | Leaf |
+---+---------------------------+--------------+------------+
| 1 | Hub & Spoke VPN | Hub Site | Spoke Site |
+---+---------------------------+--------------+------------+
| 2 | Wholesale Access | Customer's | Customer's |
| | | Interconnect | Subscriber |
+---+---------------------------+--------------+------------+
| 3 | Mobile Backhaul | RAN Network | RAN Base |
| | | Controller | Station |
+---+---------------------------+--------------+------------+
| 4 | IEEE 1588 PTPv2 | PTP Server | PTP Client |
| | Clock Synchronisation | | |
+---+---------------------------+--------------+------------+
| 5 | Internet Access | Broadband | Subscriber |
| | [TR-101] | Network | |
| | | Gateway | |
+---+---------------------------+--------------+------------+
| 6 | Broadcast Video | Video Source | Subscriber |
| | (unidirectional only) | | |
+---+---------------------------+--------------+------------+
| 7 | Broadcast/Multicast Video | Video Source | Subscriber |
| | plus Control Channel | | |
+---+---------------------------+--------------+------------+
| 8 | Device Management | Management | Managed |
| | | System | Device |
+---+---------------------------+--------------+------------+
Table 1: E-Tree Use Cases
Key, et al. Expires October 2013 [Page 4]
Internet Draft Requirement E-Tree in L2VPN April 2013
Common to all use cases, direct layer 2 Leaf-to-Leaf communication is
not required. For Mobile backhaul, this may not be valid for LTE X2
interfaces [MEF22.1].
If direct layer 2 Leaf-to-Leaf communication is not allowed due to
security concern, then E-Tree should be used to prohibit
communication between Leaf endpoints, otherwise E-LAN is also a
feasible option.
3.4. Generic E-Tree Service
A generic E-Tree service supports multiple Root endpoints. The need
for multiple Root endpoints is usually driven by redundancy
requirement. Whether a particular E-Tree service needs to support
single or multiple Roots depends on the target application.
A generic E-Tree service supports all the following traffic flows:
- Ethernet Unicast from Root to Leaf
- Ethernet Unicast from Leaf to Root
- Ethernet Unicast from Root to Root
- Ethernet Broadcast/Multicast from Root to Roots & Leafs
- Ethernet Broadcast/Multicast from Leaf to Roots
A particular E-Tree service may need to support all the above or only
a subset depending on the target application.
4. Problem Statement
4.1. Motivation
L2VPN can be used to emulate MEF E-LAN service over an MPLS network
provided that the E-LAN service uses MAC-based forwarding as a
service frame delivery attributes.
Service providers also require E-Tree support in L2VPN.
4.2. Leaf-to-Leaf Communication Restriction
In this section, VPLS is used to illustrate the problem, but the same
principle applies to other L2VPN technologies.
VPLS treats all attachment circuits (ACs) equal (i.e. not classified
into Root or Leaf) and provides any-to-any connectivity among all
ACs. VPLS does not include any mechanism of communication restriction
between specific ACs, therefore it is insufficient for emulating
generic E-Tree service over IP/MPLS PSN.
As an example of the problems not addressed in VPLS solutions,
consider the scenario in Figure 1 where there are two PEs, each with
a Root AC and a Leaf AC and where VPLS is used to emulate an E-Tree
service over an MPLS network.
Key, et al. Expires October 2013 [Page 5]
Internet Draft Requirement E-Tree in L2VPN April 2013
<------------E-Tree------------>
+---------+ +---------+
| PE1 | | PE2 |
+---+ | +---+ | | +---+ | +---+
|CE1+-----AC1----+--+ | | | | +--+----AC3-----+CE3|
+---+ (Root AC) | | V | | Ethernet | | V | | (Root AC) +---+
| | S +--+-----PW-----+--+ S | |
+---+ | | I | | | | I | | +---+
|CE2+-----AC2----+--+ | | | | +--+----AC4-----+CE4|
+---+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +---+
+---------+ +---------+
Figure 1: Problem Scenario for Leaf-to-Leaf Communication Restriction
When PE2 receives a frame from PE1 via the Ethernet PW,
- PE2 does not know which AC on PE1 is the ingress AC
- PE2 does not know whether the ingress AC is a Leaf AC or not
- PE2 does not have sufficient information to enforce the
Leaf-to-Leaf communication restriction
Examples where the problems arise:
- CE2 sends a Broadcast/Multicast frame to PE1 via AC2
- CE2 sends a Unicast frame to PE1 via AC2 with destination MAC
address corresponding to CE4's MAC address
Note: Figure 1 is a hypothetical case solely used for explaining the
problem, and not meant to represent a typical E-Tree service.
There are some possible ways to get around this problem that do not
require extension to existing VPLS solutions but they all come with
significant design complexity or deployment constraints, please refer
to [Draft ETree Frwk] Appendix A.
5. Requirements
5.1. Functional Requirements
A solution MUST prohibit communication between any two Leaf ACs in a
L2VPN instance.
A solution MUST allow multiple Root ACs in a L2VPN instance.
A solution MUST allow Root AC and Leaf AC of a L2VPN instance to
co-exist on any PE.
5.2. Applicability
A solution MUST identify the L2VPN technology ([RFC4761], [RFC4762],
E-VPN) the solution is applicable to.
Key, et al. Expires October 2013 [Page 6]
Internet Draft Requirement E-Tree in L2VPN April 2013
5.3. Backward Compatibility
A solution SHOULD minimise the impact on VPLS and E-VPN L2VPN
solutions, especially for the MEF E-LAN services already in
operation.
A solution SHOULD be backward compatible with the VPLS and E-VPN
L2VPN solutions. It SHOULD allow a case where a common L2VPN instance
is composed of both PEs supporting the solution and PEs not
supporting it, and the Leaf-to-Leaf communication restriction is
enforced within the scope of the compliant PEs.
5.4. External Network Network Interface
A solution SHOULD support Root Operator Virtual Connection (OVC) End
Point, Leaf OVC End Point and Trunk OVC End Point specified in
[MEF26.1].
6. Security Considerations
This document introduces a requirement of prohibiting communication
between any two Leaf ACs in a L2VPN instance. In some use cases, such
requirement is imposed because of security reasons. Other than that,
there are no additional security considerations beyond those already
described in [RFC4761] [RFC4762].
7. IANA Considerations
This document has no actions for IANA.
8. Acknowledgements
The authors would like to thank Lizhong Jin, Lucy Yong, Yuji Kamite
and Wim Henderickx for their valuable input and support.
9. References
9.1. Normative References
[MEF6.1] Metro Ethernet Forum, Ethernet Services Definitions -
Phase 2, April 2008
[MEF10.2] Metro Ethernet Forum, Ethernet Services Attributes -
Phase 2, October 2009
[MEF22.1] Metro Ethernet Forum, Mobile Backhaul Implementation
Agreement - Phase 2, January 2012
[MEF26.1] Metro Ethernet Forum, External Network Network Interface
(ENNI) - Phase 2, January 2012
Key, et al. Expires October 2013 [Page 7]
Internet Draft Requirement E-Tree in L2VPN April 2013
[RFC2119] Bradner, S., Key words for use in RFCs to Indicate
Requirement Levels, BCP 14, RFC 2119, March 1997
[RFC4761] Kompella & Rekhter, Virtual Private LAN Service (VPLS)
Using BGP for Auto-Discovery and Signaling, January 2007
[RFC4762] Lasserre & Kompella, Virtual Private LAN Service (VPLS)
Using Label Distribution Protocol (LDP) Signaling,
January 2007
9.2. Informative References
[Draft EVPN Req]
Sajassi, Aggarwal, et al., Requirements for Ethernet VPN
(E-VPN), draft-ietf-l2vpn-evpn-req-02 (work in
progress), February 2013
[TR-101] Broadband Forum, Migration to Ethernet-Based Broadband
Aggregation Issue 2, July 2011
[Draft ETree Frwk]
Key, et al., A Framework for E-Tree Service over MPLS
Network, draft-ietf-l2vpn-etree-frwk-02 (work in
progress), February 2013
[Draft VPMS Frmwk]
Kamite, et al., Framework and Requirements for Virtual
Private Multicast Service (VPMS),
draft-ietf-l2vpn-vpms-frmwk-requirements-05 (work in
progress), October 2012
Key, et al. Expires October 2013 [Page 8]
Internet Draft Requirement E-Tree in L2VPN April 2013
Appendix A. Frequently Asked Questions
A.1. Are E-Tree requirements addressed in the Virtual Private Multicast
Service (VPMS) requirements?
VPMS requirements are defined in [Draft VPMS Frmwk].
The focus of VPMS is to provide point-to-multipoint connectivity.
VPMS provides single coverage of receiver membership (i.e. there is
no distinct differentiation for multiple multicast groups). A VPMS
service supports single or multiple Root ACs. All traffic from a Root
AC will be forwarded to all Leaf ACs (i.e. P2MP, from Root to all
Leafs). Destination address in Ethernet frame is not used in data
forwarding. As an optional capability, a VPMS service may support
reverse traffic from a Leaf AC to a Root AC (i.e. P2P, from Leaf to
Root).
In contrast, the focus of MEF E-Tree is that a Leaf can only
communicate with Roots but not Leafs.
A generic MEF E-Tree service supports multiple Root endpoints.
Whether a particular E-Tree service needs to support single or
multiple Root endpoints depends on the target application.
A generic MEF E-Tree service supports all the following traffic
flows:
- Ethernet Unicast bidirectional Root to/from Root
- Ethernet Unicast bidirectional Root to/from Leaf
- Ethernet Broadcast/Multicast unidirectional Root to all Roots &
Leafs
- Ethernet Broadcast/Multicast unidirectional Leaf to all Roots.
A particular E-Tree service may need to support all the above or only
a subset depending on the target application.
IETF's VPMS definition and MEF's E-Tree definition are significantly
different.
Only for special case E-Tree service where
- No Unicast traffic from Root destined for a specific Leaf (or
there is no concern if such Unicast traffic is forwarded to all
Leafs)
- No traffic between Roots
VPMS will be able to meet the requirement. An example is E-Tree
service for content delivery application.
For generic E-Tree service, VPMS will not be able to meet the
requirements.
Key, et al. Expires October 2013 [Page 9]
Internet Draft Requirement E-Tree in L2VPN April 2013
A.2. Are there any potential deployment scenarios for a "VPLS Only"
solution?
Yes, there are potential deployment scenarios for a "VPLS Only"
solution with enhancements to support E-Tree services, some examples
below.
Example 1 -
Enhanced VPLS with
<-----Physical P2P Service------><-----E-Tree Support-----
+---------+
+---+ | PE1 |
+---+ |NTU| | +---+ |
|CE1+------+---+--V1-----------------AC1----+--+ | |
+---+ Root +---+ (Root AC) | | V | |
| | | | Ethernet
+---+ | | S +--+----PW--->PE2
+---+ |NTU| | | | |
|CE2+------+---+--V2-----------------AC2----+--+ I | |
+---+ Root +---+ (Root AC) | | | |
| | | |
+---+ | | | |
+---+ |NTU| | | | |
|CE3+------+---+--V3-----------------AC3----+--+ | |
+---+ Root +---+ (Root AC) | | | |
| | | |
+---+ | | | |
+---+ |NTU| | | | |
|CE4+------+---+--V4-----------------AC4----+--+ | |
+---+ Leaf +---+ (Leaf AC) | | | |
| | | |
+---+ | | | |
+---+ |NTU| | | | |
|CE5+------+---+--V5-----------------AC5----+--+ | |
+---+ Leaf +---+ (Leaf AC) | +---+ |
+---------+
Key, et al. Expires October 2013 [Page 10]
Internet Draft Requirement E-Tree in L2VPN April 2013
Example 2 -
Logical P2P Service Enhanced VPLS with
<-------via Access Switch-------><-----E-Tree Support-----
+---------+ +---------+
| Access | | PE1 |
+---+ | Switch | | |
+---+ |NTU| | | | +---+ |
|CE1+------+---+--V1--+--VLAN1--+--V1--AC1--+--+ | |
+---+ Root +---+ | | (Root AC) | | V | |
+---------+ | | | | Ethernet
| | S +--+----PW--->PE2
+---------+ | | | |
| Access | | | I | |
+---+ | Switch | | | | |
+---+ |NTU| | | | | | |
|CE2+------+---+--V2--+--VLAN2--+--V2--AC2--+--+ | |
+---+ Root +---+ | | (Root AC) | | | |
| | | | | |
+---+ | | | | | |
+---+ |NTU| | | | | | |
|CE3+------+---+--V3--+--VLAN3--+--V3--AC3--+--+ | |
+---+ Root +---+ | | (Root AC) | | | |
| | | | | |
+---+ | | | | | |
+---+ |NTU| | | | | | |
|CE4+------+---+--V4--+--VLAN4--+--V4--AC4--+--+ | |
+---+ Leaf +---+ | | (Leaf AC) | | | |
| | | | | |
+---+ | | | | | |
+---+ |NTU| | | | | | |
|CE5+------+---+--V5--+--VLAN5--+--V5--AC5--+--+ | |
+---+ Leaf +---+ | | (Leaf AC) | +---+ |
+---------+ +---------+
Key, et al. Expires October 2013 [Page 11]
Internet Draft Requirement E-Tree in L2VPN April 2013
Example 3 -
Ethernet Switching Enhanced VPLS with
<------with Split Horizon-------><-----E-Tree Support-----
+---------+ +---------+
| Access | | PE1 |
| Switch | | |
| | | |
| +---+ | | +---+ |
+---+ | | V | | | | | |
+---+ |NTU| | | L | | | | V | |
|CE1+------+---+--V1--+--+ A +--+--V1--AC1--+--+ | |
+---+ Root +---+ | | N | | (Root AC) | | S | |
| | 1 | | | | | | Ethernet
| +---+ | | | I +--+----PW--->PE2
+---------+ | | | |
| | | |
+---------+ | | | |
| Access | | | | |
| Switch | | | | |
+---+ | | | | | |
+---+ |NTU| | +---+ | | | | |
|CE2+------+---+--V2--+--+ V | | | | | |
+---+ Root +---+ | | L | | | | | |
| | A +--+--V2--AC2--+--+ | |
+---+ | | N | | (Root AC) | | | |
+---+ |NTU| | | 2 | | | | | |
|CE3+------+---+--V2--+--+ | | | | | |
+---+ Root +---+ | +---+ | | | | |
| | | | | |
+---+ | | | | | |
+---+ |NTU| | +---+ | | | | |
|CE4+------+---+--V4--+SH+ V | | | | | |
+---+ Leaf +---+ | | L | | | | | |
| | A +--+--V4--AC4--+--+ | |
+---+ | | N | | (Leaf AC) | | | |
+---+ |NTU| | | 4 | | | | | |
|CE5+------+---+--V4--+SH+ | | | | | |
+---+ Leaf +---+ | +---+ | | +---+ |
+---------+ +---------+
Note:
- Group Roots and Leafs into two separate VLANs on Access Switch
- SH means member of split horizon group on Access Switch
Key, et al. Expires October 2013 [Page 12]
Internet Draft Requirement E-Tree in L2VPN April 2013
Authors' Addresses
Raymond Key (editor)
Huawei
Email: raymond.key@ieee.org
Simon Delord
Telstra
Email: simon.delord@gmail.com
Frederic Jounay
Orange CH
4 rue caudray 1020 Renens
Switzerland
Email: frederic.jounay@orange.ch
Lu Huang
China Mobile
Unit 2, 28 Xuanwumenxi Ave, Xuanwu District
Beijing 100053, China
Email: huanglu@chinamobile.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
Nick Del Regno
Verizon
400 International Pkwy
Richardson, TX 75081, USA
Email: nick.delregno@verizon.com
Josh Rogers
Time Warner Cable
11921 N Mo Pac Expy
Suite 210B
Austin, TX 78759, USA
Email: josh.rogers@twcable.com
Key, et al. Expires October 2013 [Page 13]
Internet Draft Requirement E-Tree in L2VPN April 2013
Copyright Notice
Copyright (c) 2013 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.
Key, et al. Expires October 2013 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-21 11:47:07 |