GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc7796

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7796.txt · Last modified: 2016/03/16 22:48 (external edit)