One document matched: draft-li-mpls-global-label-usecases-00.txt
Network Working Group Z. Li
Internet-Draft Q. Zhao
Intended status: Informational Huawei Technologies
Expires: January 12, 2014 T. Yang
China Mobile
July 11, 2013
Usecases of MPLS Global Label
draft-li-mpls-global-label-usecases-00
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 January 12, 2014.
Copyright Notice
Li, et al. Expires January 12, 2014 [Page 1]
Internet-Draft Usecases of MPLS Global Label July 2013
Copyright (c) 2013 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 . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 4
3.2. Identification of Services . . . . . . . . . . . . . . . 5
3.2.1. Identification of MVPN/VPLS . . . . . . . . . . . . . 5
3.2.2. Local Protection of PE Node . . . . . . . . . . . . . 5
3.3. Identification of Network . . . . . . . . . . . . . . . . 6
3.3.1. Segment Routing . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
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
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
Li, et al. Expires January 12, 2014 [Page 2]
Internet-Draft Usecases of MPLS Global Label July 2013
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
ICCP: Inter-chassis Communication Protocol
MP2MP: Multi-Point to Multi-Point
MP2P: Multi-Point to Point
MVPN: Multicast VPN
P2P: Point to Point
P2MP: Point to Multi-Point
PE: Provider Edge
PBB: Provider Backbone Bridge
E-VPN: Ethernet VPN
S-EVPN: Segment-based EVPN
ES: Ethernet Segment
3. Usecases
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
Li, et al. Expires January 12, 2014 [Page 3]
Internet-Draft Usecases of MPLS Global Label July 2013
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 E-VPN. 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 E-VPN( [I-D.ietf-l2vpn-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
Li, et al. Expires January 12, 2014 [Page 4]
Internet-Draft Usecases of MPLS Global Label July 2013
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 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. If MPLS global label are introduced to
identify the MVPN instance or the VPLS instance and the label binding
is advertised to all PEs, it can simplify the possible change of the
existing control plane and the existing MPLS forwarding mechanism in
the data plane can be reused. It can simplify the process the
Multicast VPN and VPLS Multicast while achieve the same object as
that of 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. MPLS global label can be
introduced to identify the same L3VPN instance or L2VPN instance for
all joined PEs. When forwarding packet 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
Li, et al. Expires January 12, 2014 [Page 5]
Internet-Draft Usecases of MPLS Global Label July 2013
traffic can directly switch on 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.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.previdi-filsfils-isis-segment-routing] introduces
two forms of segments: 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.
4. IANA Considerations
This document makes no request of IANA.
5. Security Considerations
TBD.
6. Normative References
[I-D.ietf-l2vpn-evpn]
Sajassi, A., Aggarwal, R., Henderickx, W., Balus, F.,
Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN",
draft-ietf-l2vpn-evpn-03 (work in progress), February
2013.
[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-04 (work
in progress), February 2013.
[I-D.ietf-l2vpn-vpls-mcast]
Li, et al. Expires January 12, 2014 [Page 6]
Internet-Draft Usecases of MPLS Global Label July 2013
Aggarwal, R., Rekhter, Y., Kamite, Y., and L. Fang,
"Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-14 (work
in progress), July 2013.
[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.
[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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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
Li, et al. Expires January 12, 2014 [Page 7]
Internet-Draft Usecases of MPLS Global Label July 2013
Tianle Yang
China Mobile
32, Xuanwumenxi Ave.
Beijing 01719
China
Email: yangtianle@chinamobile.com
Li, et al. Expires January 12, 2014 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-21 19:36:01 |