Internet DRAFT - draft-bogdanovic-nmrg-mobile-backhaul-use-case
draft-bogdanovic-nmrg-mobile-backhaul-use-case
UCAN BOF D. Bogdanovic
Internet-Draft Juniper Networks
Intended status: Informational June 23, 2014
Expires: December 25, 2014
Autonomic Networking in mobile wireless backhaul
draft-bogdanovic-nmrg-mobile-backhaul-use-case-00
Abstract
Mobile backhaul networks that utilize microwave technology in
transport are suspicious to seasonal and/or meteorological changes.
For those reasons throughput can vary significantly. This draft
provides problem statement and how autonomic networking can be
applied to the problem.
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 December 25, 2014.
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.
Bogdanovic Expires December 25, 2014 [Page 1]
Internet-Draft An Use Case June 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 2
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Intended User and Administrator Experience . . . . . . . . . 3
4. Analysis of Parameters and Information Involved . . . . . . . 4
4.1. Parameters each device can decide for itself . . . . . . 4
4.2. Information needed from policy intent . . . . . . . . . . 5
5. Interaction with other devices . . . . . . . . . . . . . . . 6
5.1. Information needed from other devices . . . . . . . . . . 6
5.2. Monitoring, diagnostics and reporting . . . . . . . . . . 7
6. Comparison with current solutions . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Microwave technology is one of the workhorses in MBH networks today.
Unlicensed microwave links can be set up in days rather than the
weeks or months it might take to implement additional wireline
capacity for backhaul. Even licensed links, while requiring some
mildly time-consuming bureaucratic approval, still easily outpace the
time-to-deployment of wireline alternatives. Fiber may offer
unlimited bandwidth, but the tradeoff is in time and cost savings.
Microwave's improvements in bandwidth, capacity, and reliability in
the past few years have made it an ideal interim broadband
connectivity solution during the often lengthy process of deploying
fiber. In fact, these improvements go as far as to establish
microwave as a legitimate permanent alternative to fiber. Although
its many benefits, because of other restrictions that microwave links
have, they can't be utilized at maximum. OSPF/MPLS networks that are
overlayed on top of microwave transport and provide additional
benefits of packet routing and switching to mobile backhaul.
1.1. Definitions and Acronyms
MBH: Mobile Backhaul
BTS: Base Transceiver Station
OSPF: Open Shortest Path First
MPLS: Multi Protocol Label Switching
Bogdanovic Expires December 25, 2014 [Page 2]
Internet-Draft An Use Case June 2014
PLMN: Public Land Mobile Networks
CoS: Class of Service
MTTR: Mean Time To Recovery
MNO: Mobile Network Operator
IDU: In Door Unit
ODU: Out Door Unit
SNMP: Simple Network Management Protocol
IP: Internet Protocol
IPv4: Internet Protocol version 4
IPv6: Internet Protocol version 6
2. Problem Statement
Mobile backhaul (MBH) networks utilize microwave networks to
transport traffic back to Public Land Mobile Networks (PLMN). Base
transceiver stations (BTS) and/or eNodeBs connect to a device that
has multiple microwave connections to PLMN. Not each link has the
same throughtput and the quality of the link varies with different
factors,like air temperature, percipitation, vegetation, etc. Today
those networks are overlayed with OSPF/MPLS networks and although
OSPF provides automatic redirection of traffic in case of primary
link failure, it reduces network throughput, as microwave link
bandwidth slowly degrades, due to rain, snow, tower bending due to
wind and/or temperature, vegatation growing. During the link
degradation period, the throughput of MBH part is going down and the
overall service is impacted. Being able to detect the degradation of
the microwave link bandwidth and redirect traffic over higher
throughput links is very beneficial to mobile network operators.
3. Intended User and Administrator Experience
As MBH links are lowering the bandwidth, the user experience is
impacted, as the data hungry applications are not served with usual
quality of service and latency is increasing, due to dropped packets.
MBH network administrator are not getting real time picture (usually
today they see average link performance over 15 minutes period) and
with users being highly mobile, they can't react to the challenges in
the network. Administrators should be able to set intended policy on
device, based on which device wwould start changing network
Bogdanovic Expires December 25, 2014 [Page 3]
Internet-Draft An Use Case June 2014
forwarding parameters based on which the current traffic would be
routed via links with moste throughput. With monitoring the link
statistics, device can change forwarding and routing parameters in
realtime based on the intended policy pushed on the device, without
the need to interact with centralized management system, which would
act based on sent link performance indicators. Such a network would
improve end user experience, as well network administrators would be
able to create better performing networks.
4. Analysis of Parameters and Information Involved
Numerous parameters are involved in monitoring MBH, from microwave
link performance, to miscellaneous OSFP and MPLS parameters. MNO has
to look at KPI that will relate to those that may impact revenue
negatively, such as unavailability and MTTR. One thing to note here
is that much emphasis is usually placed on availability, while most
times not enough emphasis is placed on reliability. In defining Key
Performance Indicators effectively, KPIs must align with BTS
availability information for a mobile operator.
Microwave transmission
o availability
o capacity
o delay
o jitter
4.1. Parameters each device can decide for itself
All OSPF interfaces have a cost, which is a routing metric that is
used in the link-state calculation. Routes with lower total path
metrics are preferred to those with higher path metrics. OSPF
assigns a default cost metric of 1 to reference bandwidth and default
cost metric of 0 to the loopback interface (lo0). No bandwidth is
associated with the loopback interface. So if reference bandwidth is
set to 1Gbps, it means that all interfaces faster than 1Gbps have the
same default cost metric of 1. If multiple equal-cost paths exist
between a source and destination address, OSPF routes packets along
each path alternately, in round-robin fashion.
Having the same default metric might not be a problem if all of the
interfaces are running at the same speed. In MBH, microwave units
will connect via ethernet to ethernet ports on routers and each link
will have the same metric. That would not be a problem if all
microwave links would have same performance, but links operate at
Bogdanovic Expires December 25, 2014 [Page 4]
Internet-Draft An Use Case June 2014
different speeds, and it is very probable that traffic is not routed
over the fastest interface because OSPF equally routes packets across
the different interfaces.
The autonomic agent agents collects operational statistics from
ethernet ports to which microwave IDU is connected, as well from
microwave ODU (local and remote) using SNMP. By collecting this
statistics, optimal MBH OSPF agent can callculate links with best
performance and change the metric value for each link accordingly.
+-------------------------------------------------------+ +------+
| +----------+ +--------------+ | | MW |
| | | | SNMP Agent |<---------------|->| IDU |
| | Intent | | |<---------- | +------+
| +----------+ +--------------+ \ |
| ^ ^ \ | +------+
| | | ---|->| MW |
| +-----> Autonomic User Agent <--------+ | | ODU |
| | | | | +------+
| V V V |
| +-----+------+ +--------------+ +---------+ |
| | | |Optimal MBH | |Ethernet | |
| | Performance|<---->|OSFP Selection| |Interface| |
| | topology | | Agent | |Counters | |
| | | | | | | |
| +------------+ +--------------+ +---------+ |
| ^ ^ |
| | | |
| V V |
|-------------------------------------------------------|
| Control Plane |
|-------------------------------------------------------|
| Standard Operating System Functions |
+-------------------------------------------------------+
Figure 1
4.2. Information needed from policy intent
The section describers what information is needed to be provided by
external entity, so that devices can operate autonomicly. The policy
would have to set:
o reference bandwidth - example 1Gbps
o low water mark threshold, at which point to change the metric
Bogdanovic Expires December 25, 2014 [Page 5]
Internet-Draft An Use Case June 2014
o IP address or addresses of local IDU
o IP address or addresses of local ODU
o IP address or addresses of remote IDU
o IP address or addresses of remote ODU
o which ethernet port is connect to which microwave link
This list is not extensive and with more research it can be augmented
with new parameters. The experience will show what parameters are
important. There might be a need to put time restrictions between
metric updates on the device or how often are statistics collected,
as it is important not to negatively effect device forwarding
capabilities.
5. Interaction with other devices
The device would interact with microwave IDU and ODU. It would
interact with them via SNMP or some other protocol that allows to
collect operating statistics of the microwave link. By collecting
those statistics, it can compute the link perfomance. It is also
possible to communicate with other autonomic device in MBH and to
exchange information, so that devices can learn the whole topology in
segment and performance of the microwave links in possible path.
5.1. Information needed from other devices
In Figure 2, a small example is shown how MBH router 1 is connected
via microwave links to router MBH 2 and MBH 3. Microwave IDUs are
connected via ethernet to MBH routers and each IDU has two ODUs
connected. Microwave links usually have two beams in a link.
Microwave IDUs send each incoming packet from MBH router 1 to each
ODU connected to them, essentially copying packets over each beam in
the microwave links. The terminating IDU C and D, on the other side,
compare incoming packets from each ODU and drop the duplicate packets
prior to forwarding the packet to their connected MBH routers. This
mechanism allows collecting good operating statistics of the links,
so autonomic agent on MBH routers can calculate end to end
performance of each link, like latency, throughput, jitter, delay
etc. This allows building performance topology on the MBH router by
autonomic agent
Bogdanovic Expires December 25, 2014 [Page 6]
Internet-Draft An Use Case June 2014
+-----------------------------+
| |
| MBH Router 1 |
| eth eth |
| port A port B |
+-------+--------------+------+
| |
| |
+-------+----+ +---+--------+
| Microwave | | Microwave |
| IDU A | | IDU B |
+-+--------+-+ +---+------+-+
| | | |
+-----+-+ +---+---+ +----+--+ +-+-----+
| MW | | MW | | MW | | MW |
| ODU | | ODU | | ODU | | ODU |
+---+---+ +---+---+ +---+---+ +---+---+
|| || || ||
|| || || ||
+---+---+ +---+---+ +---+---+ +---+---+
| MW | | MW | | MW | | MW |
| ODU | | ODU | | ODU | | ODU |
+-----+-+ +-+-----+ +--+----+ +-+-----+
| | | |
| | | |
+-+------+---+ +-+--------+-+
| Microwave | | Microwave |
| IDU C | | IDU D |
+-----+------+ +-----+------+
| |
+-----+------+ +-----+------+
| port A | | port A |
| eth | | eth |
| MBH Router | | MBH Router |
| 2 | | 3 |
+------------+ +------------+
--- eth links
=== microwave links
Figure 2
5.2. Monitoring, diagnostics and reporting
The autonomic user agent should provide feedback data to centralized
management system, so that new improved intent policies can be
created. Most of the data doesn't have to be provided in real time,
except for cases when microwave link failure happens and causes loss
Bogdanovic Expires December 25, 2014 [Page 7]
Internet-Draft An Use Case June 2014
of data. This means that the autonomic agent didn't provide
alternative path in time or all microwave links from the MBH router
are down. Historical data, like what were the network conditions
under which the autonomic agent enforcing the intent policies are
very valuable, as well the performance topology from each device, as
it allows to create whole performance view of the MBH.
6. Comparison with current solutions
There are some vendors (NSN, Ericsson) that are trying to create self
organizing networks, but the inteligence is always centralized, which
prevents distribution of the network inteligence and using it for
autonomic use cases.
7. Security Considerations
As this stage, author of the draft didn't look into security
considerations of the use case.
8. IANA Considerations
This document requests no action by IANA.
9. Acknowledgements
10. Change log [RFC Editor: Please remove]
11. References
[I-D.irtf-nmrg-an-gap-analysis]
Behringer, M., Carpenter, B., and S. Jiang, "Gap Analysis
for Autonomic Networking", draft-irtf-nmrg-an-gap-
analysis-00 (work in progress), April 2014.
[I-D.irtf-nmrg-autonomic-network-definitions]
Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking - Definitions and Design Goals", draft-irtf-
nmrg-autonomic-network-definitions-00 (work in progress),
December 2013.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
Bogdanovic Expires December 25, 2014 [Page 8]
Internet-Draft An Use Case June 2014
Author's Address
Dean Bogdanovic
Juniper Networks
Email: deanb@juniper.net
Bogdanovic Expires December 25, 2014 [Page 9]
