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]