Network Working Group Z. Li
Internet-Draft Q. Zhao
Intended status: Informational Huawei Technologies
Expires: January 4, 2015 T. Yang
China Mobile
R. Raszuk
Individual
July 3, 2014
Use Cases of MPLS Global Label
draft-li-mpls-global-label-usecases-02
Abstract
As the SDN(Service-Driven Network) technology develops, MPLS global
label has been proposed for new solutions. The document proposes
possible use cases of MPLS global label. In these use cases MPLS
global label can be used as identification of the location, the
service and the network in different application scenarios.
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 January 4, 2015.
Li, et al. Expires January 4, 2015 [Page 1]
Internet-Draft Use Cases of MPLS Global Label July 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. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Identification of Location . . . . . . . . . . . . . . . 3
3.1.1. VPLS Multicast over MP2MP LSP . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . 5
3.2.3. Service Chaining . . . . . . . . . . . . . . . . . . 6
3.3. Identification of Network . . . . . . . . . . . . . . . . 6
3.3.1. Segment Routing . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Currently MPLS label always has local meaning. That is, MPLS label
is always allocated by the downstream node to the upstream node and
the meaning of the MPLS label is only understood by the neighboring
upstream node and downstream node. As the SDN concept is introduced,
the MPLS global label mechanism are being proposed for new solutions
based on the label binding which should be understood by all nodes or
part of nodes in the network. This document proposes possible use
cases for MPLS global label which can be used as identification of
Li, et al. Expires January 4, 2015 [Page 2]
Internet-Draft Use Cases of MPLS Global Label July 2014
the location, the service and the network in different application
scenarios.
2. Terminology
BUM: Broadcast, Unknown unicast, or Multicast
B-MAC: Backbone MAC Address
CE: Customer Edge
C-MAC: Customer/Client MAC Address
DF: Designated Forwarder
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. Use Cases
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 SHOULD 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
Li, et al. Expires January 4, 2015 [Page 3]
Internet-Draft Use Cases of MPLS Global Label July 2014
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 LSPEV, 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
EVPN( [I-D.ietf-l2vpn-evpn]) introduces a solution for multipoint
L2VPN services. Split horizon is an important feature in EVPN to
cope with the challenge proposed by BUM traffic. In order to achieve
the split horizon function, every BUM packet originating from a non-
DF PE is encapsulated with an ESI label that identifies the Ethernet
segment of origin (i.e. the segment from which the frame entered the
EVPN network). The existing ESI label allocation solutions are
different for the different transport tunnel technologies: downstream
ESI label assignment for ingress replication and upstream ESI label
assignment for P2MP LSP. For MP2MP LSP, there is no solutions of ESI
label assignment for split horizon function yet.
[I-D.li-l2vpn-segment-evpn] proposes an enhanced EVPN mechanism,
segment-based EVPN (S-EVPN). It introduces the global label to
identify the Ethernet Segment which can also be used as the ESI label
for split horizon. Thus no matter what tunnel technology (including
MP2MP LSP) is adopted to transport BUM traffic, there will be
unifying ESI label assignment mechanism for split horizon.
Besides unifying split horizon function in EVPN, S-EVPN can also be
used as an alternative solution in the central control environment
for 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
Li, et al. Expires January 4, 2015 [Page 4]
Internet-Draft Use Cases of MPLS Global Label July 2014
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.
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 outer 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) , MPLS global label can be 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 on the encapsulated MPLS
global label after receive the packets through the P tunnel.
3.2.2. Local Protection of PE Node
The local protection mechanisms for PE node such as
[I-D.ietf-pwe3-endpoint-fast-protection] and
[I-D.zhang-l3vpn-label-sharing] have been proposed. If failure
happens in the PE node, the service traffic to the primary PE node
Li, et al. Expires January 4, 2015 [Page 5]
Internet-Draft Use Cases of MPLS Global Label July 2014
can be switched by the penultimate hop to the other backup PE. In
order to achieve the object, MPLS global label can be introduced to
identify the same L3VPN instance or L2VPN instance for multi-homed
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 LSP to the backup PE at the penultimate
hop. It is only to change the out-layer 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]). The
source packet routing mechanism can be used to implement service
chaining in MPLS networks ([I-D.xu-spring-sfc-use-case]). MPLS
global label can be introduced to identify the service functions and
the label binding can be advertised in the network. Then the ingress
node can compose the MPLS stacked path to steer packets through the
required service function path for specific service flow.
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
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.filsfils-spring-segment-routing] is introduced
to leverage the source routing paradigm for traffic engineering, fast
re-route, etc. A node steers a packet through an ordered list of
segments. A segment can represent any instruction, topological or
service-based. Segment Routing can be directly applied to the MPLS
architecture with no change on the forwarding plane. A segment is
encoded as an MPLS label. An ordered list of segments is encoded as
a stack of labels. In Segment Routing, the basic segments include
Li, et al. Expires January 4, 2015 [Page 6]
Internet-Draft Use Cases of MPLS Global Label July 2014
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. That is, In the MPLS data plane
instantiation, MPLS global label is used to identify a specific Node
Segment. In essence MPLS global label is to represent the
virtualized nodes in the 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-01 (work in
progress), February 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[I-D.chen-mpls-source-label]
Chen, M., Xu, X., Li, Z., Fang, L., and G. Mirsky,
"MultiProtocol Label Switching (MPLS) Source Label",
draft-chen-mpls-source-label-05 (work in progress), July
2014.
Li, et al. Expires January 4, 2015 [Page 7]
Internet-Draft Use Cases of MPLS Global Label July 2014
[I-D.filsfils-spring-segment-routing]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing Architecture", draft-filsfils-spring-
segment-routing-03 (work in progress), June 2014.
[I-D.ietf-l2vpn-evpn]
Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J.
Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn-
evpn-07 (work in progress), May 2014.
[I-D.ietf-l2vpn-pbb-evpn]
Sajassi, A., Salam, S., Bitar, N., Isaac, A., Henderickx,
W., and L. Jin, "PBB-EVPN", draft-ietf-l2vpn-pbb-evpn-07
(work in progress), June 2014.
[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-pwe3-endpoint-fast-protection]
Shen, Y., Aggarwal, R., Henderickx, W., and Y. Jiang, "PW
Endpoint Fast Failure Protection", draft-ietf-pwe3-
endpoint-fast-protection-00 (work in progress), December
2013.
[I-D.ietf-sfc-problem-statement]
Quinn, P. and T. Nadeau, "Service Function Chaining
Problem Statement", draft-ietf-sfc-problem-statement-07
(work in progress), June 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.xu-spring-sfc-use-case]
Xu, X., Li, Z., Shah, H., and L. Contreras, "Service
Function Chaining Use Case for SPRING", draft-xu-spring-
sfc-use-case-02 (work in progress), June 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-02 (work
in progress), June 2014.
Li, et al. Expires January 4, 2015 [Page 8]
Internet-Draft Use Cases of MPLS Global Label July 2014
[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
Robert Raszuk
Individual
Email: robert@raszuk.net
Li, et al. Expires January 4, 2015 [Page 9]