Skip to main content

Usecases of MPLS Global Label
draft-li-mpls-global-label-usecases-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Zhenbin Li , Quintin Zhao , Tianle Yang
Last updated 2014-02-13
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-li-mpls-global-label-usecases-01
Network Working Group                                              Z. Li
Internet-Draft                                                   Q. Zhao
Intended status: Informational                       Huawei Technologies
Expires: August 18, 2014                                         T. Yang
                                                            China Mobile
                                                       February 14, 2014

                     Usecases of MPLS Global Label
                 draft-li-mpls-global-label-usecases-01

Abstract

   As the SDN(Service-Driven Network) technology develops, MPLS global
   label has been proposed again for new solutions.  The document
   proposes possible usecases of MPLS global label.  MPLS global label
   can be used for identification of the location, the service and the
   network in different application scenarios.  From these usecases we
   can see that no matter SDN or traditional application scenarios, the
   new solutions based on MPLS global label can gain advantage over the
   existing solutions to facilitate service provisions.

Requirements Language

   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 RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 18, 2014.

Li, et al.               Expires August 18, 2014                [Page 1]
Internet-Draft        Usecases of MPLS Global Label        February 2014

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Usecases  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Identification of Location  . . . . . . . . . . . . . . .   4
       3.1.1.  VPLS Multicast over MP2MP LSP . . . . . . . . . . . .   4
       3.1.2.  Segment-Based EVPN  . . . . . . . . . . . . . . . . .   4
       3.1.3.  MPLS OAM for LDP LSP  . . . . . . . . . . . . . . . .   5
     3.2.  Identification of Services  . . . . . . . . . . . . . . .   5
       3.2.1.  Identification of MVPN/VPLS . . . . . . . . . . . . .   5
       3.2.2.  Local Protection of PE Node . . . . . . . . . . . . .   6
       3.2.3.  Service Chaining  . . . . . . . . . . . . . . . . . .   6
     3.3.  Identification of Network . . . . . . . . . . . . . . . .   6
       3.3.1.  Segment Routing . . . . . . . . . . . . . . . . . . .   7
       3.3.2.  MPLS Network Virtualization . . . . . . . . . . . . .   7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Currently MPLS label only has local meaning.  That is, MPLS label is
   always allocated by the downstream node to the upstream node.  Then
   the MPLS label is only identified by the neighboring upstream node
   and downstream node.  MPLS global label has ever been proposed which
   has the global meaning in the MPLS domain.  That is, MPLS global
   label should be identified by all nodes in the MPLS domain for the
   same meaning.  Since for a long time current MPLS label mechanism is
   suitable for the distributed network model and can satisfy the

Li, et al.               Expires August 18, 2014                [Page 2]
Internet-Draft        Usecases of MPLS Global Label        February 2014

   possible requirements, there is not much motivation to introduce the
   MPLS global label mechanism.  As the SDN concept is introduced, the
   MPLS global label mechanism are proposed again for new solution such
   as Segment Routing ([I-D.previdi-filsfils-isis-segment-routing]).
   This document proposes possible usecases for MPLS global label which
   can be used for identification of the location, the service and the
   network in different application scenarios.  From these usecases we
   can see that no matter SDN or traditional application scenarios, the
   new solutions based on MPLS global label can gain advantage over the
   existing solutions to facilitate service provisions.

2.  Terminology

   BUM: Broadcast, Unknown unicast, or Multicast

   B-MAC: Backbone MAC Address

   CE: Customer Edge

   C-MAC: Customer/Client MAC Address

   ES: Ethernet Segment

   EVPN: Ethernet VPN

   ICCP: Inter-chassis Communication Protocol

   MP2MP: Multi-Point to Multi-Point

   MP2P: Multi-Point to Point

   MVPN: Multicast VPN

   PBB: Provider Backbone Bridge

   P2MP: Point to Multi-Point

   P2P: Point to Point

   PE: Provider Edge

   S-EVPN: Segment-based EVPN

3.  Usecases

Li, et al.               Expires August 18, 2014                [Page 3]
Internet-Draft        Usecases of MPLS Global Label        February 2014

3.1.  Identification of Location

