One document matched: draft-zhang-i2rs-mbb-usecases-00.txt
Network Working Group L. Zhang
Internet-Draft Z. Li
Intended status: Informational Huawei Technologies
Expires: April 24, 2014 D. Liu
China Mobile
October 21, 2013
Use Cases of I2RS in Mobile Backhaul Network
draft-zhang-i2rs-mbb-usecases-00
Abstract
In mobile backhaul network, traditional configuration and diagnoses
mechanisms base on device-level management tools and manual
processing are ill-suited to meet the requirements of today's
scalable, flexible, and complex network. Thanks to the new
innovation of Interface to the Routing System's (I2RS) programmatic
interfaces, as defined in [I-D.ward-i2rs-framework], an alternative
way has been rolled out to control the configuration and diagnose the
operation results. This document discusses the use case of I2RS in
mobile backhaul network.
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 April 24, 2014.
Copyright Notice
Zhang, et al. Expires April 24, 2014 [Page 1]
Internet-Draft Use Cases of I2RS in MBB October 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. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Application Configuration . . . . . . . . . . . . . . . . . . 4
3.1. Application Configuration . . . . . . . . . . . . . . . . 4
3.2. Requirements for I2RS . . . . . . . . . . . . . . . . . . 5
4. Route Policy Enforcement . . . . . . . . . . . . . . . . . . 5
4.1. Route Policy Description . . . . . . . . . . . . . . . . 5
4.2. Requirements for I2RS . . . . . . . . . . . . . . . . . . 6
5. Service Tunnel Implementation . . . . . . . . . . . . . . . . 6
5.1. Service Tunnel Description . . . . . . . . . . . . . . . 6
5.2. Requirements for I2RS . . . . . . . . . . . . . . . . . . 7
6. Protection Mechanism . . . . . . . . . . . . . . . . . . . . 7
6.1. Protection Mechanism Description . . . . . . . . . . . . 7
6.2. Requirements for I2RS . . . . . . . . . . . . . . . . . . 8
7. Network Monitoring . . . . . . . . . . . . . . . . . . . . . 8
7.1. Network Monitoring Description . . . . . . . . . . . . . 8
7.2. Requirements for I2RS . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative Reference . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
In mobile backhaul network, traditional configuration and diagnoses
mechanisms base on device-level management tools and manual
processing are ill-suited to meet the requirements of today's
scalable, flexible, and complex network. The mobile backhaul network
now need to serve various radio access modes and applications across
2G/3G / LTE/5G, build various network architectures based on the
amount of network devices or the integration of different Areas or
Autonomous System Numbers (ASNs), and support various network
Zhang, et al. Expires April 24, 2014 [Page 2]
Internet-Draft Use Cases of I2RS in MBB October 2013
protocols can be adopted to meet different network requirements,
which make the mobile backhaul network configuration more and more
arduous.
Interface to the Routing System's (I2RS) Programmatic interfaces, as
defined in [I-D.ward-i2rs-framework], provides an alternative way to
control the configuration and diagnose the operation results. The
use cases described in this document cover the critical elements of
mobile backhaul network, such as: application configuration, route
policy enforcement, service tunnel implementation, protection
mechanism and network monitoring. The goal is to inform the
community's understanding of the mobile backhaul requirements for
I2RS in a viewpoint of entire network solution.
2. Definitions
I2RS: Interface to the Routing System
IGP: Interior Gateway Protocol
BGP: Border Gateway Protocol
MPLS: Multi-Protocol Label Switching
LDP: Equal Cost Multi-path
RSVP-TE: Resource Reservation Protocol Traffic Engineering
PWE3: Pseudo Wire Emulation Edge-to-Edge
VPN: Virtual Private Network
L2VPN: L2 Virtual Private Network
L3VPN: L3 Virtual Private Network
SS-PW: Singe Segment PW
MS-PW: Multi-Segment PW
HVPN: Hierarchical VPN
EPC: Pseudo Wire Emulation Edge-to-Edge
LTE: Long Term Evolution
FRR: Fast Reroute
Zhang, et al. Expires April 24, 2014 [Page 3]
Internet-Draft Use Cases of I2RS in MBB October 2013
ECMP: Equal Cost Multi-path
3. Application Configuration
3.1. Application Configuration
The mobile backhaul network has evolved into an IP-based network,
which faces three main challenges in network construction, including:
1. various radio access modes:
Due to protect existing investment and end user resource, TDM/
ATM-based access mode belongs to 2G and 3G will coexist with
Ethernet-based access mode belongs to 3G, LTE and 5G for a
long period in future. The radio architecture evolution will
bring out new radio interfaces, such as X2 interface in LTE
which will not work in hub-spoke communication mode any more
while needs much more shorter time delay. A mobile backhaul
network must be built to have the ability to adapt to all of
the mobile access modes, providing PWE3 service for TDM /ATM-
based access mode and Native IP/Ethernet, PWE3/VPLS or L3VPN
service for IP-based access mode.
2. various radio applications:
A variety of radio applications (such as OM, signaling, data,
video, etc. ) which have different quality of services (QoS),
should be delivered in specific service channels in mobile
backhaul network, that means there will be more than one PW or
L3VPN instances binding with specific interfaces and service
tunnels.
3. various network architectures:
The mobile backhaul network maybe consist of hundreds of nodes
in a small county or thousands of nodes in a populous region.
It will be an integration of different ASNs rather than a
single AS, when the EPC is deployed in the Core network when
LTE. The network devices on different points of the network
(e.g. access\aggregation\core) have different routing and
protocol processing capabilities, resulting in an integration
of different IGP routing areas rather than a single large IGP
routing area. Refer to various network architectures,
different service modes should be provided, such as SS- PW or
MS-PW, E2E L3VPN or HVPN, Seamless MPLS, and the integration
of them.
Zhang, et al. Expires April 24, 2014 [Page 4]
Internet-Draft Use Cases of I2RS in MBB October 2013
3.2. Requirements for I2RS
The challenges in mobile backhaul network construction show the
flexibility and complexity requirements of network configuration and
modification, such as where the T-LDP should be configured, where the
BGP peer should be established, where the VPN instance should be
deployed, and where the BGP LSP should be set up. Faced with flat or
reduced budget, the network operators are trying to squeeze the most
from their network using device-level management tools and manual
processing. In contrast to management of entire network devices,
I2RS' programmable interface would allow network operators to
distribute such configuration from a central location where a global
mobile backhaul network solution provisioning information could be
stored. Use of I2RS controllers to announce network configuration
information would simplify and automate configuration of mobile
backhaul network that readily adapt to changing network scales and
radio applications.
4. Route Policy Enforcement
4.1. Route Policy Description
The route policy in mobile backhaul network mainly refers to BGP
policy when L3VPN is used to serve the radio applications. The
complexity of today's network architecture and radio interfaces make
it very difficult to apply a network-wide route policy, for:
o avoiding route advertisement across entire network
When a mobile backhaul network contains more than 500 nodes,
complementing a multi-segments service like HVPN is recommended
to reduce the routing and protocol processing quantity of
network devices. BGP policy should be configured with prefix
filters to advertise only the default or aggregate route to the
access nodes which have poor capability, while to advertise the
whole network routes to the core nodes which must have
capability of fairly large routes.
o supporting best route selection for VPN FRR or ECMP
The mobile backhaul network is recommended to be built with a
multi-homed network architecture for node failure protection,
where VPN FRR or ECMP should be configured. The best route
selection relay on the BGP Policy using Local Preference, MED
or other path attributes defined in [RFC4760]. When BGP RR is
adopted to simplify the BGP peer architecture from full-mesh
mode, the policy would be more complex, in some cases may be
per-peer or per-route more worse.
Zhang, et al. Expires April 24, 2014 [Page 5]
Internet-Draft Use Cases of I2RS in MBB October 2013
o allowing On-demand route advertisement
The advent of X2 interface in LTE, which needs specific route
information between any two access nodes, make the network
route advertisement more dynamically and unpredictably. The
BGP policy should be adjusted dynamically to meet this route
advertisement need across the entire network.
4.2. Requirements for I2RS
Route policy enforcement in mobile backhaul network need to be much
more dynamical and flexible, and when to implement a network-wide
route policy, network operators should configure thousands of devices
with different policy details individually according to the role of
the devices, such as ASRs in one AS, ASBRs between different ASs and
other service-touch nodes. It will take hours, in some cases days to
configure the route policy across the entire network. I2RS
controllers could use common APIs to collect network information
required to create different BGP policies dynamically, then push such
policy onto the corresponding network device, and make it tack effect
automatically.
5. Service Tunnel Implementation
5.1. Service Tunnel Description
In mobile backhaul network, more than one kind of Service Tunnel can
be used according to network ability or other consideration in
different scenarios. The Tunnel deployment use case in mobile
backhaul includes:
o MPLS LDP LSP
MPLS LDP LSP is set up through LDP protocol. Both Label
Advertisement Mode of Downstream Unsolicited (DU) and
Downstream on Demand (DOD) defined in [RFC3036] can be used
individually or integrated across access network and aggregate/
core network. If needed, the longed length match define in
[RFC5283] for LDP LSP should be supported. MPLS LDP LSP has
great scalability with flexible policy to control the label
advertisement of route, especially in DU mode, to decrease the
needless LSPs, that is help to reduce the LSP capability
requirement of network devices.
o MPLS-TE LSP
MPLS-TE LSP is set up through RSVP-TE protocol, which has
multiple path control attributes (such as explicit-path, path
Zhang, et al. Expires April 24, 2014 [Page 6]
Internet-Draft Use Cases of I2RS in MBB October 2013
affinity property , path bandwidth assurance , path hop
limitation, e.g.) and multiple protection modes (such as hot-
standby, Fast Re-Route, protection group, e.g.). MPLS-TE LSP
should be designed using the attributes and protection modes
according to the requirements of the service delivery
individually of integrated across access network and aggregate/
core network.
o MPLS-TP LSP
MPLS-TP includes unidirectional LSP, bidirectional co-routed
LSP, and bidirectional associated LSP, which can be calculated
and set up manually or using dynamic network protocols such as
GMPLS. In mobile backhaul network, the LSP selection depends
on the service need, and the creation of MPLS-TP LSP is always
asked to be decoupled with the protocol control plane running
on the separate network devices. In this case, the static
MPLS-TP LSP should be designed and configured on the
centralized control plane ideally.
5.2. Requirements for I2RS
Since mobile backhaul network is divided into access network and
aggregation/core network, where service tunnel implementation is not
constant and unique, perhaps need to deploy different kind of LSPs
separately (such as LDP LSP or MPLS-TE LSP in both access network and
aggregate/core network) or simultaneously (such as MPLS-TP static LSP
in access network while LDP LSP or MPLS-TE LSP in aggregate/core
network). in this case, network operators should clearly know the
ability of all of the network devices and the service requirements to
make the most appropriate tunnel implementation. I2RS provide a
centralized control of network devices, which should automate the
collection and analysis of the device ability to calculate optimal
LSP path and distribute the configuration to exact devices.
6. Protection Mechanism
6.1. Protection Mechanism Description
The SLA for radio services is strict, which need interworking among
multiple protection mechanisms. Two critical aspects should be taken
into account for inter-working, hierarchical protection architectures
and multiple OAM protocol interactions.
1. tunnel protection:
The protection mechanism of different tunnel protocols,
mentioned above, is different from each other. To enhance the
Zhang, et al. Expires April 24, 2014 [Page 7]
Internet-Draft Use Cases of I2RS in MBB October 2013
reliability, LDP LSP should configure LDP FRR, which is
calculated depends on the protect route algorithm, which can
be Loop-Free Algorithm (LFA), Remote-LFA, or Maximally
Redundant Trees (MRT) used together with LDP MT described in
[I-D.ietf-mpls-ldp-multi-topology]. MPLS-TE LSP should apply
TE Fast Reroute or TE hot-standby. When MPLS-TP LSP is used,
the LSP protection group should be configured with 1:1 or 1+1
mode for MPLS-TP line protection, as well as wrapping or
steering modes fault processing for MPLS-TP ring protection.
2. service protection:
Service protection is commended to be configured for node
failure handover in mobile backhaul network, where PW
redundancy defined in [RFC6718] or BGP VPN FRR or ECMP
realization should be deployed exactly.
6.2. Requirements for I2RS
The hierarchical protection architecture in mobile backhaul network
offer high network reliability but more flexibility to meet the
various needs of the tunnels and services. I2RS interface in this
use case is needed to automate the configuration and make tunnel
protection and service protection interwork with each other ideally.
7. Network Monitoring
7.1. Network Monitoring Description
The mobile backhaul network operators are asked to give an accurate
positioning when a link or node failure occurred, and get the real
reason for service quality descent. This need to apply different
network monitor tools for different service mode, like Network
Quality Analysis (NQA), MPLS-TP OAM, and IP Flow Performance Monitor
(IPFPM). In addition, to acquire the exact traffic path is really
significant when use IPFPM for point-to-point detection.
Multiple monitor tools require network operators to distinguish
granular traffic flow to apply the appropriate one. At the same
time, traditional device-level management tools is difficult to get
the traffic path, which may need enhance the existing protocols or
design a new specific protocol to do this work, both will increase
the burden of mobile backhaul network.
7.2. Requirements for I2RS
I2RS should solve the two problems mentioned above naturally by using
centralized controllers, which control and manage the entire network
Zhang, et al. Expires April 24, 2014 [Page 8]
Internet-Draft Use Cases of I2RS in MBB October 2013
devices and store the whole routing and service information directly.
Meanwhile, the defect and traffic congestion or dropping can be
detected real-time with I2RS, which make the network keep optimal
state dynamically all the time.
8. Security Considerations
The mobile backhaul network use cases described in this document
assumes use of I2RS's programmatic interfaces described in the I2RS
framework mentioned in[I-D.ward-i2rs-framework]. This document does
not change the underlying security issues inherent in the existing
[I-D.ward-i2rs-framework].
9. References
9.1. Normative References
[I-D.ward-i2rs-framework]
Atlas, A., Nadeau, T., and D. Ward, "Interface to the
Routing System Framework", draft-ward-i2rs-framework-00
(work in progress), February 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative Reference
[I-D.ietf-mpls-ldp-multi-topology]
Zhao, Q., Fang, L., Zhou, C., Li, L., and K. Raza, "LDP
Extensions for Multi Topology Routing", draft-ietf-mpls-
ldp-multi-topology-09 (work in progress), October 2013.
[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-04 (work in progress), July 2013.
[I-D.li-mpls-seamless-mpls-mbb]
Li, Z., Li, L., Morillo, M., and T. Yang, "Seamless MPLS
for Mobile Backhaul", draft-li-mpls-seamless-mpls-mbb-00
(work in progress), July 2013.
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, January
2007.
Zhang, et al. Expires April 24, 2014 [Page 9]
Internet-Draft Use Cases of I2RS in MBB October 2013
[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension
for Inter-Area Label Switched Paths (LSPs)", RFC 5283,
July 2008.
[RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire
Redundancy", RFC 6718, August 2012.
Authors' Addresses
Li Zhang
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: monica.zhangli@huawei.comZ
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Dapeng Liu
China Mobile
Unit2, 28 Xuanwumenxi Ave,Xuanwu District
Beijing 100053
China
Email: liudapeng@chinamobile.com
Zhang, et al. Expires April 24, 2014 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 20:23:07 |