Network Working Group Zhenbin Li
Internet-Draft Lei Li
Intended status: Informational Huawei Technologies
Expires: January 4, 2015 Manuel Julian Lopez Morillo
Vodafone Group Networks
Tianle Yang
China Mobile
L. Contreras
Telefonica I+D
July 3, 2014
Seamless MPLS for Mobile Backhaul Network
draft-li-mpls-seamless-mpls-mbh-00
Abstract
Seamless MPLS architecture is proposed to integrate access and
aggregation/core networks into a single MPLS domain. Through the
separation of the service and transport plane Seamless MPLS can
provide end to end service independent transport. But when the
mobile backhaul network is integrated as the access/aggregation
network with the core network based on Seamless MPLS architecture, it
will proposes new challenges other than the existing solutions for
Seamless MPLS. This document introduces the framework of Seamless
MPLS to integrate the mobile backhaul network and the core network.
The possible challenges of Seamless MPLS for mobile backhaul networks
are identified and new requirements are defined accordingly.
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
Zhenbin Li, et al. Expires January 4, 2015 [Page 1]
Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014
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.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Mobile Backhaul Network . . . . . . . . . . . . . 4
4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Scenarios for Network Architecture . . . . . . . . . . . 6
4.2. Scenarios for Different Edge of Labeled BGP . . . . . . . 8
5. Problem Statements and Requirements . . . . . . . . . . . . . 11
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 12
5.2.1. Problem Statements . . . . . . . . . . . . . . . . . 12
5.2.2. Requirements . . . . . . . . . . . . . . . . . . . . 13
5.3. End-to-End Transport . . . . . . . . . . . . . . . . . . 14
5.3.1. Problem Statement . . . . . . . . . . . . . . . . . . 14
5.3.2. Requirements . . . . . . . . . . . . . . . . . . . . 14
5.4. Hierarchical Service Bearing . . . . . . . . . . . . . . 15
5.4.1. Problem Statements . . . . . . . . . . . . . . . . . 15
5.4.2. Requirements . . . . . . . . . . . . . . . . . . . . 16
5.5. Reliability . . . . . . . . . . . . . . . . . . . . . . . 16
5.5.1. Problem Statements . . . . . . . . . . . . . . . . . 16
5.5.2. Requirements . . . . . . . . . . . . . . . . . . . . 16
5.6. Policy Control . . . . . . . . . . . . . . . . . . . . . 16
5.6.1. Problem Statements . . . . . . . . . . . . . . . . . 16
5.6.2. Requirements . . . . . . . . . . . . . . . . . . . . 17
5.7. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.7.1. Problem Statements . . . . . . . . . . . . . . . . . 17
5.7.2. Requirements . . . . . . . . . . . . . . . . . . . . 18
Zhenbin Li, et al. Expires January 4, 2015 [Page 2]
Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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
is the separation of the service and transport plane. Through it
Seamless MPLS can provide end to end service independent transport.
Therefore it removes the need for service specific configurations in
network transport nodes.
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 based on Seamless MPLS
architecture. Though some approaches of the existing Seamless MPLS
architecture 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 introduces the framework of Seamless MPLS to integrate
the mobile backhaul network and the aggregation/core network. The
possible challenges of Seamless MPLS for mobile backhaul networks are
identified and new requirements are defined accordingly. The
proposed requirements make it possible to work out the complete
solution for a flexible deployment of an end to end mobile backhaul
service delivery.
Currently, this document focuses on end to end unicast service
deployment. Multicast is out of scope of the document.
2. Terminology
This document uses the following terminology:
o ABR: Area Border Router
Zhenbin Li, et al. Expires January 4, 2015 [Page 3]
Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014
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
o UPE: Under Provider Edge
3. Overview of Mobile Backhaul Network
The typical mobile backhaul network is shown in the Figure 1. It
usually adopts ring topology to save fiber resource and it is always
divided into the aggregate network and the access network. In the
mobile backhaul network, Cell Site Gateways(CSGs) connect the eNodeBs
and RNC Site Gateways(RSGs) connect the RNCs. The mobile traffic is
transported from CSGs to RSGs.
Zhenbin Li, et al. Expires January 4, 2015 [Page 4]
Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014
----------------
/ \
/ \
/ \
+------+ +----+ Access +----+
|eNodeB|---|CSG1| Ring 1 |ASG1|-------------
+------+ +----+ +----+ \
\ / \
\ / +----+ +---+
\ +----+ |RSG1|----|RNC|
-------------| | Aggregate +----+ +---+
|ASG2| Ring |
-------------| | +----+ +---+
/ +----+ |RSG2|----|RNC|
/ \ +----+ +---+
/ \ /
+------+ +----+ Access +----+ /
|eNodeB|---|CSG2| Ring 2 |ASG3|------------
+------+ +----+ +----+
\ /
\ /
\ /
-----------------
Figure 1 Mobile Backhaul Network
Generally RNCs and eNodeBs connects the local mobile backhaul
network. In order to utilize the distributed resource, eNodeBs and
RNCs may be located in different networks. That is, the mobile
service must span multiple networks including the mobile backhaul
networks and the core network. In order to facilitate service
provision, Seamless MPLS architecture can be introduced to implement
the integration of the mobile backhaul networks and the core network.
[I-D.ietf-mpls-seamless-mpls] defines the possible requirements and
solutions for the integration of the access network and the
aggregation/core network into a single MPLS domain. 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. Morevover, devices
in existing mobile backhaul networks vary in capacity. So there will
be different application scenarios and new challenges when Seamless
MPLS architecture is applied for the mobile backhaul network.
Note: In order to ease the description, in the following section we
will use the PE to represent the CSG in the Seamless MPLS
Zhenbin Li, et al. Expires January 4, 2015 [Page 5]
Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014
architecture. In this document the PE and the CSG have the same
meaning.
4. 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.
4.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. And the mobile
backhaul network including the access network and the aggregation
network usually uses a private AS number just for local services. So
the integrated end-to-end service means to cross 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 2 Redundant ASBRs connected Back to Back
Zhenbin Li, et al. Expires January 4, 2015 [Page 6]
Internet-Draft Seamless MPLS for Mobile Backhaul Network July 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 can distribute the PE's /32 route from ASBRs to ingress PEs
in targeted 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 3 Integrated ASBRs
In this scenario, Seamless MPLS uses label distribution enabled IBGP
to establish the end-to-end BGP LSP to support services (that is, it
removes the requirement of EBGP sessions) (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).
Zhenbin Li, et al. Expires January 4, 2015 [Page 7]
Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014
o The integrated ASBR should support two different ASes and
redistribute the labeled IPv4 routes from one AS to neighboring
AS.
o IBGP can distributes the PE's /32 route from the integrated ASBRs
to ingress PEs in targeted AS.
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. In this scenario, the Core network is deployed in a same
AS with the access/aggregation network. And the core network,
aggregation network and access network are just separated by IGP
areas for the reason of scalability.
| Service |
|----------------------------------------|
| AS |
|----------------------------------------|
| IGP-X | IGP-Y |
|(Access/Aggregation)| (Core) |
|--------------------|-------------------|
| | |
+----+
... |ABR1|....
+----+ ........ +----+ ....... +----+
| PE |... ...| PE |
+----+ ..... ..... +----+
..... +----+ .....
...|ABR2|..
+----+
Figure 4 Integrated network in one AS
In this scenario, Seamless MPLS uses labeled IBGP to establish the
end-to-end BGP LSP to support services.
4.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 the 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 will be three possible scenarios.
Scenario 1: Cell Site/User PE devices as the edge of labeled BGP
Zhenbin Li, et al. Expires January 4, 2015 [Page 8]
Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014
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.
| 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 5 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 the access
network and BGP LSP in aggregation/core network to support end-to-end
services.
Zhenbin Li, et al. Expires January 4, 2015 [Page 9]
Internet-Draft Seamless MPLS for Mobile Backhaul Network July 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 6 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 January 4, 2015 [Page 10]
Internet-Draft Seamless MPLS for Mobile Backhaul Network July 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 7 Labeled BGP ended at ASBRs
5. Problem Statements and Requirements
5.1. Overview
Seamless MPLS in [I-D.ietf-mpls-seamless-mpls] describes an
architecture by deploying existing protocols like BGP, LDP and ISIS
to provides a highly flexible and a scalable architecture and the
possibility to integrate 100.000 of nodes. But more requirements for
provision of the mobile service and the specialty of the mobile
backhaul network proposes new challenges when Seamless MPLS is
applied:
1. Challenges from Ring Network
The mobile backhaul network always adopts the ring network
deployment. When CSGs access the ring topology and LDP is adopted as
the transport plane, there will be multiple hops from CSGs to ASGs/
RSGs which has effect on LDP DoD. Moreover the route loop may always
happens which will affect the network coverage of the possible IP
FRR/LDP FRR solutions such as LFA [RFC6571] for high reliability.
2. Challenges from MPLS TE
In the mobile backhaul network, in order to provide SDH-like service,
MPLS TE or MPLS TP technologies are always introduced instead of MPLS
LDP for transport of mobile service. When integrate the core network
Zhenbin Li, et al. Expires January 4, 2015 [Page 11]
Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014
and the mobile backhaul network, in the transport plane, the
interworking between LDP/BGP LSP and RSVP-TE is inevitable. It will
have much effect on the end-to-end transport, OAM, protection and
scalability.
3. Challenges from L3VPN
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
L2VPN PW. It needs simplification of flexible policy control and
providing complete OAM solutions in different layers.
5.2. Scalability
5.2.1. Problem Statements
There will be huge configuration when MPLS TE is adopted to transport
mobile service. 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. In
order to satisfy different requirements of the mobile service, it
will propose the configuration issues for MPLS TE:
1. Tunnel/LSP Configuration
Since rich set of traffic engineering attributes have to be specified
for MPLS TE tunnel and LSP, it has to configure these attributes at
the ingress node for each MPLS TE tunnel/LSP to satisfy the
requirements such as bandwidth guarantee, fast protection switch,
OAM, etc.
2. Path Constraints Configuration
In order to satisfy the requirement of path design for MPLS TE LSP,
it has to introduce additional configuration which will deteriorate
the configuration work for MPLS TE.
1) Return Path Issue of BFD for MPLS LSPs
In order for high reliability BFD for MPLS LSPs ([RFC5884]) can be
used to detect the possible failure fast which can trigger traffic
switch between the primary LSP and the backup LSP of a specific MPLS
TE tunnel. When BFD for MPLS LSPs is deployed, the return path of
BFD traffic may take an IP path which is different from the forward
path. The failure that happens in the return path may cause wrong
Zhenbin Li, et al. Expires January 4, 2015 [Page 12]
Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014
traffic switch. In order to solve the return path issue of BFD for
MPLS LSPs, it has to be guaranteed that the forward path and the
return path must be co-routed. For MPLS TE LSPs the explicit path
has to be configured for the forward LSP and the return LSP.
2) Completely disjointed primary and backup LSP
MPLS TE Hot-standby feature is always introduced to implement traffic
protection. That is, primary LSP and backup LSP are setup at the
same time for one MPLS TE tunnel. In order to achieve higher
reliability, it is requires that the primary and backup LSP should
not share any nodes and links. Thus when failure happens in the
primary path, the backup LSP can always take over the traffic. So it
has to introduce the additional path constraints configuration to
satisfy the requirements.
3) Avoid passing through different access rings
When the mobile traffic is transported from the CSG to the RSG, it is
expected that the path would not pass through multiple access rings.
Since the bandwidth of the access ring is always designed to satisfy
its own bandwidth requirement, if mobile traffic from other access
ring pass through, the access ring is prone to be overloaded which
will cause traffic loss owing to traffic congestion. It is complex
to satisfy the requirement using cost, link color or explicit path
configurations.
In order to cope with above issues, the complex traffic engineering
attributes configuration and path constraints configuration has to be
introduced for MPLS TE tunnel/LSP. Calculated using the typical MPLS
TE tunnel configuration, there will be hundreds of thousands of
command lines need to be configured for MPLS TE. Comparing with LDP,
the provision work for MPLS TE is time-consuming and error-prone
which has much negative effect on the scalability.
5.2.2. Requirements
When Seamless MPLS is applied to the mobile backhaul network, in
order to solve the configuration issue of MPLS TE to improve
scalability, following requirements are proposed:
REQ 01: It SHOULD avoid traffic engineering attributes configuration
for each MPLS TE tunnel/LSP. Auto tunnel mechanism SHOULD be
introduced for provision of MPLS TE tunnel.
REQ 02: It SHOULD simplify the path constraints configuration to cope
with the return path issue of BFD for MPLS LSPs.
Zhenbin Li, et al. Expires January 4, 2015 [Page 13]
Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014
REQ 03: It SHOULD simplify the path constraints configuration to
implement completely disjointed primary and backup LSP.
REQ 04: It SHOULD simplify the path constraints configuration to
avoid traffic passing through different access rings.
5.3. End-to-End Transport
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 the access nodes 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 4.2. This section
will introduces new challenges and requirements for MPLS TE and LDP
to implement stitching solution for the end-to-end transport.
5.3.1. Problem Statement
1. Proxy Egress MPLS TE LSP
In the typical Seamless MPLS architecture, LDP DoD are adopted to
setup the segment LSP which is stitched with BGP LSP. When MPLS TE
is adopted to deploy in the mobile backhaul network, it is necessary
to stitch the MPLS TE LSP set up in the mobile backhaul network and
BGP LSP in the core network at the stitching point. Since the actual
destination of the MPLS TE LSP may be not located in the local mobile
backhaul network, it has to set up the proxy egress MPLS TE LSP from
the CSG to the stitching point.
2. Multi-hop LDP DoD
In the typical Seamless MPLS architecture, the static route can be
configured for set up LDP DoD LSP. In addition, LDP Extension for
Inter-Area Label Switched Paths[RFC5283] can be introduced to reduce
the numbers of routes. 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 cannot configure the default route for setup of LDP
DoD LSP. If static routes are used, it will be troublesome to
configure static routes to a specific destination on all nodes in the
mobile backhaul network.
5.3.2. Requirements
REQ 11: It SHOULD set up MPLS TE proxy egress LSP to stitch with BGP
LSP to implement end-to-end transport.
Zhenbin Li, et al. Expires January 4, 2015 [Page 14]
Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014
REQ 12: It SHOULD simplify the route configuration to setup multi-hop
LDP DoD LSP.
5.4. Hierarchical Service Bearing
5.4.1. Problem Statements
Though Seamless MPLS can provide end to end service independent
transport and removes the need for service specific configurations in
network transport nodes, owing to the limited capability of access
nodes it may be necessary to introduce hierarchical MPLS-based
service bearing solutions.
+----+ +-----+ +-----+
..|ASG1| ...|ASBR1|-------|ASBR3|....
+----+ .... .+----+. +-----+ +-----+ +----+
| PE |.. ... ...| PE |
+----+ .....+----+ . +----+
.|ASG2|. . +-----+ +-----+ ..
+----+ ..|ASBR2|-------|ASBR4|..
+-----+ +-----+
| Hierarchy of 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
As shown in the above figure, the access nodes (PEs) may be not able
to update to support end to end transport, it can utilize the simple
hierarchical MPLS-based service bearing solutions such as Hierarchy
of VPN (HoVPN) to stitch two segmented VPNs at the ASG or ASBR to
establish a VPN service across different domains. The segmented VPN
can simply steer the traffic from the access nodes to the ASG or ASBR
with higher capability for complex process. This can also simplify
the process of access devices (CSGs) and reduce the capability
requirement on lower level network devices. Seamless MPLS is not to
stop hierarchical service bearing which may need service specific
configurations in network transport nodes. On the contrary, it is to
provide more flexibility for MPLS-based service bearing. Depending
Zhenbin Li, et al. Expires January 4, 2015 [Page 15]
Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014
on the characteristic of the mobile service, different hierarchical
service bearing solutions based on L2VPN or L3VPN should be adopted.
5.4.2. Requirements
In order to reduce the requirement on lower level network devices,
hierarchical MPLS-based service bearing solutions can be introduced
for mobile service. Following requirements are proposed:
REQ 31: Hierarchical L3VPN solutions MAY be introduced to bear
L3-based mobile service.
REQ 32: Hierarchical L2VPN solutions MAY be introduced to bear
L2-based mobile service.
5.5. Reliability
5.5.1. Problem Statements
The ring topology is always adopted in the mobile backhaul network.
The route loop will be bound to happen in the ring network when LFA
solution is applied. This means that the backup route does not exist
in specific nodes of the ring network according to LFA. Regarding
Remote LFA FRR [I-D.ietf-rtgwg-remote-lfa], though it can improve the
network coverage comparing with LFA, it still faces the route loop
challenges for the back path. In addition, when R-LFA is adopted,
there has to set up LDP remote sessions which will propose the
scalability issue for fast protection. 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.
5.5.2. Requirements
REQ 41: Scalable IP/LDP FRR solutions SHOULD be provided for the
purpose of 100% network coverage when LDP is used for transport of
mobile service.
5.6. Policy Control
5.6.1. Problem Statements
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.
Zhenbin Li, et al. Expires January 4, 2015 [Page 16]
Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014
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 case, consideration 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.
5.6.2. Requirements
REQ 51: BGP SHOULD be able to carry more information to facilitate
the route policy control.
5.7. OAM
5.7.1. Problem Statements
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
management and performance monitoring.
1. Layering OAM Framework for L3VPN Service
When VPN is used to bear mobile service, multiple layers come into
play for implementing the VPN service. This layering extends to the
set of OAM protocols that are involved in the ongoing maintenance and
diagnostics of VPN networks. The figure below depicts the OAM
layering, and shows which devices have visibility into what OAM
layer(s).
+---+ +---+
+--+ | | +---+ +---+ +---+ | | +--+
|CE|----|PE1|----| P |----| P |----| P |----|PE2|----|CE|
+--+ | | +---+ +---+ +---+ | | +--+
+---+ +---+
o--------o--------- Service OAM -------------o--------o
o----------- Network OAM -----------o
o-------o--------o---------o-------o Transport OAM
o-----o o-----o o-----o o-----o o-----o o-----o Link OAM
Figure 9 VPN OAM Layering
Zhenbin Li, et al. Expires January 4, 2015 [Page 17]
Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014
OAM mechanisms is relatively complete and mature for L2VPN services.
However, L3VPN are introduced in the mobile backhaul network for
better scalability. The multiple layers for an L3VPN service are as
follows:
- The Service Layer runs end to end between the sites that are being
interconnected by the L3VPN solution. It is always IP network.
- The Network Layer extends in between the L3VPN PE nodes and is
mostly transparent to the core nodes (except where Flow Entropy comes
into play). It leverages MPLS for service (i.e. VRF) multiplexing.
- The Transport Layer is dictated by the networking technology of the
PSN. It may be either based on MPLS LSPs or IP.
- The Link Layer is dependent upon the physical technology used.
Ethernet is a popular choice for this layer, but other alternatives
are deployed (e.g. POS, DWDM etc...).
The existing OAM mechanisms for IP and L3VPN is not sufficient to
satisfy the OAM requirement of the mobile service, especially for
performance monitoring.
2. Flat End-to-End OAM Mechanism
Seamless MPLS provides an architecture to support end-to-end services
across multi-separated IP/MPLS domains. Existing path detection
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 for maintenance of the network. On the
other hand, existing technologies do not 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.7.2. Requirements
REQ 61: Performance monitoring mechanism SHOULD be provided for the
IP flow.
REQ 62: Performance monitoring mechanism SHOULD be provided for the
VPN flow between a pair of L3VPN members.
Zhenbin Li, et al. Expires January 4, 2015 [Page 18]
Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014
REQ 63: The end-to-end path trace mechanism SHOULD be provided for
the IP flow to collect the whole path information in multiple layers.
6. IANA Considerations
This document makes no request of IANA.
7. Security Considerations
TBD.
8. 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.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[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-07 (work in progress), June 2014.
[I-D.ietf-rtgwg-remote-lfa]
Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S.
Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-06
(work in progress), May 2014.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension
for Inter-Area Label Switched Paths (LSPs)", RFC 5283,
July 2008.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010.
Zhenbin Li, et al. Expires January 4, 2015 [Page 19]
Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014
[RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B.,
Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free
Alternate (LFA) Applicability in Service Provider (SP)
Networks", RFC 6571, June 2012.
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 January 4, 2015 [Page 20]
Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014
Luis M. Contreras
Telefonica I+D
Ronda de la Comunicacion, Sur-3 building, 3rd floor
Madrid 28050
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
URI: http://people.tid.es/LuisM.Contreras/
Zhenbin Li, et al. Expires January 4, 2015 [Page 21]