3.1.1.  VPLS Multicast over MP2MP LSP

   [I-D.ietf-l2vpn-vpls-mcast] defines the VPLS multicast mechanism only
   based on P2MP LSPs.  In this case BUM (Broadcast, Unknown unicast, or
   Multicast) traffic must be transported uniformly through P2MP LSPs.
   If MP2MP LSP is introduced to transport BUM traffic, there exists
   issue for unknown unicast traffic.  VPLS needs to learn MAC address
   through broadcast or multicast of unknown unicast traffic.  PEs of a
   specific VSI can learn the source PE of the MAC address according to
   the P2MP LSP which transports the unknown unicast traffic.  If
   unknown unicast traffic is transported by the MP2MP LSP, the MAC can
   be learned, but the source PE for the MAC cannot be determined since
   there is no determined root node for the MP2MP LSP.  So if the MP2MP
   LSP is used it has to separate the BUM traffic into two parts: the
   broadcast and multicast traffic can be transported by the MP2MP LSP;
   the unknown unicast traffic has to be transported by the P2MP LSP or
   P2P PW.  The process is complex and hard to be provisioned.  MPLS
   global label can be introduced as the identification of the source PE
   and the binding between the MPLS global label and the PE is
   advertised to all PEs.  When the unknown unicast traffic is sent by
   the source PE, the MPLS global label for the identification of the PE
   could be encapsulated firstly.  Thus even if the MP2MP LSP is used,
   the remote PEs can learn the source PE for the learned MAC address
   based on the received MPLS global label.

3.1.2.  Segment-Based EVPN

   [I-D.li-l2vpn-segment-evpn] proposes an enhanced EVPN mechanism,
   segment-based EVPN (S-EVPN).  It introduces a new solution based on
   MPLS global label to satisfy the requirements of PBB-EVPN
   ([I-D.ietf-l2vpn-pbb-evpn]) without the necessity of implementing PBB
   functionality on PE.  PBB-EVPN [I-D.ietf-l2vpn-pbb-evpn] adopts B-MAC
   to implement C-MACs summarization and PEs in PBB-EVPN can determine
   the source PE through B-MAC in the PBB encapsulation for C-MACs which
   are learned in the data plane.  S-EVPN introduces MPLS global label
   for each Ethernet Segment (ES) in an EVPN.  It inserts the source ES
   label into packets at ingress PE and learns C-MAC and source ES label
   binding at egress PE.  Through the source ES label the egress PE can
   determine the source Ethernet Segment and corresponding source PE for
   the learned C-MAC.  Owing to the MPLS global label the S-EVPN
   solution can adopt the unified MPLS method to satisfy the
   requirements of PBB-EVPN.  It makes the implementation easier and
   closer to EVPN( [I-D.ietf-l2vpn-evpn]).

Li, et al.               Expires August 18, 2014                [Page 4]
Internet-Draft        Usecases of MPLS Global Label        February 2014

3.1.3.  MPLS OAM for LDP LSP

   MPLS OAM mechanism has been defined for MPLS TE and MPLS-TP.  MPLS TE
   or MPLS-TP LSP adopts the point-to-point model which is easy to count
   the number of received packets for the specific LSP based on the MPLS
   label in the encapsulation if packet loss rate need to be calculated
   for Performance Monitoring.  As the network convergence develops,
   MPLS LDP network needs to interwork with MPLS TE/MPLS-TP network and
   unified MPLS OAM becomes the realistic requirement.  Owing to the
   MP2P(Multi-Point to Point) or MP2MP model of MPLS LDP LSP, it is
   difficult for MPLS LDP to implement Performance Monitoring since it
   cannot count the number of the received packets based on the MPLS
   label in the encapsulation for a specific flow between two PEs.  MPLS
   global label can be introduced to be used as the source label (Refer
   to [I-D.chen-mpls-source-label]) to identify the source PE and it can
   be encapsulated for the traffic transported by MPLS LDP LSP.  Thus
   even if the outlayer MPLS LDP label is the same for flows from
   different PEs, the egress PE can differentiate flows from specific
   ingress PEs based on the encapsulated MPLS global label for
   Performance Monitoring.

3.2.  Identification of Services

