Internet DRAFT - draft-li-mpls-seamless-mpls-mbb
draft-li-mpls-seamless-mpls-mbb
Network Working Group Zhenbin Li
Internet-Draft Lei Li
Intended status: Informational Huawei Technologies
Expires: August 17, 2014 Manuel Julian Lopez Morillo
Vodafone Group Networks
Tianle Yang
China Mobile
February 13, 2014
Seamless MPLS for Mobile Backhaul
draft-li-mpls-seamless-mpls-mbb-01
Abstract
This document introduces the framework of Seamless MPLS to integrate
the mobile backhaul network with the core network. New requirements
of Seamless MPLS for mobile backhaul networks are defined and
corresponding solutions are proposed.
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 17, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhenbin Li, et al. Expires August 17, 2014 [Page 1]
Internet-Draft Seamless MPLS for Mobile Backhaul February 2014
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. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Scenarios for Network Architecture . . . . . . . . . . . 4
3.2. Scenarios for Different Edge of Labeled BGP . . . . . . . 6
4. Requirements and Solutions . . . . . . . . . . . . . . . . . 9
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1. Auto Mesh and Enhancement . . . . . . . . . . . . . . 12
4.2.2. Service-Driven Tunnel . . . . . . . . . . . . . . . . 13
4.2.3. Auto Path Computation . . . . . . . . . . . . . . . . 13
4.3. Access Stitching . . . . . . . . . . . . . . . . . . . . 14
4.3.1. Transport Layer Stitching . . . . . . . . . . . . . . 14
4.3.2. Service Layer Stitching technology . . . . . . . . . 15
4.4. Reliability . . . . . . . . . . . . . . . . . . . . . . . 18
4.4.1. MRT FRR based on LDP MT . . . . . . . . . . . . . . . 18
4.5. Policy Control . . . . . . . . . . . . . . . . . . . . . 18
4.6. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.6.1. L3VPN PM . . . . . . . . . . . . . . . . . . . . . . 19
4.6.2. IPFPM (IP Flow Performance Measurement) . . . . . . . 19
4.6.3. Service Path Visualization . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
Seamless MPLS [I-D.ietf-mpls-seamless-mpls] describes an architecture
which can be used to extend MPLS networks to integrate access and
core/aggregation networks into a single MPLS domain. It provides a
highly flexible and a scalable architecture and the possibility to
integrate 100.000 of nodes. One of the key elements of Seamless MPLS
Zhenbin Li, et al. Expires August 17, 2014 [Page 2]
Internet-Draft Seamless MPLS for Mobile Backhaul February 2014
is the separation of the service and transport plane: it can reduce
the service specific configurations in network transport node.
The main purpose of Seamless MPLS is to deal with the integration of
access networks and core/aggregation networks. The typical access
devices taken into account are DSLAM(Digital Subscriber Link Access
Multiplexer), etc. Now the mobile backhaul service has been deployed
widely, the requirement of the integration of mobile backhaul
networks and core networks has been proposed. Though some approaches
of Seamless MPLS can be reused for the integration, there has to be
some new issues to be dealt with when integrate these networks based
on MPLS technologies.
This document describes new requirements and solutions for Seamless
MPLS to extend the core domain to integrate the mobile backhaul
networks. It can enable a flexible deployment of an end to end
mobile backhaul service delivery. Though the Seamless MPLS approach
for the integration of the core network and the mobile network tries
to use existing and well known protocols, some new features or
protocol extensions have to be introduced for the integrated network
to provide the unified service.
Currently, this document focuses on end to end unicast LSP.
Multicast will be described in the future version.
2. Terminology
This document uses the following terminology:
o ABR: Area Border Router
o ASBR: AS Border Router
o ASG: Aggregation Site Gateway
o CSG: Cell Site Gateway
o LFA: Loop Free Alternate
o NPE: Network Provider Edge
o PE: Provider Edge
o RNC: Radio Network Controller
o RSG: RNC Site Gateway
o SPE: Switching Provider Edge
Zhenbin Li, et al. Expires August 17, 2014 [Page 3]
Internet-Draft Seamless MPLS for Mobile Backhaul February 2014
o UPE: Under Provider Edge
3. Scenarios
Existing mobile backhaul networks have different topology and network
architectures composed by devices with variable capability . Seamless
MPLS should be able to adapt to different scenarios to support the
integration of mobile backhaul networks.
3.1. Scenarios for Network Architecture
Mobile backhaul networks are usually built using hierarchical network
structure with access network, aggregation network and core network.
These networks are always separated by AS or IGP area. Along with
the progress of network integration, the integration network can be
summarized as following scenarios.
Network Architecture 1: Network separated by ASes
In current networks it is common that the core network and the mobile
backhaul network have different AS numbers. The core network usually
uses a public AS number for internet connection. On the other hand
the mobile backhaul network including access network and aggregation
network usually uses a private AS number just for local services. So
the integrated end-to-end service means to across different ASes.
Scenario 1: ASes connected by different ASBRs
This is the most common scenario. In this scenario there are
redundant ASBRs in each AS to connect with the other AS back to back.
| Service |
|------------------------------------------------------|
| AS-X | | AS-Y |
|(Access/Aggregation)| | (Core) |
|--------------------| |------------------|
| | |
+-----+ +-----+
...|ASBR1|-------|ASBR3|....
+----+ ........ +-----+ +-----+ ....... +----+
| PE |... ...| PE |
+----+ ..... ..... +----+
..... +-----+ +-----+ .....
..|ASBR2|-------|ASBR4|..
+-----+ +-----+
Figure 1 Redundant ASBRs connected Back to Back
Zhenbin Li, et al. Expires August 17, 2014 [Page 4]
Internet-Draft Seamless MPLS for Mobile Backhaul February 2014
The transport layer of Seamless MPLS for this scenario is the same as
the Option C Inter-AS VPN scenario defined by [RFC4364]. In this
scenario, Seamless MPLS uses label distribution enabled IBGP and EBGP
to establish the end-to-end BGP LSP to support services (using IPv4
as the example).
o IBGP distributes the PE's 32/ route to ASBRs in source AS (P
devices need not know the PE's 32/ route).
o EBGP redistributes labeled IPv4 routes from source AS to
neighboring AS.
o IBGP distributes the PE's 32/ route from ASBRs to ingress PEs in
target AS.
Scenario 2: ASes connected by integrated ASBRs
In this scenario there are still redundant ASBRs in each AS. But
these ASBRs integrates together to reduce a pair of devices. This
scenario can effectively reduce the number of devices and costs.
Other devices in each AS such as PEs and Ps need not be impacted.
| Service |
|----------------------------------------|
| AS-X | AS-Y |
|(Access/Aggregation)| (Core) |
|--------------------|-------------------|
| | |
+-----+
....ASBR1|....
+----+ ........ +-----+ ....... +----+
| PE |... ...| PE |
+----+ ..... ..... +----+
..... +-----+ .....
...ASBR2|..
+-----+
Figure 2 Integrated ASBRs
The transport layer of Seamless MPLS for this scenario is similar
with the network architecture 1 (using IPv4 as the example).
o The same in each AS domain. Still use IBGP to distribute the PE's
32/ routes.
o The integrated ASBR should support two different ASes and can
redistribute the labeled IPv4 routes from one AS to neighboring
AS.
Zhenbin Li, et al. Expires August 17, 2014 [Page 5]
Internet-Draft Seamless MPLS for Mobile Backhaul February 2014
Network Architecture 2: Different network integrated in one AS but
separated by different IGP areas
This scenario is far different from most of current mobile backhaul
networks. Core network is deployed in a same AS with access/
aggregation network. The core network, aggregation network and
access network are just separated by IGP areas for scalability.
| Service |
|----------------------------------------|
| AS |
|----------------------------------------|
| IGP-X | IGP-Y |
|(Access/Aggregation)| (Core) |
|--------------------|-------------------|
| | |
+----+
... |ABR1|....
+----+ ........ +----+ ....... +----+
| PE |... ...| PE |
+----+ ..... ..... +----+
..... +----+ .....
...|ABR2|..
+----+
Figure 3 Integrated network in one AS
In this scenario, Seamless MPLS uses labeled IBGP to establish the
end-to-end BGP LSP to support services.
3.2. Scenarios for Different Edge of Labeled BGP
Devices in existing mobile backhaul networks vary in capacity.
Labeled BGP capability may not be able to be supported by all
devices, especially by lower level nodes in access network. Seamless
MPLS based on labeled BGP technology should adapt to different
situations. Based on the location of the edge of labeled BGP, there
should be three possible scenarios.
Scenario 1: Cell Site/User PE devices as the edge of labeled BGP
The transport layer in this scenario should be totally end-to-end BGP
LSP. The scenario requires the ingress PE(access devices) to
encapsulate a three-label stack on the packet. This requirement
maybe difficult to be satisfied by all kinds of access devices,
especially access devices with very low capacity.
Zhenbin Li, et al. Expires August 17, 2014 [Page 6]
Internet-Draft Seamless MPLS for Mobile Backhaul February 2014
| AS-X | | AS-Y |
|(Access/Aggregation)| | (Core) |
|--------------------| |-------------------|
| | | |
+-----+ +-----+
...|ASBR1|-------|ASBR3|....
+----+ ........ +-----+ +-----+ ....... +----+
| PE |... ...| PE |
+----+ ..... ..... +----+
..... +-----+ +-----+ .....
..|ASBR2|-------|ASBR4|..
+-----+ +-----+
| |
| Hierarchical BGP LSP |
+--------------------+--------------+------------------+
| | | |
+--------------------+--------------+------------------+
| MPLS LDP/TE | MPLS LDP/TE | MPLS LDP/TE |
| | | |
Figure 4 Labeled BGP ended at access devices
Scenario 2: ASG nodes as the edge of labeled BGP
In this scenario, access nodes(PEs) directly connected with eNodeB
can not support labeled BGP. Access nodes only support basic MPLS
functionality with basic route functionality using static or default
routes. ASG devices should stitch MPLS LDP/TE LSP in access network
and BGP LSP in aggregation/core network to support end-to-end
services.
Zhenbin Li, et al. Expires August 17, 2014 [Page 7]
Internet-Draft Seamless MPLS for Mobile Backhaul February 2014
| AS-X | | AS-Y |
|(Access/Aggregation)| | (Core) |
|--------------------| |-------------------|
| | | |
+----+ +-----+ +-----+
|ASG | ...|ASBR1|-------|ASBR3|....
+----+ .+----+. +-----+ +-----+ ... +----+
| PE |... .....| PE |
+----+ ..+----+ .. +----+
|ASG |.. +-----+ +-----+ .....
+----+ ..|ASBR2|-------|ASBR4|..
+-----+ +-----+
| | | | |
| |Labeled IBGP|Labeled EBGP| Labeled IBGP |
| +------------+------------+---------------------+
+-----------+ | | |
|MPLS LDP/TE+------------+ +---------------------+
| | MPLS LDP/TE| | MPLS LDP/TE |
| | | | |
Figure 5 Labeled BGP ended at ASG(P) devices
Scenario 3: RSG(ASBR) devices as the edge of labeled BGP
In this scenario devices in the access and aggregation network just
support basic MPLS functionality. ASBR nodes should stitch MPLS LDP/
TE LSP in access/aggregation network and BGP LSP in core network for
end-to-end service across different domains.
Zhenbin Li, et al. Expires August 17, 2014 [Page 8]
Internet-Draft Seamless MPLS for Mobile Backhaul February 2014
| AS-X | | AS-Y |
|(Access/Aggregation)| | (Core) |
|--------------------| |-------------------|
| | | |
+-----+ +-----+
...|ASBR1|-------|ASBR3|....
+----+ ........ +-----+ +-----+ ....... +----+
| PE |... ...| PE |
+----+ ..... ..... +----+
..... +-----+ +-----+ .....
..|ASBR2|-------|ASBR4|..
+-----+ +-----+
| | | |
| | Labeled EBGP | Labeled IBGP |
| +--------------+------------------+
+--------------------+ +------------------+
| MPLS LDP/TE | | MPLS LDP/TE |
Figure 6 Labeled BGP ended at ASBRs
4. Requirements and Solutions
4.1. Overview
The typical mobile backhaul network is shown in the figure 1. It
usually adopts ring topology to save fiber resource and it is divided
into the aggregate network and the access network. Cell Site
Gateways(CSGs) connects the eNodeBs and RNC Site Gateways(RSGs)
connects the RNCs. The mobile traffic is transported from CSGs to
RSGs.
Zhenbin Li, et al. Expires August 17, 2014 [Page 9]
Internet-Draft Seamless MPLS for Mobile Backhaul February 2014
----------------
/ \
/ \
/ \
+------+ +----+ Access +----+
|eNodeB|---|CSG1| Ring 1 |ASG1|-------------
+------+ +----+ +----+ \
\ / \
\ / +----+ +---+
\ +----+ |RSG1|----|RNC|
-------------| | Aggregate +----+ +---+
|ASG2| Ring |
-------------| | +----+ +---+
/ +----+ |RSG2|----|RNC|
/ \ +----+ +---+
/ \ /
+------+ +----+ Access +----+ /
|eNodeB|---|CSG2| Ring 2 |ASG3|------------
+------+ +----+ +----+
\ /
\ /
\ /
-----------------
Figure 7 Mobile Backhaul Network
Seamless MPLS [I-D.ietf-mpls-seamless-mpls] defines the possible
requirements for the integration of the access network and the
aggregation/core network. In the mobile backhaul network, being
different from the typical access devices(DSLAM, MSAN), CSGs and RSGs
of the mobile backhaul network needs to support rich MPLS features
such as path design, protection switch, OAM, etc., to provide SDH-
like service. On the other hand, CSGs have the same scalability
limitations as access devices. Seamless MPLS for mobile backhaul has
to take into account the difference and the similarity and new
requirements are proposed.
1. Requirements on MPLS TE
In the mobile backhaul network, in order to provide SDH-like service,
MPLS TE or MPLS TP technologies are always introduced besides MPLS
LDP. When integrate the core network and the mobile backhaul
network, the interworking between IGP/BGP and RSVP-TE is inevitable.
There are following requirements:
-- Proxy Egress LSP and BGP LSP Stitching: When the end-to-end LSP
setup in the Seamless MPLS domain, MPLS TE LSP in the mobile backhaul
should be stitched with the BGP LSP in the core network. In
Zhenbin Li, et al. Expires August 17, 2014 [Page 10]
Internet-Draft Seamless MPLS for Mobile Backhaul February 2014
addition, since the end-to-end MPLS TE LSP cannot setup spanning
multiple areas, the proxy egress RSVP-TE LSP should be able to setup
in the mobile backhaul network.
-- OAM: There are complete OAM solutions for MPLS TE/MPLS-TP
including fault management(FM) and performance monitoring(PM). For
IGP/BGP, the OAM mechanism, especially the performance monitoring
mechanism is not enough. Thus the end-to-end OAM for the mobile
backhaul service can not be provided. The Seamless MPLS architecture
should propose unified OAM mechanisms to satisfy the requirements of
the end-to-end services.
-- Protection: The protection switch mechanism has been provided in
the mobile backhaul network to achieve convergence in 50ms. When
integrate the core network, the end-to-end convergence in 50 ms
should be guaranteed.
-- Scalability: Comparing with MPLS LDP, there exists more
scalability issues for MPLS TE. Though the network scale can be
controlled by dividing the network into multiple IGP areas in the
Seamless MPLS domain, there is more complex configuration for MPLS TE
than MPLS LDP since the rich MPLS TE properties should be specified.
The provision issue has much negative effect on the scalability of
MPLS-TE-based network.
2. Requirements on Ring Network
In mobile backhaul network, CSGs always access the ring network. The
approaches proposed in the [I-D.ietf-mpls-seamless-mpls] face
challenges in the ring network.
-- LDP DoD: There exists multiple nodes from a CSG to an ASG in the
ring network. This means label request messages and label mapping
messages should be sent through multiple nodes for LDP DoD. If
static routes are used, there are a great deal of routes which should
be configured statically in the network. This provision is hard to
be accepted by the service provider.
-- LFA(Loop Free Alternate): The route loop will be bound to happen
in the ring network. This means that the backup route does not exist
in specific nodes of the ring network according to LFA. If LDP is
used and convergence in 50 ms must be guaranteed for the mobile
backhaul service, the new FRR solution must be proposed to cover the
whole network.
3. Requirements on L3VPN
Zhenbin Li, et al. Expires August 17, 2014 [Page 11]
Internet-Draft Seamless MPLS for Mobile Backhaul February 2014
FMC( Fixed Mobile Convergence ) is being taken into account for the
mobile backhaul network. In order to achieve higher scalability,
L3VPN is provisioned to bear the mobile backhaul service besides PW.
There are following requirements:
-- Policy control: The routes in the L3VPN can be advertised in a
larger scope comparing with the point-to-point PW setup in the L2VPN.
Considering the limited capability of the access devices (CSGs),
complex policy control on route advertisement has to be introduced.
This cause the provision becomes complex and error-prone.
Simplifying the policy control is mandatory in the Seamless MPLS
domain.
-- L3VPN OAM: There exists mature OAM mechanism based on PW for
L2VPN. The similar mechanism should be provided for the L3VPN to
satisfy the SDH-like OAM requirement for the mobile backhaul service.
4.2. Scalability
[I-D.li-mpls-serv-driven-co-lsp-fmwk] describes the massive
configuration issue for MPLS TE. As the mobile backhaul service
develops and the network scale expands, more and more LTE eNodeBs and
associated Cell Site Gateways(CSGs) are added in the networks to
connect the RNCs and associated RNC site gateways(RSGs). This
proposes the requirement of a great deal of MPLS TE tunnels which
connect CSGs and RSGs. Calculated using the typical MPLS TE tunnel
configuration, there will be hundreds of thousands of command lines
need to be configured for MPLS TE. In addition, the return path
issue for BFD for LSP will deteriorate the configuration work since
the configuration is necessary to guarantee the return the path is
the same as the forward path for MPLS TE tunnels. Comparing with
LDP, the provision work for MPLS TE is time-consuming and error-prone
which has much negative effect on the scalability. When Seamless
MPLS is applied to the mobile backhaul network, the scalability of
MPLS TE must be improved by effective solutions.
4.2.1. Auto Mesh and Enhancement
[RFC4972] proposes an automatic discovery mechanism to discover the
set of LSR members of a mesh in order to automate the creation of
mesh of TE LSPs. Through Interior Gateway Protocol (IGP) routing
extensions, the LSRs members of a specific mesh can be discovered.
Then the LSR can trigger setup of MPLS TE tunnels to other LSRs of
the same mesh. [I-D.li-ccamp-role-based-automesh] proposes the
optimization for the auto mesh mechanism. In some application
scenarios, it is not necessary to setup full mesh MPLS TE tunnels.
The optimized auto mesh mechanism is to not only advertise the
membership of a mesh, but also advertise the role of the member.
Zhenbin Li, et al. Expires August 17, 2014 [Page 12]
Internet-Draft Seamless MPLS for Mobile Backhaul February 2014
Thus the MPLS TE tunnel can setup based on both the membership and
the role. It can save the unnecessary setup of MPLS TE tunnels.
4.2.2. Service-Driven Tunnel
[I-D.li-mpls-serv-driven-co-lsp-fmwk] proposes the service-driven
mechanism and framework for setup of MPLS TE tunnels. LDP LSP has
advantage over MPLS TE in scalability since LDP LSP setup is
topology-driven which is a scalable way to adapt to the large-scale
network. On the other hand, MPLS TE LSP is always setup to bear
specific services such as L3VPN and L2VPN. That is, MPLS TE LSPs
will not be setup aimlessly which is always inevitable for MPLS
topology-driven LSP if there is no policy exerted on it. So the
service-driven mechanism is proposed to trigger MPLS TE LSP setup
automatically by the service instead of explicitly configuring each
tunnel and its traffic engineering attributes. The service-driven
method also has much advantage in the process of setting up co-routed
TE LSPs. The mobile backhaul service transported by MPLS TE LSPs is
always bi-directional. The characteristic can be utilized to setup
the forward MPLS TE LSP and the co-routed reverse MPLS TE LSP. The
details of the procedures can refer to
[I-D.li-mpls-serv-driven-co-lsp-fmwk].
4.2.3. Auto Path Computation
No matter the auto mesh mechanism or the service-driven mechanism is
used to automate the creation of MPLS TE LSPs, several set of MPLS TE
properties need to be specified for these MPLS TE tunnels. If a
group of tunnels can share one set of MPLS TE properties, they can be
triggered to setup automatically. On the contrary, if there are
distinct MPLS TE properties for MPLS TE tunnels, the configuration
work can not be saved since even if the auto tunnel mechanism is
adopted the MPLS TE properties has to be configured for each tunnel
which is like the current explicit configuring of traffic engineering
properties of a tunnel. For MPLS TE, the explicit path is such a
tough thing which can have negative effect on the auto tunnel
mechanism. [I-D.li-ospf-auto-mbb-te-path] describes the scenarios of
the mobile backhaul service in which the explicit path has to be
used. Accordingly TA (TE Area) and TL(TE Layer) are introduced for
the design of MPLS TE network view. Thus less MPLS TE properties
need to be specified for MPLS TE tunnels and automation of path
computation can be improved. As a result the auto tunnel mechanism
can be applied to improve the scalability of MPLS TE.
Zhenbin Li, et al. Expires August 17, 2014 [Page 13]
Internet-Draft Seamless MPLS for Mobile Backhaul February 2014
4.3. Access Stitching
To reduce the requirement on lower level network devices( access
nodes/ ASG nodes, etc.) and keep these devices as simple as possible,
the MPLS stitching technology should be deployed at the edge of
labeled BGP nodes. Thus nodes under the stitching points just need
to support basic MPLS function with IGP or even just static routes.
The position of the stitching point has been discussed in section
3.2. This section introduces the stitching solutions.
1. Transport layer stitching. This kind of stitching technology
ensures the transport LSP can setup end to end. The service is
just to deploy at the end points and the transit nodes in network
need not perceive services.
2. Service layer stitching. This kind of stitching technology
establishes a hierarchical service end to end. This technology
can reduce the load of service session on access nodes. But the
stitching nodes need to perceive services.
4.3.1. Transport Layer Stitching
Transport layer stitching technology can stitch multi-segment
transport LSPs together to establish an end-to-end LSP.
4.3.1.1. Proxy TE
In mobile backhaul network MPLS TE has been adopted to provide SDH-
like service. When the end-to-end LSP setup in the Seamless MPLS
domain, MPLS TE LSP in the mobile backhaul network should be stitched
with the BGP LSP in the core network. [I-D.li-mpls-proxy-te-lsp]
proposes the solution to setup proxy egress LSP by RSVP-TE. When
setup such LSP, there are two addresses will be carried by RSVP-TE
Path/Resv messages: the actual destination address and the proxy node
address. RSVP-TE Path message will be sent along the path to the
proxy node instead of the actual destination node. When Path
messages arrives at the proxy node, it will send back Resv message to
allocate label and reserve resource. The proxy node can use the
actual destination address advertised by the Path message to stitch
with BGP LSP. With Proxy TE, the path for the LSP is calculated with
the proxy node as the destination instead of its actual destination.
So the MPLS TE information related with the path to the actual
destination is not necessary to flood in the mobile backhaul network.
This reduces the state maintenance and process burden of access
nodes.
Zhenbin Li, et al. Expires August 17, 2014 [Page 14]
Internet-Draft Seamless MPLS for Mobile Backhaul February 2014
4.3.1.2. Proxy LDP DoD
If LDP DoD is adopted for Seamless MPLS in the mobile haul network,
since there are multiple hops from the CSG to ASG or RSG, it is
troublesome to configure static routes to a specific destination on
all nodes. Like Proxy TE, LDP can also setup proxy egress LSP by
specifying the proxy node. When setup such LSP, there are two
addresses will be carried by LDP Label Request/Label Mapping
messages: the actual destination address and the proxy node address.
LDP Label Request message will be sent along the path to the proxy
node instead of the actual destination node. When Label Request
messages arrives at the proxy node, it will sent back Label Mapping
message to allocate label. The proxy node can use the actual
destination address advertised by the Label Request message to stitch
with BGP LSP. With Proxy LDP, the route for the proxy node will be
used to setup LSP for the actual destination. So the static routes
for the actual destination are not necessary in the mobile backhaul
network. This reduces the route number and process burden of access
nodes.
4.3.2. Service Layer Stitching technology
There is another stitching technology, which is not only just
stitching transport layer but also stitching the service layer to
help establish services across different domains. Service layer
stitching technology should coexist with common services in an MPLS
network.
Zhenbin Li, et al. Expires August 17, 2014 [Page 15]
Internet-Draft Seamless MPLS for Mobile Backhaul February 2014
+----+ +-----+ +-----+
..|SPE | ...|ASBR1|-------|ASBR3|....
+----+ .... .+----+. +-----+ +-----+ +----+
| UPE|.. ... ...| PE |
+----+ .....+----+ . +----+
..SPE |. . +-----+ +-----+ ..
+----+ ..|ASBR2|-------|ASBR4|..
+-----+ +-----+
| Hierarchy End-to-End Service |
| |
| Service1 | Service2 |
+-----------+-----------------------------------------+
| | | | |
| |Labeled IBGP|Labeled EBGP| Labeled IBGP |
| +------------+------------+---------------+
| | | | |
+-----------+------------+ +---------------+
|MPLS LDP/TE| MPLS LDP/TE| | MPLS LDP/TE |
| | | | |
Figure 8 Architecture of Service Layer Stitching
The general architecture of service layer stitching is shown in
figure 8. The service stitching technologies are related with
different service types.
4.3.2.1. L3 Service Stitching - Hierarchy of VPN (HoVPN)
Hierarchy of VPN (HoVPN) can stitching two segment VPN in one domain
together to establish a VPN service across different domains and
simplify the process of access devices (AN/CSG).
1. Process of Control Plane
o UPEs provide the access service for users. These UPEs act as CSG/
AN to maintain the VPNv4 routes of the directly connected VPN
sites and just default VPNv4 routes advertised from SPEs. For
transport layer UPEs just maintain LSPs to SPEs instead of
establishing Hierarchical LSPs to all remote PEs. For service
layer UPEs just establish VPNv4 MP-BGP session with SPEs instead
of establishing them with all remote PEs.
o SPEs maintain all VPNv4 routes of the VPN sites connected through
the UPEs and PEs, including the routes from the local and the
remote sites. Instead of advertising routes from the remote sites
to the UPEs, the SPE only advertises the default route carrying
label to the UPEs for the specific VPN instance. SPEs establish
Zhenbin Li, et al. Expires August 17, 2014 [Page 16]
Internet-Draft Seamless MPLS for Mobile Backhaul February 2014
hierarchy LSPs through labeled BGP to all other PEs and basic LSPs
/CR-LSPs through MPLS LDP/RSVP-TE to UPEs.
2. Process of Forwarding Plane
o UPEs stack two layer labels for packets to SPEs. The bottom label
is assigned by the SPE and it is associated with the default route
in a particular VRF. The top label is assigned by the UPE's IGP
Next Hop, which is associated with to the /32 route to the SPE.
o When packets from UPEs arrive at SPEs, the bottom label associated
with the default route in a particular VRF will introduce the
packet to loop up the forwarding entry in corresponding VRF. SPEs
would send packets to remote PEs with three layer label stack.
SPEs will swap the bottom label to a new bottom label which is
assigned by remote PE. The middle label is assigned by the ASBR,
which is associated with the /32 route to the remote PE. The top
label is assigned by the SPE's IGP Next Hop, corresponding to the
/32 route to the ASBR.
In HoVPN, since the SPE will only advertise the label binding with
the default route for a specific VRF to the UPE, it can greatly
reduce the route load and the process burden in the UPE.
4.3.2.2. L2VPN Service stitching- Multi-Segment PW
Multi-Segment PW(MS-PW) can stitching two segment PW in one domain
together to establish an end-to-en PW across different domains. With
MS-PW, it is not necessary to setup LDP remote sessions among the
UPEs and the remote PEs. It is just to setup LDP remote session
among UPEs and SPEs. Thus it can reduce the load and the process
burden proposed by LDP remote sessions.
1. Process of Control Plane
o UPEs provide the access service for users. These UPEs act as CSG/
AN to establish LDP remote sessions with SPEs instead of
establishing sessions with all remote PEs.
o SPEs establish SS-PW(Single-Segment PW) with UPEs and remote PEs
and stitching(switch) these two SS-PW together to establish
hierarchy PW services across different domains.
2. Process of Forwarding Plane
The detail of process of the forwarding plane refers to
[I-D.ietf-pwe3-ms-pw-requirements].
Zhenbin Li, et al. Expires August 17, 2014 [Page 17]
Internet-Draft Seamless MPLS for Mobile Backhaul February 2014
4.4. Reliability
4.4.1. MRT FRR based on LDP MT
[I-D.li-rtgwg-ldp-mt-mrt-frr] describes the scenarios of LDP Multi-
topology(MT) for unicast fast-reroute using Maximally Redundant
Trees(MRT). MRT FRR can provide 100% coverage for fast-reroute of
unicast traffic and LDP multi-topology has been proposed to provide
multi-topology-based unicast forwarding in the architecture.
Combining MRT FRR and LDP MT can be easy to achieve the object of
high reliability in IGP/LDP networks. Ring topology has been widely
adopted in mobile backhaul networks. The route loop will be bound to
happen in the ring network and the existing LFA technology cannot
cover the whole network to implement fast reroute functionality. MRT
FRR based on LDP MT can be adopted in the mobile backhaul network
using LDP to provide 100% coverage for fast-reroute. And the
solution can also be deployed uniformly in the core network using LDP
to achieve high scalability.
4.5. Policy Control
BGP as a route protocol for inter-AS now is used for Seamless MPLS to
establish end-to-end hierarchical LSP or deploy VPN services. BGP
route policy based on IP-Prefix or communities are usually used to
control the path. The design and configuration is complex and error-
prone. In fact, BGP in Seamless MPLS is used to propagate labeled
BGP routes across different domains to implement network convergence.
This means several contiguous BGP networks are under the uniform
administration. It is not like the traditional BGP networks which
may be under the administration of different service providers. In
this cases, thinking on the security of the network can be reduced.
On the contrary, when advertise routes in the Seamless MPLS domain,
it is desirable for BGP to carry more information to help select
routing more intelligently. It can reduce the cost proposed by
complex policy control design and be able to adapt to network change
easily.
4.6. OAM
Mobile Backhaul is a sensitive network on latency timer, packet loss
rate, performance and so on. Therefore, unified OAM mechanism is
necessary to ensure the end-to-end network management including fault
and performance management.
OAM mechanisms is complete and mature for L2VPN and MAC services.
However, L3VPN are introduced in the mobile backhaul network for
better scalability. The OAM mechanisms for IP and L3VPN is not
sufficient to satisfy the OAM requirement of the mobile service,
Zhenbin Li, et al. Expires August 17, 2014 [Page 18]
Internet-Draft Seamless MPLS for Mobile Backhaul February 2014
especially for performance monitoring. On the other hand, the
Seamless MPLS is in fact composed by multiple contiguous networks.
More convenient mechanisms should be introduced for maintenance of
the end-to-end path.
4.6.1. L3VPN PM
FMC becomes the requirement of mobile backhaul network and L3VPN is
introduced to get better scalability for service provisioning.
Unlike existing mature OAM mechanism based on PW for L2VPN, L3VPN
lacks of similar mechanisms to satisfy the SDH-like OAM requirement
for the mobile backhaul service. [I-D.zheng-l3vpn-pm-analysis]
analyzes the difficulty to implement performance monitoring for L3VPN
owing to its MP2P or MP2MP service models.
[I-D.dong-l3vpn-pm-framework] proposes the framework to implement
L3VPN PM. The point-to-point connection between two VRFs, called as
VRF-to-VRF tunnel, is established. Thus the existing MPLS OAM
mechanisms based on P2P LSP models can be reused for L3VPN.
4.6.2. IPFPM (IP Flow Performance Measurement)
It is lack of effective performance monitoring mechanisms for IP-
based mobile service. The existing PM mechanism can not guarantee
that the path of the injected OAM packets is same with the real
traffic. If out-of-order arrival of packets happens, the accuracy of
the measurement result will be affected negatively for the IP
service.
[I-D.chen-coloring-based-ipfpm-framework] defines a new performance
measurement mechanism for Service Level Agreement (SLA) verification
and trouble shooting (e.g., fault localization or fault delimitation)
named as IP Flow Performance Measurement (IPFPM). This measurement
mechanism can measure performance based on 5-tuple encapsulation
information of IP flow without injecting any extra OAM packet to the
flow. The accuracy of the measurement result can be guaranteed even
if out-of-order arrival of packets happens by setting one unused bit
of the IP header of packets to "color" the packets into different
color blocks. The solution can adapt to various IP based network
architecture (pure IP, L3VPN, etc.)
4.6.3. Service Path Visualization
Seamless MPLS provides an architecture to support end-to-end services
across multi-separated IP/MPLS domains. Existing path detect
technologies (e.g. IP/LSP Ping and Trace) can only trace the path in
different layers or different network segments. So it is ineffective
to get the end-to-end path combing these technologies for maintenance
of the network. On the other hand, existing technologies do not
Zhenbin Li, et al. Expires August 17, 2014 [Page 19]
Internet-Draft Seamless MPLS for Mobile Backhaul February 2014
encapsulate the same 5-tuple {source IP address, destination IP
address, source port number, destination port number, IP protocol
number} as the real traffic. This means the path maybe be different
between the OAM packets and the real flow's packets when there are
more than one outgoing paths and the forwarding decision is
determined by hash based on 5-tuple information in the IP packet.
According to these new requirements, the new solution should be
introduced to maintain the end-to-end path more conveniently.
5. IANA Considerations
This document makes no request of IANA.
6. Security Considerations
TBD.
7. Acknowledgements
The authors would like to thank Loa Andersson for his valuable
comments and suggestions on this draft. The authors would also like
to acknowledge the important contributions of Yuanbin Yin on IPFPM
and Service Path Visualization.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.chen-coloring-based-ipfpm-framework]
Chen, M., Liu, H., and Y. Yin, "Coloring based IP Flow
Performance Measurement Framework", draft-chen-coloring-
based-ipfpm-framework-01 (work in progress), February
2013.
[I-D.dong-l3vpn-pm-framework]
Dong, J., Li, Z., and B. Parise, "A Framework for L3VPN
Performance Monitoring", draft-dong-l3vpn-pm-framework-02
(work in progress), January 2014.
Zhenbin Li, et al. Expires August 17, 2014 [Page 20]
Internet-Draft Seamless MPLS for Mobile Backhaul February 2014
[I-D.ietf-mpls-seamless-mpls]
Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
M., and D. Steinberg, "Seamless MPLS Architecture", draft-
ietf-mpls-seamless-mpls-05 (work in progress), January
2014.
[I-D.ietf-pwe3-ms-pw-requirements]
Bocci, M. and L. Martini, "Requirements for Multi-Segment
Pseudowire Emulation Edge-to-Edge (PWE3)", draft-ietf-pwe3
-ms-pw-requirements-07 (work in progress), June 2008.
[I-D.li-ccamp-role-based-automesh]
Li, Z. and M. Chen, "Routing Extensions for Discovery of
Role-based MPLS Label Switching Router (MPLS LSR) Traffic
Engineering (TE) Mesh Membership", draft-li-ccamp-role-
based-automesh-01 (work in progress), October 2013.
[I-D.li-mpls-proxy-te-lsp]
Li, Z. and X. Zeng, "Proxy MPLS Traffic Engineering Label
Switched Path(LSP)", draft-li-mpls-proxy-te-lsp-00 (work
in progress), July 2013.
[I-D.li-mpls-serv-driven-co-lsp-fmwk]
Li, Z. and J. Dong, "A Framework for Service-Driven Co-
Routed MPLS Traffic Engineering LSPs", draft-li-mpls-serv-
driven-co-lsp-fmwk-02 (work in progress), January 2014.
[I-D.li-ospf-auto-mbb-te-path]
Li, Z., Zhang, L., and Y. Liu, "OSPF Extensions for
Automatic Computation of MPLS Traffic Engineering Path
Using Traffic Engineering Layers and Areas", draft-li-
ospf-auto-mbb-te-path-00 (work in progress), February
2013.
[I-D.li-rtgwg-ldp-mt-mrt-frr]
Li, Z., Chou, T., Zhao, Q., and T. Yang, "Applicability of
LDP Multi-Topology for Unicast Fast-reroute Using
Maximally Redundant Trees", draft-li-rtgwg-ldp-mt-mrt-
frr-02 (work in progress), April 2013.
[I-D.zheng-l3vpn-pm-analysis]
Zheng, L., Li, Z., Aldrin, S., and B. Parise, "Performance
Monitoring Analysis for L3VPN", draft-zheng-l3vpn-pm-
analysis-02 (work in progress), October 2013.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
Zhenbin Li, et al. Expires August 17, 2014 [Page 21]
Internet-Draft Seamless MPLS for Mobile Backhaul February 2014
[RFC4972] Vasseur, JP., Leroux, JL., Yasukawa, S., Previdi, S.,
Psenak, P., and P. Mabbey, "Routing Extensions for
Discovery of Multiprotocol (MPLS) Label Switch Router
(LSR) Traffic Engineering (TE) Mesh Membership", RFC 4972,
July 2007.
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Lei Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lily.lilei@huawei.com
Manuel Julian Lopez Morillo
Vodafone Group Networks
Parque Empresarial Castellana Norte. Isabel Colbrand 22
Madrid 28050
Spain
Email: manuel-julian.lopez@vodafone.com
Tianle Yang
China Mobile
32, Xuanwumenxi Ave.
Beijing 01719
China
Email: yangtianle@chinamobile.com
Zhenbin Li, et al. Expires August 17, 2014 [Page 22]
