summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7152.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7152.txt')
-rw-r--r--doc/rfc/rfc7152.txt675
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc7152.txt b/doc/rfc/rfc7152.txt
new file mode 100644
index 0000000..13d77c5
--- /dev/null
+++ b/doc/rfc/rfc7152.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) R. Key, Ed.
+Request for Comments: 7152 S. Delord
+Category: Informational Telstra
+ISSN: 2070-1721 F. Jounay
+ Orange CH
+ L. Huang
+ China Mobile
+ Z. Liu
+ China Telecom
+ M. Paul
+ Deutsche Telekom
+ March 2014
+
+
+ Requirements for Metro Ethernet Forum (MEF) Ethernet-Tree (E-Tree)
+ Support in Layer 2 Virtual Private Network (L2VPN)
+
+Abstract
+
+ This document provides functional requirements for the support of
+ Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in multipoint Layer
+ 2 Virtual Private Network solutions (referred to as simply "L2VPN").
+ It is intended that potential solutions will use these requirements
+ as guidelines.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7152.
+
+
+
+
+
+
+
+
+
+
+
+Key, et al. Informational [Page 1]
+
+RFC 7152 Requirement E-Tree in L2VPN March 2014
+
+
+Copyright Notice
+
+ Copyright (c) 2014 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.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Conventions Used in This Document ..........................3
+ 2. IETF Multipoint Ethernet L2VPN Services .........................3
+ 2.1. VPLS .......................................................3
+ 2.2. Ethernet Virtual Private Network (E-VPN) ...................3
+ 3. MEF Multipoint Ethernet Services ................................4
+ 3.1. Similarities between E-LAN and E-Tree ......................4
+ 3.2. Differences between E-LAN and E-Tree .......................4
+ 3.3. E-Tree Use Cases ...........................................5
+ 3.4. Generic E-Tree Service .....................................6
+ 4. Problem Statement ...............................................6
+ 4.1. Motivation .................................................6
+ 4.2. Leaf-to-Leaf Communication Restriction .....................6
+ 5. Requirements ....................................................7
+ 5.1. Functional Requirements ....................................7
+ 5.2. Applicability ..............................................8
+ 5.3. Backward Compatibility .....................................8
+ 5.4. External Network Network Interface (ENNI) ..................8
+ 6. Security Considerations .........................................8
+ 7. Contributors ....................................................8
+ 8. Acknowledgements ................................................9
+ 9. References ......................................................9
+ 9.1. Normative References .......................................9
+ 9.2. Informative References ....................................10
+ Appendix A. Frequently Asked Question .............................11
+ A.1. Are E-Tree Requirements Addressed in the Virtual
+ Private Multicast Service (VPMS) Requirements? ...............11
+
+
+
+
+
+
+
+Key, et al. Informational [Page 2]
+
+RFC 7152 Requirement E-Tree in L2VPN March 2014
+
+
+1. Introduction
+
+ This document provides functional requirements for the support of
+ Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in multipoint Layer
+ 2 Virtual Private Network solutions (referred to as simply "L2VPN").
+ It is intended that potential solutions will use these requirements
+ as guidelines.
+
+ A considerable number of service providers have adopted Virtual
+ Private LAN Service (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.
+
+1.1. 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].
+
+2. IETF Multipoint Ethernet L2VPN Services
+
+2.1. VPLS
+
+ VPLS [RFC4761] [RFC4762] is an L2VPN service that provides
+ multipoint-to-multipoint connectivity for Ethernet across an IP or
+ MPLS-enabled IP Packet Switched Network (IP/MPLS PSN). VPLS emulates
+ the Ethernet 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 Media Access Control (MAC) address in the context of the
+ virtual switching instance (VSI) to which it belongs.
+
+2.2. Ethernet Virtual Private Network (E-VPN)
+
+ E-VPN is an enhanced L2 service that emulates an Ethernet VLAN across
+ an IP/MPLS 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 [EVPN].
+
+
+
+
+
+
+
+Key, et al. Informational [Page 3]
+
+RFC 7152 Requirement E-Tree in L2VPN March 2014
+
+
+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 the full specifications, please refer to [MEF6.1] and [MEF10.2].
+
+3.1. Similarities between E-LAN and E-Tree
+
+ The following are the similarities between E-LAN and E-Tree services.
+
+ - Data frame is an Ethernet frame.
+ - Data forwarding is MAC-based forwarding.
+ - 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. Differences 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 Leaves.
+
+ The only differences between E-LAN and E-Tree are:
+
+ - 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Key, et al. Informational [Page 4]
+
+RFC 7152 Requirement E-Tree in L2VPN March 2014
+
+
+3.3. E-Tree Use Cases
+
+ Table 1 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 | Radio Access | RAN Base |
+ | | | Network (RAN)| Station |
+ | | | Network | |
+ | | | Controller | |
+ +---+---------------------------+--------------+------------+
+ | 4 | IEEE 1588 PTPv2 | Precision | PTP Client |
+ | | Clock Synchronisation | Time Protocol| |
+ | | [IEEE1588] | (PTP) Server | |
+ +---+---------------------------+--------------+------------+
+ | 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
+
+ Common to all use cases, direct L2 Leaf-to-Leaf communication is not
+ required or must be inhibited.
+
+ If direct L2 Leaf-to-Leaf communication is not allowed due to a
+ security concern, then E-Tree should be used to prohibit
+ communication between Leaf endpoints. Otherwise, E-LAN is also a
+ feasible option.
+
+
+
+
+
+
+
+Key, et al. Informational [Page 5]
+
+RFC 7152 Requirement E-Tree in L2VPN March 2014
+
+
+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 a 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 other Roots and Leaves
+ - 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 IP/MPLS PSN.
+
+ 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; however, the
+ same principle applies to other L2VPN technologies.
+
+ VPLS treats all attachment circuits (ACs) equally (essentially as
+ Roots, although they not classified into Root or Leaf) and provides
+ any-to-any connectivity among all ACs. VPLS does not include any
+ mechanism for communication restriction between specific ACs.
+ Therefore, it is insufficient for emulating generic E-Tree service
+ over an 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 interconnecting these ACs over an IP/MPLS PSN.
+
+
+
+
+
+
+
+
+
+Key, et al. Informational [Page 6]
+
+RFC 7152 Requirement E-Tree in L2VPN March 2014
+
+
+ <------------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 pseudowire (PW),
+
+ - PE2 does not know which AC on PE1 is the ingress AC
+ - PE2 does not know whether or not the ingress AC is a Leaf AC
+ - PE2 does not have sufficient information to enforce the Leaf-to-
+ Leaf communication restriction
+
+ Examples where the problems arise:
+
+ - Customer Edge 2 (CE2) sends a Broadcast/Multicast Ethernet frame
+ to PE1 via AC2
+ - CE2 sends a Unicast Ethernet frame to PE1 via AC2 with a
+ destination MAC address corresponding to CE4's MAC address
+
+ Note: Figure 1 is a hypothetical case solely used for explaining the
+ problem; it is not meant to represent a typical E-Tree service.
+
+ There are some possible ways to get around this problem that do not
+ require extensions to existing VPLS solutions, but they all come with
+ significant design complexity or deployment constraints.
+
+5. Requirements
+
+5.1. Functional Requirements
+
+ The following are the E-Tree L2VPN functional requirements:
+
+ (1) A solution MUST prohibit communication between any two Leaf ACs
+ in an L2VPN instance.
+
+ (2) A solution MUST allow multiple Root ACs in an L2VPN instance.
+
+
+
+
+
+
+Key, et al. Informational [Page 7]
+
+RFC 7152 Requirement E-Tree in L2VPN March 2014
+
+
+ (3) A solution MUST allow a Root AC and Leaf AC of an L2VPN instance
+ to coexist on any PE.
+
+5.2. Applicability
+
+ A solution MUST identify the L2VPN technology ([RFC4761], [RFC4762],
+ [EVPN]) to which the solution is applicable.
+
+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 (ENNI)
+
+ 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 an L2VPN instance. In some use cases,
+ such a requirement is imposed because of security reasons. Other
+ than that, there are no additional security considerations beyond
+ those already described in [RFC4761], [RFC4762], and [EVPN].
+
+7. Contributors
+
+ 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
+
+
+
+
+Key, et al. Informational [Page 8]
+
+RFC 7152 Requirement E-Tree in L2VPN March 2014
+
+
+ Josh Rogers
+ Time Warner Cable
+ 11921 N Mo Pac Expy
+ Suite 210B
+ Austin, TX 78759, USA
+ EMail: josh.rogers@twcable.com
+
+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", Technical Specification MEF 6.1, April 2008,
+ <http://metroethernetforum.org/Assets/
+ Technical_Specifications/PDF/MEF6-1.pdf>.
+
+ [MEF10.2] Metro Ethernet Forum, "Ethernet Services Attributes
+ Phase 2", Technical Specification MEF 10.2, October
+ 2009, <http://metroethernetforum.org/Assets/
+ Technical_Specifications/PDF/MEF10.2.pdf>.
+
+ [MEF26.1] Metro Ethernet Forum, "External Network Network
+ Interface (ENNI) Phase 2", Technical Specification, MEF
+ 26.1, January 2012,
+ <http://metroethernetforum.org/Assets/
+ Technical_Specifications/PDF/MEF_26.1.pdf>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private
+ LAN Service (VPLS) Using BGP for Auto-Discovery and
+ Signaling", RFC 4761, January 2007.
+
+ [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual
+ Private LAN Service (VPLS) Using Label Distribution
+ Protocol (LDP) Signaling", RFC 4762, January 2007.
+
+
+
+
+
+
+
+
+
+Key, et al. Informational [Page 9]
+
+RFC 7152 Requirement E-Tree in L2VPN March 2014
+
+
+9.2. Informative References
+
+ [EVPN] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N.,
+ Henderickx, W., and A. Isaac, "Requirements for Ethernet
+ VPN (EVPN)", Work in Progress, February 2014.
+
+ [IEEE1588] IEEE, "1588-2008 Standard for a Precision Clock
+ Synchronization Protocol for Networked Measurement and
+ Control Systems", July 2008.
+
+ [TR-101] Broadband Forum, "Migration to Ethernet-Based DSL
+ Aggregation", Technical Report, DSL Forum TR-101, April
+ 2006, <http://www.broadband-forum.org/
+ technical/download/TR-101.pdf>.
+
+ [VPMS] Kamite, Y., Jounay, F., Niven-Jenkins, B., Brungard, D.,
+ and L. Jin, "Framework and Requirements for Virtual
+ Private Multicast Service (VPMS)", Work in Progress,
+ October 2012.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Key, et al. Informational [Page 10]
+
+RFC 7152 Requirement E-Tree in L2VPN March 2014
+
+
+Appendix A. Frequently Asked Question
+
+A.1. Are E-Tree Requirements Addressed in the Virtual Private Multicast
+ Service (VPMS) Requirements?
+
+ VPMS requirements are defined in [VPMS].
+
+ 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., Point-to-Multipoint
+ (P2MP), from Root to all Leaves). The destination address in an
+ 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., point-to-point (P2P), from Leaf to Root).
+
+ In contrast, the focus of MEF E-Tree is that a Leaf can only
+ communicate with Roots, not Leaves.
+
+ 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.
+
+ As discussion in a previous section, 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
+ and Leaves
+ - 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.
+
+ The IETF's VPMS definition and MEF's E-Tree definition are
+ significantly different.
+
+ VPMS may be acceptable in cases where E-Tree service is needed, such
+ as in the following cases:
+
+ - No Unicast traffic from Root destined for a specific Leaf (or
+ there is no concern if such Unicast traffic is forwarded to all
+ Leaves)
+ - No traffic between Roots
+
+
+
+
+Key, et al. Informational [Page 11]
+
+RFC 7152 Requirement E-Tree in L2VPN March 2014
+
+
+ For generic E-Tree service, VPMS will not be able to meet the
+ requirements.
+
+Authors' Addresses
+
+ Raymond Key (editor)
+
+ 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
+
+
+
+
+
+Key, et al. Informational [Page 12]
+