3.2.1.  Identification of MVPN/VPLS

   In BGP-base Multicast VPN ( [RFC6513]) and VPLS Multicast(
   [I-D.ietf-l2vpn-vpls-mcast]), in order to implement aggregating
   multiple MVPNs or VPLS on a single P-Tunnel (i.e. sharing one P2MP
   LSP) , the upstream-assigned label mechanism is introduced to
   associate the MPLS label with one MVPN or VPLS and advertise the
   label binding via BGP by the ingress PEs.  In addition this procedure
   requires each egress PE to support a separate label space for every
   other PE.  When the packet is received the label space ( called as
   "tunnel-specific label space" ) should be determined firstly by the
   aggregating tree over which the packet is received and in the label
   space the upstream-assigned MPLS label lookup has to be performed.
   The upstream-assigned label mechanism and multi-instance label-space
   forwarding mechanism have much effect on the existing MPLS control
   plane and forwarding plane.  MPLS global label are introduced to
   identify the MVPN instance or the VPLS instance and the label binding
   is advertised to all PEs.  When aggregating multiple MVPN instances
   and VPLS instances over one P-tunnel, the corresponding MPLS global
   label binded with these VPN instances should be encapsulated.  Then
   the egress PEs can determine the MVPN or VPLS instance based the
   encapsulated MPLS global label after receive the packets through the
   packets.  The mechanism can simplify the possible change of the
   existing control plane and the existing MPLS forwarding mechanism in
   the data plane can be reused.  That is, It can simplify the process

Li, et al.               Expires August 18, 2014                [Page 5]
Internet-Draft        Usecases of MPLS Global Label        February 2014

   of the Multicast VPN and VPLS Multicast while achieve the same object
   as the upstream-assigned label mechanism.

3.2.2.  Local Protection of PE Node

   The local protection mechanism for PE node such as
   [I-D.shen-pwe3-endpoint-fast-protection] has been introduced . If
   failure happens in the PE node, the service traffic to the PE node
   can be switched by the penultimate hop to the other backup PE.  In
   order to achieve the object, multi-instance MPLS label space has to
   be introduced and labels allocated for L3VPN or L2VPN must backup
   between the multi-homed PEs or be coordinated through possible
   protocol extensions based on ICCP, etc.  For the local protection
   mechanism proposed in [I-D.zhang-l3vpn-label-sharing] against egress
   node failure, MPLS global label can be introduced to identify the
   same L3VPN instance or L2VPN instance for all joined PEs.  When
   forwarding packets for VPN service, the inner label in the
   encapsulation to identify the specific VPN can be replaced by the
   MPLS global label.  If PE node failure happens, the traffic can
   directly switch to the backup tunnel to the backup PE.  It is only to
   change the outlayer tunnel label without having any extra process on
   the inner label.

3.2.3.  Service Chaining

   With the deployment of service functions (such as firewalls, load
   balancers) in large-scale environments, the term service function
   chaining is used to describe the definition and instantiation of an
   ordered set of such service functions, and the subsequent "steering"
   of traffic flows through those service functions.  The set of enabled
   service function chains reflect operator service offerings and is
   designed in conjunction with application delivery and service and
   network policy (Refer to [I-D.ietf-sfc-problem-statement]).  To
   implement service chaining, it is important to use the service header
   for the packets to be identifed as a specific service flow to pass
   through specific service functions.  In the MPLS network for service
   chaining, the global label can be introduced as the service header to
   identify a specific service flow globally.  When forward packets of
   the specific service flow, the global label should be kept in the
   MPLS stack encapsulation until the service functions are completed.

3.3.  Identification of Network

   MPLS is the basic technology to implement virtual networks.  VPN can
   be seen as a typical example to use the MPLS label to differentiate
   the virtual network instance.  Now the virtual network technologies
   based on MPLS concentrate on the service layer such as L3VPN, L2VPN,
   MVPN, etc.  New requirements on easy implementation of virtual

Li, et al.               Expires August 18, 2014                [Page 6]
Internet-Draft        Usecases of MPLS Global Label        February 2014

   network on the transport layer are being emerged.  MPLS global label
   can also play an important role in the course of achieving the
   object.

