Internet DRAFT - draft-zhang-i2rs-mbh-usecases
draft-zhang-i2rs-mbh-usecases
Network Working Group L. Zhang
Internet-Draft Z. Li
Intended status: Informational Huawei Technologies
Expires: January 5, 2015 D. Liu
China Mobile
S. Hares
Hickory Hill Consulting
L. Contreras
Telefonica I+D
July 4, 2014
Use Cases of I2RS in Mobile Backhaul Network
draft-zhang-i2rs-mbh-usecases-00
Abstract
In a mobile backhaul network, traditional configuration and diagnoses
mechanisms based 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.ietf-i2rs-architecture], an
alternative way is available to control the configuration and
diagnose the operational results. This document discusses the use
case for 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."
Zhang, et al. Expires January 5, 2015 [Page 1]
Internet-Draft Use Cases of I2RS in MBH July 2014
This Internet-Draft will expire on January 5, 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. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Topology Change Adaptation . . . . . . . . . . . . . . . . . 4
3.1. Frequently Access Network Topology Changes . . . . . . . 4
3.2. Requirements for I2RS . . . . . . . . . . . . . . . . . . 5
4. Application Configuration . . . . . . . . . . . . . . . . . . 5
4.1. Application Configuration . . . . . . . . . . . . . . . . 5
4.2. Requirements for I2RS . . . . . . . . . . . . . . . . . . 6
5. Route Policy Enforcement . . . . . . . . . . . . . . . . . . 7
5.1. Route Policy Description . . . . . . . . . . . . . . . . 7
5.2. Requirements for I2RS . . . . . . . . . . . . . . . . . . 8
6. Service Tunnel Implementation . . . . . . . . . . . . . . . . 9
6.1. Service Tunnel Description . . . . . . . . . . . . . . . 9
6.2. Requirements for I2RS . . . . . . . . . . . . . . . . . . 10
7. Protection Mechanism . . . . . . . . . . . . . . . . . . . . 10
7.1. Protection Mechanism Description . . . . . . . . . . . . 10
7.2. Requirements for I2RS . . . . . . . . . . . . . . . . . . 11
8. Network Monitoring . . . . . . . . . . . . . . . . . . . . . 11
8.1. Network Monitoring Description . . . . . . . . . . . . . 11
8.2. Requirements for I2RS . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative Reference . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
Zhang, et al. Expires January 5, 2015 [Page 2]
Internet-Draft Use Cases of I2RS in MBH July 2014
1. Introduction
In mobile backhaul network, traditional configuration and diagnoses
mechanisms based 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 needs to serve various radio access modes and applications across
2G/3G/LTE/5G, build various network architectures based on the number
of network devices or the integration of different Areas or
Autonomous System Numbers (ASNs), and support various network
protocols that can be adopted to meet different network requirements.
These needs make the mobile backhaul network configuration more and
more arduous.
Interface to the Routing System's (I2RS) Programmatic interfaces, as
defined in [I-D.ietf-i2rs-architecture], provides an alternative way
to control the configuration and diagnose the operational results.
The use cases described in this document cover the critical elements
of mobile backhaul networks, such as: application configuration,
route policy enforcement, service tunnel implementation, protection
mechanisms and network monitoring. The goal is to increase the
community's understanding of the mobile backhaul requirements for
I2RS in a the context of an entire network solution.
This draft notes unique I2RS Requirements in the draft with the
abbreviation "MBB-REQnn" where nn is the number of the requirements.
2. Definitions
I2RS: Interface to the Routing System
IGP: Interior Gateway Protocol
BGP: Border Gateway Protocol
MPLS: Multi-Protocol Label Switching
LDP: Label Distribution Protocol
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
Zhang, et al. Expires January 5, 2015 [Page 3]
Internet-Draft Use Cases of I2RS in MBH July 2014
SS-PW: Singe Segment PW
MS-PW: Multi-Segment PW
HVPN: Hierarchical VPN
EPC: Evolved Packet Core
LTE: Long Term Evolution
FRR: Fast Reroute
ECMP: Equal Cost Multi-path
3. Topology Change Adaptation
3.1. Frequently Access Network Topology Changes
As wireless becomes the primary or even sole access method for more
and more people, the mobile backhaul network must carry higher
volumes of traffic. Growing traffic has necessitated more and more
cells in the radio access networks (RANs) that provide mobile
subscribers with an onramp to wireless networks. Mobile operators
are turning to small-cell technology to increase capacity through
frequency reuse, especially in densely populated areas. Finally,
network capabilities must be highly scalable and agile, which lead to
more frequently topology change, such as:
o Change linear access network to ring access network
Whether the access network is linear or ring is based on the
optical links resource. The linear access network is less
reliable than ring. So when the optical links are ready, it
may be necessary to change linear access network to ring access
network.
o Add nodes for an access network
Every access network is deployed to cover a given region.
Along with the growth of wireless users, one access network may
add new nodes to accommodate more users.
o Split one ring access network into multiple linear or ring access
networks
The mobile traffic an access ring can bear is limited by the
device capability such as the route/LSP specification and the
bandwidth. When access users and traffic load are overloaded
Zhang, et al. Expires January 5, 2015 [Page 4]
Internet-Draft Use Cases of I2RS in MBH July 2014
in a ring access network, it may be necessary to split this
ring into multiple linear or ring access networks according to
the optical link resource.
o Add more access networks
This is the direct approach to cope with the growth of users
and traffic, especially when the small-cell technology is
introduced.
3.2. Requirements for I2RS
The devices in the access network have limited capability for route
and LSP specification, so the access network has to be divided into
different IGP domains to reduce the number of routes and LSPs. This
division into multiple IGPS has the benefit of isolating the impact
of failure among different convergence domains and decreasing the
time it takes to configure the IGP. Frequent changes of the access
network topology require fast provision of IGP domain deployment,
including both the whole IGP domain provision and the IGP
configuration on the individual node.
I2RS' programmatic interface would enable the IGP domain provisioning
to operate automatically and simultaneously to topology changes while
using global information of mobile backhaul network stored in a
central location.
MBH-REQ-01: The I2RS client-agent communication can distribute
position-critical changes to IGP nodes using this global knowledge to
quicken changes to support traffic during failures or traffic
overloads.
To enable this feature, the I2RS Clients-Agent communication needs to
pass information on which IGP process or Level or Area the given node
and links belong to.
4. Application Configuration
4.1. Application Configuration
The mobile backhaul network has evolved into an IP-based network,
which faces three main challenges in network construction:
1. various radio access modes:
To protect existing investment and end user resource, TDM/ATM-
based access modes belonging to 2G and 3G will coexist with
Ethernet-based access mode belonging to 3G, LTE, and 5G for an
Zhang, et al. Expires January 5, 2015 [Page 5]
Internet-Draft Use Cases of I2RS in MBH July 2014
extended time into the future. The radio architecture
evolution will bring out new radio interfaces, such as the X2
interface in LTE which will not work in hub-spoke
communication mode and needs much more shorter latency. A
mobile backhaul network must be built to have the ability to
adapt to all 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 networks, meaning 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 may 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[I-D.li-mpls-seamless-mpls-mbb], when EPC is deployed
in the Core network with 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. Within 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.
4. various traffic patterns
User applications run on mobile phones now encompass the full
range of user programs. Traffic from mobile phones may have
different requirements for bandwidth and application responses
(real-time, near real-time, non-real-time). This user traffic
combines with the mobile phone control traffic that keeps
tracks network usage and QoS.
4.2. Requirements for I2RS
The challenges in mobile backhaul network construction show the
flexibility and complexity requirements of network configuration and
modification, such as:
Zhang, et al. Expires January 5, 2015 [Page 6]
Internet-Draft Use Cases of I2RS in MBH July 2014
o where the T-LDP should be configured,
o where a BGP peer should be established,
o where the VPN instance should be deployed, and
o where the BGP-based LSP should be set up.
Faced with flat or reduced budgets, 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' programmatic interface would allow network
operators to distribute such configurations from a central location
where global mobile backhaul network solution provisioning
information could be stored.
MBH-REQ-02: I2RS must allow operators to use of I2RS clients to
distribute time-critical changes in configuration to I2RS agents
associated with each routing node. This feature will simplify and
automate configuration and monitoring of a mobile backhaul network to
allow it to readily adapt to changing network sizes (and scales) and
radio applications.
MBB-REQ-03: I2RS Clients-Agent communication needs to pass
information on:
o T-LDP configurations and status;
o BGP peer configurations, peer topologies and status;
o BGP-based LSP topologies and status;
o Reset VPN topologies, and per node configurations;
While a beginning exists in the I2RS RIB Information Model
[[I-D.ietf-i2rs-rib-info-model]] which includes in the route
interfaces with MPLS LSP or VPN technology, additional features need
to be added to support mobile backhaul networks.
5. Route Policy Enforcement
5.1. Route Policy Description
The route policy in mobile backhaul networks mainly refers to BGP
policy when L3VPN is used to serve the radio applications. The
complexity of the existing network architecture and radio interfaces
make it very difficult to apply a network-wide route policy, for:
Zhang, et al. Expires January 5, 2015 [Page 7]
Internet-Draft Use Cases of I2RS in MBH July 2014
o avoiding route advertisement across entire network
When a mobile backhaul network contains more than 500 nodes,
utilizing a multi-segments service like HVPN is recommended to
reduce the routing and protocol processing overhead 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 limited capability, while advertising to the
whole network routes to the core nodes which must have
capability to store large number of 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 relies on BGP Policy using Local Preference, MED or
other path attributes defined in [RFC4760]. When a BGP RR is
adopted to simplify the BGP peer architecture from full-mesh
mode, the policy would become more complex, in some cases may
make be per-peer or per-route worse.
o allowing On-demand route advertisement
The advent of X2 interfaces in LTE, which need specific route
information between any two access nodes, makes the network
route advertisement more dynamic and unpredictable. The BGP
policy should be adjusted dynamically to meet this route
advertisement need across the entire network.
5.2. Requirements for I2RS
MBB-REQ04: Route policy enforcement in mobile backhaul networks needs
to be more dynamic and flexible than the current methods take hours
(or even days) to configure route policy across a network.
The I2RS interface must provide a programmatic way to configure (both
policy and device) and monitor thousands of devices individually
whose configuration is based on the devices role (such as ASRSs in
one AS, ASBRs between ASs and other service-touch nodes).
MBB-REQ-05: I2RS clients should be able to contact I2RS agents on
nodes to query role-based information from the network status. After
collecting the status, the I2RS client can develop the BGP policies
based on role information and push the BGP policies to the I2RS
agents that would load the alternate policies into the network
device. The I2RS Agents loading the alternate policies could then
send status back to the I2RS Client.
Zhang, et al. Expires January 5, 2015 [Page 8]
Internet-Draft Use Cases of I2RS in MBH July 2014
6. Service Tunnel Implementation
6.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 networks and
aggregate/core networks. If needed, the longest length match
defined in [RFC5283] for LDP LSP should be supported. MPLS LDP
LSP has excellent scalability with flexible policy to control
the label advertisement of route, especially in DU mode, to
decrease needless LSPs 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
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 as
integrated across access network and aggregate/cores 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 networks, the LSP selection depends
on the service need, and the creation of MPLS-TP LSP is always
assumed to be decoupled with the protocol control plane running
on separate network devices. Ideally, the static MPLS-TP LSP
should be designed and configured on the centralized control
plane.
Zhang, et al. Expires January 5, 2015 [Page 9]
Internet-Draft Use Cases of I2RS in MBH July 2014
6.2. Requirements for I2RS
The mobile backhaul network is divided into an access network and an
aggregation/core network where service tunnel implementation is not
constant and unique. Therefore, it may be necessary to deploy
different kind of LSPs separately (such as LDP LSP or MPLS-TE LSP in
both access network and aggregate/core networks) or simultaneously
(such as MPLS-TP static LSP in access network while LDP LSP or MPLS-
TE LSP in aggregate/core network). Network operators need to know
the ability of all of the network devices and the service
requirements to make the most appropriate tunnel implementation.
MBH-REQ06: I2RS clients can provide centralized control of many
network devices via the I2RS Client-Agent communication. The I2RS
programmatic interface can automate the collection and analysis of
each device's capability so that the centralized I2RS client could
calculate the optimal LSP path and distribute the configuration to
individual devices. Automation of the collection of device
capability should be available as query, notification, or a published
stream.
MBH-REQ07: While the I2RS RIB Information Model
[[I-D.ietf-i2rs-rib-info-model]] provides for routes with tunnels or
MPLS LSP, the features defined in this model are not sufficient to
configure both types of LSPs needed for the VPN technology in mobile
backhaul networks. Additional I2RS Informational models need to be
created to support these features.
7. Protection Mechanism
7.1. Protection Mechanism Description
The SLA for radio services is strict, which requires 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 mechanisms of different tunnel protocols,
mentioned above, are different from each other. To enhance
the reliability, LDP LSP should configure LDP FRR, which is
calculated depending on the protect route algorithm, and be
Loop-Free Algorithm (LFA), Remote-LFA, or Maximally Redundant
Trees (MRT) used together with LDP MT as 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
Zhang, et al. Expires January 5, 2015 [Page 10]
Internet-Draft Use Cases of I2RS in MBH July 2014
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 recommended 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.
7.2. Requirements for I2RS
MBH-REQ08: The hierarchical protection architecture in mobile
backhaul network offer high network reliability and more flexibility
to meet the various needs of the tunnels and services. The I2RS
interface in this use case is needed to automate the configuration
and monitoring so that tunnel protection and service protection
interwork in a flexible and reliable manner.
8. Network Monitoring
8.1. Network Monitoring Description
The mobile backhaul network operators requires to determine the
accurate cause as fast as possible when a link or node failure occurs
and get the real reason for service quality degradation. For this,
different network monitor tools are introduced for different service
mode ( MPLS-TP OAM for section or LSP, Y.1731 for PW , IP Flow
Performance Monitor (IPFPM) for IP service, etc.). The network
operators should decide what a combination of multi-layer network
monitor tools should be deployed, and what the exact detection
parameters for these tools should be provisioned. Meanwhile, the
network devices should report the detection result to the controller,
which is used to analyze the network status.
8.2. Requirements for I2RS
MBB-REQ09: The I2RS architecture (client-agent) should allow the two
features for network monitoring naturally in its basic modes:
o allow a combination of multi-layer network monitor tools with
exact detection parameters to be configured on the network device
o Facilitate the reporting the detection result as notification or
publication stream
It is important the result of these features allow the outages and
traffic congestion or discards to be detected real-time with I2RS
Zhang, et al. Expires January 5, 2015 [Page 11]
Internet-Draft Use Cases of I2RS in MBH July 2014
Client(s) in each node, and the detection result will be reported to
the I2RS agents to get the exact status of the network.
9. Security Considerations
The mobile backhaul network use cases described in this document
assumes use of I2RS' programmatic interfaces described in the I2RS
framework mentioned in[I-D.ietf-i2rs-architecture]. This document
does not change the underlying security issues inherent in the
existing [I-D.ietf-i2rs-architecture].
10. References
10.1. Normative References
[I-D.ietf-i2rs-architecture]
Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing
System", draft-ietf-i2rs-architecture-04 (work in
progress), June 2014.
[I-D.ietf-i2rs-rib-info-model]
Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing
Information Base Info Model", draft-ietf-i2rs-rib-info-
model-03 (work in progress), May 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative Reference
[I-D.ietf-mpls-ldp-multi-topology]
Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D.
King, "LDP Extensions for Multi Topology", draft-ietf-
mpls-ldp-multi-topology-12 (work in progress), April 2014.
[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-01
(work in progress), February 2014.
[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 January 5, 2015 [Page 12]
Internet-Draft Use Cases of I2RS in MBH July 2014
[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.com
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
Susan Hares
Hickory Hill Consulting
7453 Hickory Hill
Saline, MI 48176
USA
Email: shares@ndzh.com
Zhang, et al. Expires January 5, 2015 [Page 13]
Internet-Draft Use Cases of I2RS in MBH 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/
Zhang, et al. Expires January 5, 2015 [Page 14]
