diff options
Diffstat (limited to 'doc/rfc/rfc7796.txt')
| -rw-r--r-- | doc/rfc/rfc7796.txt | 1459 |
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc7796.txt b/doc/rfc/rfc7796.txt new file mode 100644 index 0000000..43d6f50 --- /dev/null +++ b/doc/rfc/rfc7796.txt @@ -0,0 +1,1459 @@ + + + + + + +1;2c. +Internet Engineering Task Force (IETF) Y. Jiang, Ed. +Request for Comments: 7796 L. Yong +Category: Standards Track Huawei +ISSN: 2070-1721 M. Paul + Deutsche Telekom + March 2016 + + + Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) + +Abstract + + This document specifies a generic Virtual Private LAN Service (VPLS) + solution, which uses VLANs to indicate root or leaf traffic to + support Ethernet-Tree (E-Tree) services. A VPLS Provider Edge (PE) + model is illustrated as an example for the solution. In the + solution, E-Tree VPLS PEs are interconnected by Pseudowires (PWs), + which carry the VLAN indicating the E-Tree attribute. The MAC + address-based Ethernet forwarding engine and the PW work in the same + way as specified in RFC 4762 and RFC 4448, respectively. A signaling + mechanism is described to support E-Tree capability and VLAN mapping + negotiation. + +Status of This Memo + + This is an Internet Standards Track document. + + 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). Further information on + Internet Standards is available in 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/rfc7796. + + + + + + + + + + + + + + +Jiang, et al. Standards Track [Page 1] + +RFC 7796 E-Tree Support in VPLS March 2016 + + +Copyright Notice + + Copyright (c) 2016 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 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4. PE Model with E-Tree Support . . . . . . . . . . . . . . . . 5 + 4.1. Existing PE Models . . . . . . . . . . . . . . . . . . . 5 + 4.2. A New PE Model with E-Tree Support . . . . . . . . . . . 8 + 5. PW for E-Tree Support . . . . . . . . . . . . . . . . . . . . 9 + 5.1. PW Encapsulation . . . . . . . . . . . . . . . . . . . . 9 + 5.2. VLAN Mapping . . . . . . . . . . . . . . . . . . . . . . 10 + 5.3. PW Processing . . . . . . . . . . . . . . . . . . . . . . 11 + 5.3.1. PW Processing in the VLAN Mapping Mode . . . . . . . 11 + 5.3.2. PW Processing in the Compatible Mode . . . . . . . . 12 + 5.3.3. PW Processing in the Optimized Mode . . . . . . . . . 13 + 6. Signaling for E-Tree Support . . . . . . . . . . . . . . . . 14 + 6.1. LDP Extensions for E-Tree Support . . . . . . . . . . . . 14 + 6.2. BGP Extensions for E-Tree Support . . . . . . . . . . . . 17 + 7. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 19 + 8. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 19 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 + 11.2. Informative References . . . . . . . . . . . . . . . . . 21 + Appendix A. Other PE Models for E-Tree . . . . . . . . . . . . . 23 + A.1. A PE Model with a VSI and No Bridge . . . . . . . . . . . 23 + A.2. A PE Model with External E-Tree Interface . . . . . . . . 24 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 25 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 + + + + + +Jiang, et al. Standards Track [Page 2] + +RFC 7796 E-Tree Support in VPLS March 2016 + + +1. Introduction + + The Ethernet-Tree (E-Tree) service is defined in the Metro Ethernet + Forum (MEF) Technical Specification MEF 6.2 [MEF6.2] as a Rooted- + Multipoint Ethernet Virtual Connection (EVC) service. An MEF 6.2 + E-Tree solution must meet the following design requirements: the + Ethernet frames from a root may be received by any other root or + leaf, and the frames from a leaf may be received by any root, but + must not be received by a leaf. Further, an E-Tree service may + include multiple roots and multiple leaves. Although Virtual Private + Multicast Service (VPMS) [VPMS] and Point-to-Multipoint (P2MP) + multicast are somewhat simplified versions of this service, in fact, + they are both multicast services and are different from an E-Tree + service that may include both unicast and multicast traffic. + + [RFC7152] gives the requirements for providing E-Tree solutions in + the VPLS and the need to filter leaf-to-leaf traffic. [RFC7387] + further describes a Multiprotocol Label Switching (MPLS) framework + for providing E-Tree. Though there were proposals for using the + Pseudowire (PW) control word or PWs to indicate the root/leaf + attribute of an E-Tree frame, both methods are limited in that they + are only applicable to "VPLS only" networks. + + A VPLS PE usually consists of a bridge module itself (see [RFC4664] + and [RFC6246]); and moreover, E-Tree services may cross both Ethernet + and VPLS domains. Therefore, it is necessary to develop an E-Tree + solution both for "VPLS only" scenarios and for interworking between + Ethernet and VPLS. + + IEEE 802.1 has incorporated the generic E-Tree solution into 802.1Q + [IEEE-802.1Q-2014], which is an improvement on the traditional + asymmetric VLAN mechanism. In the asymmetric VLAN mechanism as + described in Section B.1.3 of IEEE 802.1Q [IEEE-802.1Q-2003], a VLAN + ID is used to indicate the traffic from a server, and multiple VLAN + IDs are used to indicate the traffic from the clients (one VLAN ID + per client). In the new IEEE 802.1Q solution, only two VLANs are + used to indicate root/leaf attributes of a frame: one VLAN ID is used + to indicate the frames originated from the roots and another VLAN ID + is used to indicate the frames originated from the leaves. At a leaf + port, the bridge can then filter out all the frames from other leaf + ports based on the VLAN ID. It is better to reuse the same mechanism + in VPLS than to develop a new mechanism. A new mechanism would + introduce more complexity to interwork with the new IEEE 802.1Q + solution. + + This document specifies how the Ethernet VLAN solution can be used to + support generic E-Tree services in VPLS. The solution specified here + is fully compatible with the IEEE bridge architecture and with IETF + + + +Jiang, et al. Standards Track [Page 3] + +RFC 7796 E-Tree Support in VPLS March 2016 + + + Pseudowire Emulation Edge-to-Edge (PWE3) technology, thus it will not + change the FIB (such as installing E-Tree attributes in the FIB) or + need any specially tailored implementation. Furthermore, VPLS + scalability and simplicity are also maintained. With this mechanism, + it is also convenient to deploy a converged E-Tree service across + both Ethernet and MPLS networks. + + A typical VPLS PE model is introduced as an example; the model is + then extended in which a Tree VSI is connected to a VLAN bridge with + a dual-VLAN interface. + + This document then discusses the PW encapsulation and PW processing + such as VLAN mapping options for transporting E-Tree services in + VPLS. + + Finally, this document describes the signaling extensions and + processing procedures for E-Tree support in VPLS. + +2. 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]. + +3. Terminology + + AC: Attachment Circuit + + B-VLAN: Backbone VLAN + + C-VLAN: Customer VLAN + + E-Tree: Ethernet Tree, a Rooted-Multipoint EVC service as defined in + [MEF6.2] + + EVC: Ethernet Virtual Connection, as defined in [MEF4] + + FIB: Forwarding Information Base, also known as "forwarding table" + + I-SID: Backbone Service Instance Identifier, as defined in IEEE + 802.1ah [IEEE-802.1Q-2014] + + Leaf AC: An AC attached with a leaf + + Leaf VLAN: A VLAN Identifier (ID) used to indicate all the frames + that are originated at a leaf AC. It may be a C-VLAN, an S-VLAN, + or a B-VLAN + + + + +Jiang, et al. Standards Track [Page 4] + +RFC 7796 E-Tree Support in VPLS March 2016 + + + OAM: Operations, Administration, and Maintenance + + PBB: Provider Backbone Bridge + + PE: Provider Edge + + PW: Pseudowire + + Root AC: An AC attached with a root + + Root VLAN: A VLAN ID used to indicate all the frames that are + originated at a root AC. It may be a C-VLAN, an S-VLAN, or a + B-VLAN + + S-VLAN: Service VLAN + + T-VSI: Tree VSI, a VSI with E-Tree support + + VLAN: Virtual Local Area Network + + VPLS: Virtual Private LAN Service + + VSI: Virtual Switching Instance as defined in [RFC4664], also known + as "VPLS Forwarder" in [RFC7041] + +4. PE Model with E-Tree Support + + The problem scenario of E-Tree as shown in Figure 1 of [RFC7152] is a + simplification of the L2VPN architecture. Several common VPLS PE + architectures are discussed in more detail in [RFC4664] and + [RFC6246]. + + Below, an E-Tree solution in VPLS is demonstrated with the help of a + typical VPLS PE model. Its use in other PE models is discussed in + Appendix A. + +4.1. Existing PE Models + + According to [RFC4664], there are at least three models possible for + a VPLS PE, including: + + o A single bridge module, a single VSI; + + o A single bridge module, multiple VSIs; + + o Multiple bridge modules, each attaches to a VSI. + + + + + +Jiang, et al. Standards Track [Page 5] + +RFC 7796 E-Tree Support in VPLS March 2016 + + + The second PE model is commonly used. A typical example is further + depicted in Figure 1 and Figure 2 (both figures are extracted from + [RFC6246]), where an S-VLAN bridge module is connected to multiple + VSIs each with a single VLAN virtual interface. + + +-------------------------------+ + | 802.1ad Bridge Module Model | + | | + +---+ AC | +------+ +-----------+ | + |CE |---------|C-VLAN|------| | | + +---+ | |bridge|------| | | + | +------+ | | | + | o | S-VLAN | | + | o | | | ---> to VSI + | o | Bridge | | + +---+ AC | +------+ | | | + |CE |---------|C-VLAN|------| | | + +---+ | |bridge|------| | | + | +------+ +-----------+ | + +-------------------------------+ + + Figure 1: A Model of 802.1ad Bridge Module + + +----------------------------------------+ + | VPLS-Capable PE Model | + | +---------------+ +------+ | + | | | |VSI-1 |------------ + | | |==========| |------------ PWs + | | Bridge ------------ |------------ + | | | S-VLAN-1 +------+ | + | | Module | o | + | | | o | + | | (802.1ad | o | + | | bridge) | o | + | | | o | + | | | S-VLAN-n +------+ | + | | ------------VSI-n |------------- + | | |==========| |------------- PWs + | | | ^ | |------------- + | +---------------+ | +------+ | + | | | + +-------------------------|--------------+ + LAN Emulation Interface + + Figure 2: A VPLS-Capable PE Model + + + + + + +Jiang, et al. Standards Track [Page 6] + +RFC 7796 E-Tree Support in VPLS March 2016 + + + In this PE model, Ethernet frames from Customer Edges (CEs) will + cross multiple stages of bridge modules (i.e., C-VLAN and S-VLAN + bridge), and a VSI in a PE before being sent on the PW to a remote + PE. Therefore, the association between an AC port and a PW on a VSI + is difficult. + + This model could be further enhanced: when Ethernet frames arrive at + an ingress PE, a root VLAN or a leaf VLAN tag is added. At an egress + PE, the frames with the root VLAN tag are transmitted both to the + roots and the leaves, while the frames with the leaf VLAN tag are + transmitted to the roots but dropped for the leaves (these VLAN tags + are removed before the frames are transmitted over the ACs). It was + demonstrated in [IEEE-802.1Q-2014] that the E-Tree service in + Ethernet networks can be well supported with this mechanism. + + Assuming this mechanism is implemented in the bridge module, it is + quite straightforward to infer a VPLS PE model with two VSIs to + support the E-Tree (as shown in Figure 3). But this model will + require two VSIs per PE and two sets of PWs per E-Tree service, which + is poorly scalable in a large MPLS/VPLS network; in addition, both of + these VSIs have to share their learned MAC addresses. + + +----------------------------------------+ + | VPLS-Capable PE Model | + | +---------------+ +------+ | + | | | |VSI-1 |------------ + | | |==========| |------------ PWs + | | Bridge ------------ |------------ + | | | Root +------+ | + | | Module | S-VLAN | + | | | | + | | (802.1ad | | + | | bridge) | | + | | | Leaf | + | | | S-VLAN +------+ | + | | ------------VSI-2 |------------- + | | |==========| |------------- PWs + | | | ^ | |------------- + | +---------------+ | +------+ | + | | | + +-------------------------|--------------+ + LAN Emulation Interface + + Figure 3: A VPLS PE Model for E-Tree with 2VSIs + + + + + + + +Jiang, et al. Standards Track [Page 7] + +RFC 7796 E-Tree Support in VPLS March 2016 + + +4.2. A New PE Model with E-Tree Support + + In order to support the E-Tree in a more scalable way, a new VPLS PE + model with a single Tree VSI (T-VSI, a VSI with E-Tree support) is + specified. As depicted in Figure 4, the bridge module is connected + to the T-VSI with a dual-VLAN virtual interface, i.e., both the root + VLAN and the leaf VLAN are connected to the same T-VSI, and they + share the same FIB and work in shared VLAN learning. In this way, + only one VPLS instance and one set of PWs is needed per E-Tree + service, and the scalability of VPLS is improved. + + +----------------------------------------+ + | VPLS-Capable PE Model | + | +---------------+ +------+ | + | | |==========|TVSI-1|------------ + +---+ AC | | ------------ |------------ PWs + |CE |--------| Bridge ------------ |------------ + +---+ | | | Root & +------+ | + | | Module | Leaf VLAN o | + | | | o | + | | | o | + | | | o | + | | | o | + +---+ AC | | | VLAN-n +------+ | + |CE |--------| ------------VSI-n |------------- + +---+ | | |==========| |------------- PWs + | | | ^ | |------------- + | +---------------+ | +------+ | + | | | + +-------------------------|--------------+ + LAN Emulation Interface + + Figure 4: A VPLS PE Model for E-Tree with a Single T-VSI + + For an untagged AC port (frames over this port are untagged) or a + VLAN unaware port (VLAN tags in the frames are ignored), where the + bridge module is a C-VLAN bridge, the Ethernet frames received from + the root ACs MUST be tagged with a root C-VLAN. When the bridge + module is an 802.1ad bridge [IEEE-802.1Q-2014], the Ethernet frames + received from the root ACs MUST be tagged with a root S-VLAN. Note, + this can be done by adding a root C-VLAN first in a C-VLAN bridge, + but this is out of the scope of this document. + + For a C-VLAN tagged port, the Ethernet frames received from the root + ACs MUST be tagged with a root S-VLAN. + + + + + + +Jiang, et al. Standards Track [Page 8] + +RFC 7796 E-Tree Support in VPLS March 2016 + + + For an S-VLAN tagged port, the S-VLAN tag in the Ethernet frames + received from the root ACs SHOULD be translated to the root S-VLAN in + the VPLS network domain. + + Alternatively, for an S-VLAN tagged port, the PBB VPLS PE model + (where an IEEE 802.1ah bridge module is embedded in the PE) as + described in [RFC7041] MAY be used. A root B-VLAN or a leaf B-VLAN + MAY be added. The E-Tree attribute may also be indicated with two + I-SID tags in the bridge module, and the frames are then encapsulated + and transported transparently over a single B-VLAN. Thus, the PBB + VPLS works in the same way as described in [RFC7041] and will not be + discussed further in this document. When many S-VLANs are + multiplexed in a single AC, PBB VPLS has the advantages of both VLAN + scalability and MAC address scalability. + + In a similar way, the traffic from the leaf ACs is tagged and + transported on the leaf C-VLAN, S-VLAN, or B-VLAN. + + In all cases, the outermost VLAN in the resulting Ethernet header is + used to indicate the E-Tree attribute of an Ethernet frame; this + document uses VLAN to refer to this outermost VLAN for simplicity in + the latter sections. + +5. PW for E-Tree Support + +5.1. PW Encapsulation + + To support an E-Tree service, T-VSIs in a VPLS MUST be interconnected + with a bidirectional Ethernet PW. The Ethernet PW SHOULD work in the + tagged mode (PW type 0x0004) as described in [RFC4448], in which case + a VLAN tag MUST be carried in each frame in the PW to indicate the + frame originated from either root or leaf (the VLAN tag indicating + the frame originated from either root or leaf can be translated by a + bridge module in the PE or added by an outside Ethernet edge device, + even by a customer device). In the tagged PW mode, two service- + delimiting VLANs MUST be allocated in the VPLS domain for an E-Tree. + PW processing for the tagged PW will be described in Section 5.3 of + this document. + + A raw mode PW (PW type 0x0005 in [RFC4448]) MAY also be used to carry + an E-Tree service for a PW in Compatible mode as shown in + Section 5.3.2. As defined in [RFC4448], for a raw mode PW, an + Ethernet frame's 802.1Q VLAN tag is not meaningful to the PEs and it + passes transparently through them. + + + + + + + +Jiang, et al. Standards Track [Page 9] + +RFC 7796 E-Tree Support in VPLS March 2016 + + +5.2. VLAN Mapping + + There are two ways of manipulating VLANs for an E-Tree in VPLS: + + o Global VLAN based, that is, provisioning two global VLANs (Root + VLAN and Leaf VLAN) across the VPLS network, thus no VLAN mapping + is needed at all, or the VLAN mapping is done completely in the + Ethernet domains. + + o Local VLAN based, that is, provisioning two local VLANs for each + PE (that participates in the E-Tree) in the VPLS network + independently. + + The first method requires no VLAN mapping in the PW, but two unique + service-delimiting VLANs must be allocated across the VPLS domain. + + The second method is more scalable in the use of VLANs, but needs a + VLAN mapping mechanism in the PW similar to what is already described + in Section 4.3 of [RFC4448]. + + Global or local VLANs can be manually configured or provisioned by an + Operational Support System. Alternatively, some automatic VLAN + allocation algorithm may be provided in the management plane, but it + is out of scope of this document. + + For both methods, VLAN mapping parameters from a remote PE can be + provisioned or determined by a signaling protocol as described in + Section 6 when a PW is being established. + + + + + + + + + + + + + + + + + + + + + + + +Jiang, et al. Standards Track [Page 10] + +RFC 7796 E-Tree Support in VPLS March 2016 + + +5.3. PW Processing + +5.3.1. PW Processing in the VLAN Mapping Mode + + In the VLAN mapping mode, two VPLS PEs with E-Tree capability are + inter-connected with a PW (for example, the scenario of Figure 5 + depicts the interconnection of two PEs attached with both root and + leaf nodes). + + +----------------------------+ + | VPLS PE with T-VSI | + | | + +----+ | +------+ Root VLAN +-----+ | PW + |Root|------| VLAN |-----------|T-VSI|---------- + +----+ | | BRG | Leaf VLAN | |---------- + +----+ | | |-----------| |---------- + |Leaf|------| | | |-----+ + +----+ | +------+ +-----+ | | + | | | + +----------------------------+ | + | + +----------------------------+ | + | VPLS PE with T-VSI | | + | | | + +----+ | +------+ Root VLAN +-----+ | | PW + |Root|------| VLAN |-----------|T-VSI|-----+ + +----+ | | BRG | Leaf VLAN | |---------- + +----+ | | |-----------| |---------- + |Leaf|------| | | |---------- + +----+ | +------+ +-----+ | + | | BRG: Bridge Module + +----------------------------+ + + Figure 5: T-VSI Interconnected in the Normal Mode + + If a PE is in the VLAN mapping mode for a PW, then in the data plane, + the PE MUST map the VLAN in each frame as follows: + + o Upon transmitting frames on the PW, map from the local VLAN to the + remote VLAN (i.e., the local leaf VLAN in a frame is translated to + the remote leaf VLAN; the local root VLAN in a frame is translated + to the remote root VLAN). + + o Upon receiving frames on the PW, map from the remote VLAN to the + local VLAN, and the frames are further forwarded or dropped in the + egress bridge module using the filtering mechanism as described in + [IEEE-802.1Q-2014]. + + + + +Jiang, et al. Standards Track [Page 11] + +RFC 7796 E-Tree Support in VPLS March 2016 + + + The signaling for VLANs used by E-Tree is specified in Section 6. + +5.3.2. PW Processing in the Compatible Mode + + The new VPLS PE model can work in a traditional VPLS network + seamlessly in the compatibility mode. As shown in Figure 6, the VPLS + PE with T-VSI can be attached with root and/or leaf nodes, while the + VPLS PE with a traditional VSI can only be attached with root nodes. + A raw PW SHOULD be used to connect them. + + +------------------------+ + | VPLS PE with T-VSI | + | | + +----+ | +------+ +-----+ | PW + |Root|------| VLAN |-------|T-VSI|---------- + +----+ | | BRG | | |---------- + +----+ | | |-------| |---------- + |Leaf|------| | | |---------+ + +----+ | +------+ +-----+ | | + | | | + +------------------------+ | + | + +------------------------+ | + | VPLS PE with VSI | | + | | | + +----+ | +------+ +-----+ | PW | + |Root|------| VLAN |-------|VSI |---------+ + +----+ | | BRG | | |---------- + +----+ | | | | |---------- + |Root|------| | | |---------- + +----+ | +------+ +-----+ | + | | + +------------------------+ + + Figure 6: T-VSI Interconnected with Traditional VSI + + If a PE is in the Compatible mode for a PW, then in the data plane, + the PE MUST process the frame as follows: + + o Upon transmitting frames on the PW, remove the root or leaf VLAN + in the frames. + + o Upon receiving frames on the PW, add a VLAN tag with a value of + the local root VLAN to the frames. + + + + + + + +Jiang, et al. Standards Track [Page 12] + +RFC 7796 E-Tree Support in VPLS March 2016 + + +5.3.3. PW Processing in the Optimized Mode + + When two PEs (both with E-Tree capability) are inter-connected with a + PW and one of them (e.g., PE2) is attached with only leaf nodes, as + shown in the scenario of Figure 7, its peer PE (e.g., PE1) should + then work in the Optimized mode for this PW. In this case, PE1 + should not send the frames originated from the local leaf VLAN to + PE2, i.e., these frames are dropped rather than transported over the + PW. The bandwidth efficiency of the VPLS can thus be improved. The + signaling for the PE attached with only leaf nodes is specified in + Section 6. + + +------------------------+ + |VPLS PE with T-VSI (PE1)| + | | + +----+ | +------+ +-----+ | PW + |Root|------| VLAN |-------|T-VSI|---------- + +----+ | | BRG | | |---------- + +----+ | | |-------| |---------- + |Leaf|------| | | |---------+ + +----+ | +------+ +-----+ | | + | | | + +------------------------+ | + | + +------------------------+ | + |VPLS PE with T-VSI (PE2)| | + | | | + +----+ | +------+ +-----+ | PW | + |Leaf|------| VLAN |-------|T-VSI|---------+ + +----+ | | BRG | | |---------- + +----+ | | |-------| |---------- + |Leaf|------| | | |---------- + +----+ | +------+ +-----+ | + | | + +------------------------+ + + Figure 7: T-VSI Interconnected with PE Attached with Only Leaf Nodes + + If a PE is in the Optimized Mode for a PW, upon transmit, the PE + SHOULD drop a frame if its VLAN ID matches the local leaf VLAN ID. + + + + + + + + + + + +Jiang, et al. Standards Track [Page 13] + +RFC 7796 E-Tree Support in VPLS March 2016 + + +6. Signaling for E-Tree Support + +6.1. LDP Extensions for E-Tree Support + + In addition to the signaling procedures as specified in Section 5.3.3 + of [RFC4447], this document specifies a new interface parameter sub- + TLV to provision an E-Tree service and negotiate the VLAN mapping + function, as follows: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | E-Tree(0x1A) | Length=8 | Reserved |P|V| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MBZ | Root VLAN ID | MBZ | Leaf VLAN ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 8: E-Tree Sub-TLV + + Where: + + o E-Tree is the sub-TLV identifier (0x1A) as assigned by IANA. + + o Length is the length of the sub-TLV in octets. + + o Reserved, bits MUST be set to zero on transmit and be ignored on + receive. + + o P is a leaf-only bit, it is set to 1 to indicate that the PE is + attached with only leaf nodes, and set to 0 otherwise. + + o V is a bit indicating the sender's VLAN mapping capability. A PE + capable of VLAN mapping MUST set this bit, and clear it otherwise. + + o Must Be Zero (MBZ), 4 bits MUST be set to zero on transmit and be + ignored on receive. + + o Root VLAN ID is the value of the local root VLAN. + + o Leaf VLAN ID is the value of the local leaf VLAN. + + When setting up a PW for the E-Tree based VPLS, two peer PEs + negotiate the E-Tree support using the above E-Tree sub-TLV. Note + that the PW type of 0x0004 SHOULD be used during the PW negotiation. + + A PE that wishes to support an E-Tree service MUST include an E-Tree + sub-TLV in its PW Label Mapping message and include its local root + VLAN ID and leaf VLAN ID in the TLV. A PE that has the VLAN mapping + + + +Jiang, et al. Standards Track [Page 14] + +RFC 7796 E-Tree Support in VPLS March 2016 + + + capability MUST set the V bit to 1, and a PE attached with only leaf + nodes SHOULD set the P bit to 1. + + A PE that receives a PW Label Mapping message with an E-Tree sub-TLV + from its peer PE, after saving the VLAN information for the PW, MUST + process it as follows: + + 1) For this PW, set VLAN-Mapping-Mode, Compatible-Mode, and + Optimized-Mode to FALSE. + + 2) If either the root VLAN ID in the message is not equal to the + local root VLAN ID, or the leaf VLAN ID in the message is not + equal to the local leaf VLAN ID { + + If the bit V is cleared { + + If the PE is capable of VLAN mapping, it MUST set + VLAN-Mapping-Mode to TRUE; + + Else { + + A Label Release message with the error code "E- + Tree VLAN mapping not supported" is sent to the + peer PE and exit the process; + + } + + } + + If the bit V is set, and the PE is capable of VLAN mapping, + the PE with the minimum IP address MUST set + VLAN-Mapping-Mode to TRUE; + + } + + 3) If the P bit is set + + { + + If the PE is a leaf-only node itself, a Label Release + message with a status code "Leaf-to-Leaf PW released" is + sent to the peer PE and exits the process; + + Else the PE SHOULD set the Optimized-Mode to TRUE. + + } + + + + + +Jiang, et al. Standards Track [Page 15] + +RFC 7796 E-Tree Support in VPLS March 2016 + + + A PE SHOULD send a Label Mapping message with an E-Tree sub-TLV as + per Section 5.3.3 of [RFC4447]. A PE MUST send a Label Mapping + message with an updated E-Tree sub-TLV to all other PEs over + corresponding LDP sessions when its role changes from leaf-only to + not leaf-only (i.e., when a root node is added to a PE attached with + only leaf nodes). + + If a PE has sent a Label Mapping message with an E-Tree sub-TLV but + does not receive any E-Tree sub-TLV in its peer's PW Label Mapping + message, the PE SHOULD then establish a raw PW with this peer as in + traditional VPLS and set Compatible-Mode to TRUE for this PW. + + Data plane processing for this PW is as follows: + + o If Optimized-Mode is TRUE, then data plane processing as described + in Section 5.3.3 applies. + + o If VLAN-Mapping-Mode is TRUE, then data plane processing as + described in Section 5.3.1 applies. + + o If Compatible-Mode is TRUE, then data plane processing as + described in Section 5.3.2 applies. + + o PW processing as described in [RFC4448] proceeds as usual for all + cases. + + When VPLS is set up using the Pseudowire ID (PWid) Forwarding + Equivalence Class (FEC) Element (see Appendix A of [RFC4762]), its + E-Tree signaling is similar to the above process. Dynamic + re-configuration of E-Tree should be avoided for this case. However, + when re-configuration of E-Tree is forced on a PE for some reason + (e.g., a configuration error), the PE may close the LDP sessions with + its peer PEs for this VPLS instance and re-install its PW labels, so + that its peer PEs can send out the LDP Label Mapping messages again. + + + + + + + + + + + + + + + + + +Jiang, et al. Standards Track [Page 16] + +RFC 7796 E-Tree Support in VPLS March 2016 + + +6.2. BGP Extensions for E-Tree Support + + A new E-Tree extended community (0x800b) has been allocated by IANA + for E-Tree signaling in BGP VPLS: + + +------------------------------------+ + | Extended community type (2 octets) | + +------------------------------------+ + | MBZ | Root VLAN (12 bits) | + +------------------------------------+ + | MBZ | Leaf VLAN (12 bits) | + +------------------------------------+ + | Reserved |P|V| + +------------------------------------+ + + Figure 9: E-Tree Extended Community + + Where: + + o Must Be Zero (MBZ), 4 bits MUST be set to zero on transmit and be + ignored on receive. + + o Root VLAN ID is the value of the local root VLAN. + + o Leaf VLAN ID is the value of the local leaf VLAN. + + o Reserved, 14 bits MUST be set to zero on transmit and be ignored + on receive. + + o P is a leaf-only bit, it is set to 1 to indicate that the PE is + attached with only leaf nodes, and set to 0 otherwise. + + o V is a bit indicating the sender's VLAN mapping capability. A PE + capable of VLAN mapping MUST set this bit, and clear it otherwise. + + The PEs attached with both leaf and root nodes MUST support BGP + E-Tree signaling as described in this document, and SHOULD support + VLAN mapping in their data planes. The traditional PE attached with + only root nodes may also participate in an E-Tree service. If some + PEs don't support VLAN mapping, global VLANs as per Section 5.2 MUST + be provisioned for an E-Tree service. + + In BGP VPLS signaling, besides attaching a Layer2 Info Extended + Community as detailed in [RFC4761], an E-Tree Extended Community MUST + be further attached if a PE wishes to participate in an E-Tree + service. The PE MUST include its local root VLAN ID and leaf VLAN ID + + + + + +Jiang, et al. Standards Track [Page 17] + +RFC 7796 E-Tree Support in VPLS March 2016 + + + in the E-Tree Extended Community. A PE attached with only leaf nodes + of an E-Tree SHOULD set the P bit in the E-Tree Extended Community to + 1. + + A PE that receives a BGP UPDATE message with an E-Tree Extended + Community from its peer PE, after saving the VLAN information for the + PW, MUST process it as follows (after processing procedures as + specified in Section 3.2 of [RFC4761]): + + 1) For this PW, set VLAN-Mapping-Mode, Compatible-Mode, and + Optimized-Mode to FALSE. + + 2) If either the root VLAN ID in the E-Tree Extended Community is + not equal to the local root VLAN ID, or the leaf VLAN ID in the + E-Tree Extended Community is not equal to the local leaf VLAN ID { + + If the bit V is cleared { + + If the PE is capable of VLAN mapping, it MUST set VLAN- + Mapping-Mode to TRUE; + + Else { + + Log with a message "E-Tree VLAN mapping not + supported" and exit the process; + + } + + } + + If the bit V is set, and the PE is capable of VLAN mapping, + the PE with the minimum IP address MUST set VLAN-Mapping-Mode + to TRUE; + + } + + 3) If the P bit is set { + + If the PE is a leaf-only PE itself, forbids any traffic on the + PW; + + Else the PE SHOULD set the Optimized-Mode to TRUE. + + } + + A PE that does not recognize this attribute SHALL ignore it silently. + If a PE has sent an E-Tree Extended Community but does not receive + any E-Tree Extended Community from its peer, the PE SHOULD then + + + +Jiang, et al. Standards Track [Page 18] + +RFC 7796 E-Tree Support in VPLS March 2016 + + + establish a raw PW with this peer as in traditional VPLS and set + Compatible-Mode to TRUE for this PW. + + The data plane in the VPLS is the same as described in Section 4.2 of + [RFC4761], and data plane processing for a PW is the same as + described at the end of Section 6.1 in this document. + +7. OAM Considerations + + The VPLS OAM requirements and framework as specified in [RFC6136] are + applicable to E-Tree, as both Ethernet OAM frames and data traffic + are transported over the same PW. + + Ethernet OAM for E-Tree including both service OAM and segment OAM + frames SHALL undergo the same VLAN mapping as the data traffic; and + root VLAN SHOULD be applied to segment OAM frames so that they are + not filtered. + +8. Applicability + + The solution specified in this document is applicable to both LDP + VPLS [RFC4762] and BGP VPLS [RFC4761]. + + This solution is applicable to both "VPLS Only" networks and VPLS + with Ethernet aggregation networks. + + This solution is also applicable to PBB VPLS networks. + +9. IANA Considerations + + IANA allocated the following value for E-Tree in the "Pseudowire + Interface Parameters Sub-TLV type Registry". + + Parameter ID Length Description + ======================================= + 0x1A 8 E-Tree + + IANA allocated the two following new LDP status codes in the "Status + Code Name Space" registry. + + Range/Value E Description + ------------- ----- ---------------------- + 0x20000003 1 E-Tree VLAN mapping not supported + 0x20000004 0 Leaf-to-Leaf PW released + + + + + + + +Jiang, et al. Standards Track [Page 19] + +RFC 7796 E-Tree Support in VPLS March 2016 + + + IANA allocated the following value for E-tree in the "Generic + Transitive Experimental Use Extended Community Sub-Types" registry + within the BGP Extended Community registry. + + Type Value Sub-Type Value Name + ========== ============== ============ + 0x80 0x0b E-Tree Info + +10. Security Considerations + + This solution requires implementations to prevent leaf-to-leaf + communication in the data plane of VPLS when its PEs are + interconnected with PWs. If all PEs enforce that, then network + attacks from one leaf to another leaf are avoided, and security can + be enhanced for customers with this solution. However, if a PE is + compromised or inappropriately configured, a leaf node may be taken + as a root node and may receive traffic from other leaf nodes + inappropriately. Authenticity and integrity measures for LDP need to + be considered as in RFC 5036 [RFC5036]. Security considerations as + described in [RFC4448], [RFC4761], and [RFC4762] also apply. + +11. References + +11.1. Normative References + + [IEEE-802.1Q-2014] + IEEE, "Bridges and Bridged Networks", IEEE 802.1Q, + DOI 10.1109/ieeestd.2014.6991462, November 2014. + + [MEF6.2] Metro Ethernet Forum 6.2, "EVC Ethernet Services + Definitions Phase 3", August 2014. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and + G. Heron, "Pseudowire Setup and Maintenance Using the + Label Distribution Protocol (LDP)", RFC 4447, + DOI 10.17487/RFC4447, April 2006, + <http://www.rfc-editor.org/info/rfc4447>. + + [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, + "Encapsulation Methods for Transport of Ethernet over MPLS + Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, + <http://www.rfc-editor.org/info/rfc4448>. + + + + +Jiang, et al. Standards Track [Page 20] + +RFC 7796 E-Tree Support in VPLS March 2016 + + + [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private + LAN Service (VPLS) Using BGP for Auto-Discovery and + Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, + <http://www.rfc-editor.org/info/rfc4761>. + + [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private + LAN Service (VPLS) Using Label Distribution Protocol (LDP) + Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, + <http://www.rfc-editor.org/info/rfc4762>. + + [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., + "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, + October 2007, <http://www.rfc-editor.org/info/rfc5036>. + +11.2. Informative References + + [IEEE-802.1Q-2003] + IEEE, "Virtual Bridged Local Area Networks", IEEE 802.1, + DOI 10.1109/IEEESTD.2003.94280, May 2003. + + [MEF4] Metro Ethernet Forum 4, "Metro Ethernet Network + Architecture Framework - Part 1: Generic Framework", May + 2004. + + [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation + Edge-to-Edge (PWE3) Architecture", RFC 3985, + DOI 10.17487/RFC3985, March 2005, + <http://www.rfc-editor.org/info/rfc3985>. + + [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer + 2 Virtual Private Networks (L2VPNs)", RFC 4664, + DOI 10.17487/RFC4664, September 2006, + <http://www.rfc-editor.org/info/rfc4664>. + + [RFC6136] Sajassi, A., Ed. and D. Mohan, Ed., "Layer 2 Virtual + Private Network (L2VPN) Operations, Administration, and + Maintenance (OAM) Requirements and Framework", RFC 6136, + DOI 10.17487/RFC6136, March 2011, + <http://www.rfc-editor.org/info/rfc6136>. + + [RFC6246] Sajassi, A., Ed., Brockners, F., Mohan, D., Ed., and Y. + Serbest, "Virtual Private LAN Service (VPLS) + Interoperability with Customer Edge (CE) Bridges", + RFC 6246, DOI 10.17487/RFC6246, June 2011, + <http://www.rfc-editor.org/info/rfc6246>. + + + + + + +Jiang, et al. Standards Track [Page 21] + +RFC 7796 E-Tree Support in VPLS March 2016 + + + [RFC7041] Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed., + "Extensions to the Virtual Private LAN Service (VPLS) + Provider Edge (PE) Model for Provider Backbone Bridging", + RFC 7041, DOI 10.17487/RFC7041, November 2013, + <http://www.rfc-editor.org/info/rfc7041>. + + [RFC7152] Key, R., Ed., DeLord, S., Jounay, F., Huang, L., Liu, Z., + and M. Paul, "Requirements for Metro Ethernet Forum (MEF) + Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private + Network (L2VPN)", RFC 7152, DOI 10.17487/RFC7152, March + 2014, <http://www.rfc-editor.org/info/rfc7152>. + + [RFC7387] Key, R., Ed., Yong, L., Ed., Delord, S., Jounay, F., and + L. Jin, "A Framework for Ethernet Tree (E-Tree) Service + over a Multiprotocol Label Switching (MPLS) Network", + RFC 7387, DOI 10.17487/RFC7387, October 2014, + <http://www.rfc-editor.org/info/rfc7387>. + + [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, + draft-ietf-l2vpn-vpms-frmwk-requirements-05, October 2012. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jiang, et al. Standards Track [Page 22] + +RFC 7796 E-Tree Support in VPLS March 2016 + + +Appendix A. Other PE Models for E-Tree + +A.1. A PE Model with a VSI and No Bridge + + If there is no bridge module in a PE, the PE may consist of Native + Service Processors (NSPs) as shown in Figure 10 (adapted from + Figure 5 of [RFC3985]) where any transformation operation for VLANs + (e.g., VLAN insertion/removal or VLAN mapping) may be applied. Thus, + a root VLAN or leaf VLAN can be added by the NSP depending on the + User Network Interface (UNI) type (root/leaf) associated with the AC + over which the packet arrives. + + Further, when a packet with a leaf VLAN exits a forwarder and arrives + at the NSP, the NSP must drop the packet if the egress AC is + associated with a leaf UNI. + + Tagged PW and VLAN mapping work in the same way as in the typical PE + model. + + +----------------------------------------+ + | PE Device | + Multiple+----------------------------------------+ + AC | | | Single | PW Instance + <------>o NSP # + PW Instance X<----------> + | | | | + |------| VSI |----------------------| + | | | Single | PW Instance + <------>o NSP #Forwarder + PW Instance X<----------> + | | | | + |------| |----------------------| + | | | Single | PW Instance + <------>o NSP # + PW Instance X<----------> + | | | | + +----------------------------------------+ + + Figure 10: A PE Model with a VSI and No Bridge Module + + This PE model may be used by a Multi-Tenant Unit switch (MTU-s) in a + Hierarchical VPLS (H-VPLS) network or a Network-facing PE (N-PE) in + an H-VPLS network with non-bridging edge devices, wherein a spoke PW + can be treated as an AC in this model. + + + + + + + + + + +Jiang, et al. Standards Track [Page 23] + +RFC 7796 E-Tree Support in VPLS March 2016 + + +A.2. A PE Model with External E-Tree Interface + + +----------------------------------------+ + | PE Device | + Root +----------------------------------------+ + VLAN | | Single | PW Instance + <------>o + PW Instance X<----------> + | | | + | VSI |----------------------| + | | Single | PW Instance + | Forwarder + PW Instance X<----------> + | | | + Leaf | |----------------------| + VLAN | | Single | PW Instance + <------>o + PW Instance X<----------> + | | | + +----------------------------------------+ + + Figure 11: A PE Model with External E-Tree Interface + + A more simplified PE model is depicted in A.2, where Root/Leaf VLANs + are directly or indirectly connected over a single PW to the same VSI + forwarder in a PE, any transformation of E-Tree VLANs, e.g., VLAN + insertion/removal or VLAN mapping, can be performed by some outer + equipment, and the PE may further translate these VLANs into its own + local VLANs. This PE model may be used by an N-PE in an H-VPLS + network with bridging-capable devices, or scenarios such as providing + E-Tree Network-to-Network interfaces. + + + + + + + + + + + + + + + + + + + + + + + +Jiang, et al. Standards Track [Page 24] + +RFC 7796 E-Tree Support in VPLS March 2016 + + +Acknowledgements + + The authors would like to thank Stewart Bryant, Lizhong Jin, Deborah + Brungard, Russ Housley, Stephen Farrell, Sheng Jiang, Alvaro Retana, + and Ben Campbell for their detailed reviews and suggestions, and + Adrian Farrel, Susan Hares, Shane Amante, and Andrew Malis for their + valuable advice. In addition, the authors would like to thank Ben + Mack-crane, Edwin Mallette, Donald Fedyk, Dave Allan, Giles Heron, + Raymond Key, Josh Rogers, Sam Cao, and Daniel Cohn for their valuable + comments and discussions. + +Contributors + + The following people made significant contributions to this document: + + Frederic Jounay + Salt Mobile SA + Rue du Caudray 4 + 1020 Renens + Switzerland + + Email: frederic.jounay@salt.ch + + Florin Balus + Alcatel-Lucent + 701 East Middlefield Road + Mountain View, CA 94043 + United States + + Email: florin.balus@alcatel-lucent.com + + Wim Henderickx + Alcatel-Lucent + Copernicuslaan 50 + 2018 Antwerp + Belgium + + Email: wim.henderickx@alcatel-lucent.com + + Ali Sajassi + Cisco + 170 West Tasman Drive + San Jose, CA 95134 + United States + + Email: sajassi@cisco.com + + + + + +Jiang, et al. Standards Track [Page 25] + +RFC 7796 E-Tree Support in VPLS March 2016 + + +Authors' Addresses + + Yuanlong Jiang (editor) + Huawei + Bantian, Longgang district + Shenzhen 518129 + China + + Email: jiangyuanlong@huawei.com + + + Lucy Yong + Huawei + 207 Estrella Xing + Georgetown, TX 78628 + United States + + Email: lucyyong@huawei.com + + + Manuel Paul + Deutsche Telekom + Winterfeldtstrasse 21 + Berlin 10781 + Germany + + Email: manuel.paul@telekom.de + + + + + + + + + + + + + + + + + + + + + + + + +Jiang, et al. Standards Track [Page 26] + |