3.3.1.  Segment Routing

   Segment Routing[I-D.previdi-filsfils-isis-segment-routing] introduces
   multiple types of segments.  The basic segments includes node segment
   and adjacency segment.  A Node Segment represents the shortest path
   to a node and Node segments must be globally unique within the
   network domain.  In the MPLS data plane instantiation, MPLS global
   label is used to identify a specific Node Segment.  That is, MPLS
   global label can virtualize network nodes to comprise the virtual
   network.

3.3.2.  MPLS Network Virtualization

   As the virtual network operators develop, it is desirable to provide
   better network virtualization solutions to facilitate the service
   provision.  [I-D.li-mpls-network-virtualization-framework] introduces
   the framework for MPLS network virtualization.  In the framework,
   MPLS global label can be used to identify the virtualized network
   topology, nodes and links which can make up the virtual network.

4.  IANA Considerations

   This document makes no request of IANA.

5.  Security Considerations

   TBD.

6.  References

6.1.  Normative References

   [I-D.li-l2vpn-segment-evpn]
              Li, Z., Yong, L., and J. Zhang, "Segment-Based
              EVPN(S-EVPN)", draft-li-l2vpn-segment-evpn-00 (work in
              progress), July 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Li, et al.               Expires August 18, 2014                [Page 7]
Internet-Draft        Usecases of MPLS Global Label        February 2014

6.2.  Informative References

   [I-D.chen-mpls-source-label]
              Chen, M., Building, K., Li, Z., and L. Fang,
              "MultiProtocol Label Switching (MPLS) Source Label",
              draft-chen-mpls-source-label-01 (work in progress),
              October 2013.

   [I-D.ietf-l2vpn-evpn]
              Sajassi, A., Aggarwal, R., Henderickx, W., Isaac, A., and
              J. Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-
              l2vpn-evpn-05 (work in progress), February 2014.

   [I-D.ietf-l2vpn-pbb-evpn]
              Sajassi, A., Salam, S., Boutros, S., Bitar, N., Isaac, A.,
              and L. Jin, "PBB-EVPN", draft-ietf-l2vpn-pbb-evpn-06 (work
              in progress), October 2013.

   [I-D.ietf-l2vpn-vpls-mcast]
              Aggarwal, R., Rekhter, Y., Kamite, Y., and L. Fang,
              "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-16 (work
              in progress), November 2013.

   [I-D.ietf-sfc-problem-statement]
              Quinn, P. and T. Nadeau, "Service Function Chaining
              Problem Statement", draft-ietf-sfc-problem-statement-00
              (work in progress), January 2014.

   [I-D.li-mpls-network-virtualization-framework]
              Li, Z. and M. Li, "Framework of Network Virtualization
              Based on MPLS Global Label", draft-li-mpls-network-
              virtualization-framework-00 (work in progress), October
              2013.

   [I-D.previdi-filsfils-isis-segment-routing]
              Previdi, S., Filsfils, C., Bashandy, A., Horneffer, M.,
              Decraene, B., Litkowski, S., Milojevic, I., Shakir, R.,
              Ytti, S., Henderickx, W., and J. Tantsura, "Segment
              Routing with IS-IS Routing Protocol", draft-previdi-
              filsfils-isis-segment-routing-02 (work in progress), March
              2013.

   [I-D.shen-pwe3-endpoint-fast-protection]
              Shen, Y., Aggarwal, R., and W. Henderickx, "PW Endpoint
              Fast Failure Protection", draft-shen-pwe3-endpoint-fast-
              protection-04 (work in progress), July 2013.

Li, et al.               Expires August 18, 2014                [Page 8]
Internet-Draft        Usecases of MPLS Global Label        February 2014

   [I-D.zhang-l3vpn-label-sharing]
              Zhang, M., Zhou, P., and R. White, "Label Sharing for Fast
              PE Protection", draft-zhang-l3vpn-label-sharing-01 (work
              in progress), October 2013.

   [RFC6513]  Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
              VPNs", RFC 6513, February 2012.

Authors' Addresses

   Zhenbin Li
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: lizhenbin@huawei.com

   Quintin Zhao
   Huawei Technologies
   125 Nagog Technology Park
   Acton, MA  01719
   US

   Email: quintin.zhao@huawei.com

   Tianle Yang
   China Mobile
   32, Xuanwumenxi Ave.
   Beijing  01719
   China

   Email: yangtianle@chinamobile.com

Li, et al.               Expires August 18, 2014                [Page 9]