idnits 2.17.1 draft-bogdanovic-nmrg-mobile-backhaul-use-case-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 23, 2014) is 3594 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.irtf-nmrg-an-gap-analysis' is defined on line 360, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-nmrg-autonomic-network-definitions' is defined on line 365, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 372, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-irtf-nmrg-an-gap-analysis-00 == Outdated reference: A later version (-07) exists of draft-irtf-nmrg-autonomic-network-definitions-00 ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 UCAN BOF D. Bogdanovic 3 Internet-Draft Juniper Networks 4 Intended status: Informational June 23, 2014 5 Expires: December 25, 2014 7 Autonomic Networking in mobile wireless backhaul 8 draft-bogdanovic-nmrg-mobile-backhaul-use-case-00 10 Abstract 12 Mobile backhaul networks that utilize microwave technology in 13 transport are suspicious to seasonal and/or meteorological changes. 14 For those reasons throughput can vary significantly. This draft 15 provides problem statement and how autonomic networking can be 16 applied to the problem. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 25, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 2 54 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Intended User and Administrator Experience . . . . . . . . . 3 56 4. Analysis of Parameters and Information Involved . . . . . . . 4 57 4.1. Parameters each device can decide for itself . . . . . . 4 58 4.2. Information needed from policy intent . . . . . . . . . . 5 59 5. Interaction with other devices . . . . . . . . . . . . . . . 6 60 5.1. Information needed from other devices . . . . . . . . . . 6 61 5.2. Monitoring, diagnostics and reporting . . . . . . . . . . 7 62 6. Comparison with current solutions . . . . . . . . . . . . . . 8 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 66 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 8 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 Microwave technology is one of the workhorses in MBH networks today. 73 Unlicensed microwave links can be set up in days rather than the 74 weeks or months it might take to implement additional wireline 75 capacity for backhaul. Even licensed links, while requiring some 76 mildly time-consuming bureaucratic approval, still easily outpace the 77 time-to-deployment of wireline alternatives. Fiber may offer 78 unlimited bandwidth, but the tradeoff is in time and cost savings. 79 Microwave's improvements in bandwidth, capacity, and reliability in 80 the past few years have made it an ideal interim broadband 81 connectivity solution during the often lengthy process of deploying 82 fiber. In fact, these improvements go as far as to establish 83 microwave as a legitimate permanent alternative to fiber. Although 84 its many benefits, because of other restrictions that microwave links 85 have, they can't be utilized at maximum. OSPF/MPLS networks that are 86 overlayed on top of microwave transport and provide additional 87 benefits of packet routing and switching to mobile backhaul. 89 1.1. Definitions and Acronyms 91 MBH: Mobile Backhaul 93 BTS: Base Transceiver Station 95 OSPF: Open Shortest Path First 97 MPLS: Multi Protocol Label Switching 98 PLMN: Public Land Mobile Networks 100 CoS: Class of Service 102 MTTR: Mean Time To Recovery 104 MNO: Mobile Network Operator 106 IDU: In Door Unit 108 ODU: Out Door Unit 110 SNMP: Simple Network Management Protocol 112 IP: Internet Protocol 114 IPv4: Internet Protocol version 4 116 IPv6: Internet Protocol version 6 118 2. Problem Statement 120 Mobile backhaul (MBH) networks utilize microwave networks to 121 transport traffic back to Public Land Mobile Networks (PLMN). Base 122 transceiver stations (BTS) and/or eNodeBs connect to a device that 123 has multiple microwave connections to PLMN. Not each link has the 124 same throughtput and the quality of the link varies with different 125 factors,like air temperature, percipitation, vegetation, etc. Today 126 those networks are overlayed with OSPF/MPLS networks and although 127 OSPF provides automatic redirection of traffic in case of primary 128 link failure, it reduces network throughput, as microwave link 129 bandwidth slowly degrades, due to rain, snow, tower bending due to 130 wind and/or temperature, vegatation growing. During the link 131 degradation period, the throughput of MBH part is going down and the 132 overall service is impacted. Being able to detect the degradation of 133 the microwave link bandwidth and redirect traffic over higher 134 throughput links is very beneficial to mobile network operators. 136 3. Intended User and Administrator Experience 138 As MBH links are lowering the bandwidth, the user experience is 139 impacted, as the data hungry applications are not served with usual 140 quality of service and latency is increasing, due to dropped packets. 141 MBH network administrator are not getting real time picture (usually 142 today they see average link performance over 15 minutes period) and 143 with users being highly mobile, they can't react to the challenges in 144 the network. Administrators should be able to set intended policy on 145 device, based on which device wwould start changing network 146 forwarding parameters based on which the current traffic would be 147 routed via links with moste throughput. With monitoring the link 148 statistics, device can change forwarding and routing parameters in 149 realtime based on the intended policy pushed on the device, without 150 the need to interact with centralized management system, which would 151 act based on sent link performance indicators. Such a network would 152 improve end user experience, as well network administrators would be 153 able to create better performing networks. 155 4. Analysis of Parameters and Information Involved 157 Numerous parameters are involved in monitoring MBH, from microwave 158 link performance, to miscellaneous OSFP and MPLS parameters. MNO has 159 to look at KPI that will relate to those that may impact revenue 160 negatively, such as unavailability and MTTR. One thing to note here 161 is that much emphasis is usually placed on availability, while most 162 times not enough emphasis is placed on reliability. In defining Key 163 Performance Indicators effectively, KPIs must align with BTS 164 availability information for a mobile operator. 166 Microwave transmission 168 o availability 170 o capacity 172 o delay 174 o jitter 176 4.1. Parameters each device can decide for itself 178 All OSPF interfaces have a cost, which is a routing metric that is 179 used in the link-state calculation. Routes with lower total path 180 metrics are preferred to those with higher path metrics. OSPF 181 assigns a default cost metric of 1 to reference bandwidth and default 182 cost metric of 0 to the loopback interface (lo0). No bandwidth is 183 associated with the loopback interface. So if reference bandwidth is 184 set to 1Gbps, it means that all interfaces faster than 1Gbps have the 185 same default cost metric of 1. If multiple equal-cost paths exist 186 between a source and destination address, OSPF routes packets along 187 each path alternately, in round-robin fashion. 189 Having the same default metric might not be a problem if all of the 190 interfaces are running at the same speed. In MBH, microwave units 191 will connect via ethernet to ethernet ports on routers and each link 192 will have the same metric. That would not be a problem if all 193 microwave links would have same performance, but links operate at 194 different speeds, and it is very probable that traffic is not routed 195 over the fastest interface because OSPF equally routes packets across 196 the different interfaces. 198 The autonomic agent agents collects operational statistics from 199 ethernet ports to which microwave IDU is connected, as well from 200 microwave ODU (local and remote) using SNMP. By collecting this 201 statistics, optimal MBH OSPF agent can callculate links with best 202 performance and change the metric value for each link accordingly. 204 +-------------------------------------------------------+ +------+ 205 | +----------+ +--------------+ | | MW | 206 | | | | SNMP Agent |<---------------|->| IDU | 207 | | Intent | | |<---------- | +------+ 208 | +----------+ +--------------+ \ | 209 | ^ ^ \ | +------+ 210 | | | ---|->| MW | 211 | +-----> Autonomic User Agent <--------+ | | ODU | 212 | | | | | +------+ 213 | V V V | 214 | +-----+------+ +--------------+ +---------+ | 215 | | | |Optimal MBH | |Ethernet | | 216 | | Performance|<---->|OSFP Selection| |Interface| | 217 | | topology | | Agent | |Counters | | 218 | | | | | | | | 219 | +------------+ +--------------+ +---------+ | 220 | ^ ^ | 221 | | | | 222 | V V | 223 |-------------------------------------------------------| 224 | Control Plane | 225 |-------------------------------------------------------| 226 | Standard Operating System Functions | 227 +-------------------------------------------------------+ 229 Figure 1 231 4.2. Information needed from policy intent 233 The section describers what information is needed to be provided by 234 external entity, so that devices can operate autonomicly. The policy 235 would have to set: 237 o reference bandwidth - example 1Gbps 239 o low water mark threshold, at which point to change the metric 240 o IP address or addresses of local IDU 242 o IP address or addresses of local ODU 244 o IP address or addresses of remote IDU 246 o IP address or addresses of remote ODU 248 o which ethernet port is connect to which microwave link 250 This list is not extensive and with more research it can be augmented 251 with new parameters. The experience will show what parameters are 252 important. There might be a need to put time restrictions between 253 metric updates on the device or how often are statistics collected, 254 as it is important not to negatively effect device forwarding 255 capabilities. 257 5. Interaction with other devices 259 The device would interact with microwave IDU and ODU. It would 260 interact with them via SNMP or some other protocol that allows to 261 collect operating statistics of the microwave link. By collecting 262 those statistics, it can compute the link perfomance. It is also 263 possible to communicate with other autonomic device in MBH and to 264 exchange information, so that devices can learn the whole topology in 265 segment and performance of the microwave links in possible path. 267 5.1. Information needed from other devices 269 In Figure 2, a small example is shown how MBH router 1 is connected 270 via microwave links to router MBH 2 and MBH 3. Microwave IDUs are 271 connected via ethernet to MBH routers and each IDU has two ODUs 272 connected. Microwave links usually have two beams in a link. 273 Microwave IDUs send each incoming packet from MBH router 1 to each 274 ODU connected to them, essentially copying packets over each beam in 275 the microwave links. The terminating IDU C and D, on the other side, 276 compare incoming packets from each ODU and drop the duplicate packets 277 prior to forwarding the packet to their connected MBH routers. This 278 mechanism allows collecting good operating statistics of the links, 279 so autonomic agent on MBH routers can calculate end to end 280 performance of each link, like latency, throughput, jitter, delay 281 etc. This allows building performance topology on the MBH router by 282 autonomic agent 283 +-----------------------------+ 284 | | 285 | MBH Router 1 | 286 | eth eth | 287 | port A port B | 288 +-------+--------------+------+ 289 | | 290 | | 291 +-------+----+ +---+--------+ 292 | Microwave | | Microwave | 293 | IDU A | | IDU B | 294 +-+--------+-+ +---+------+-+ 295 | | | | 296 +-----+-+ +---+---+ +----+--+ +-+-----+ 297 | MW | | MW | | MW | | MW | 298 | ODU | | ODU | | ODU | | ODU | 299 +---+---+ +---+---+ +---+---+ +---+---+ 300 || || || || 301 || || || || 302 +---+---+ +---+---+ +---+---+ +---+---+ 303 | MW | | MW | | MW | | MW | 304 | ODU | | ODU | | ODU | | ODU | 305 +-----+-+ +-+-----+ +--+----+ +-+-----+ 306 | | | | 307 | | | | 308 +-+------+---+ +-+--------+-+ 309 | Microwave | | Microwave | 310 | IDU C | | IDU D | 311 +-----+------+ +-----+------+ 312 | | 313 +-----+------+ +-----+------+ 314 | port A | | port A | 315 | eth | | eth | 316 | MBH Router | | MBH Router | 317 | 2 | | 3 | 318 +------------+ +------------+ 320 --- eth links 321 === microwave links 323 Figure 2 325 5.2. Monitoring, diagnostics and reporting 327 The autonomic user agent should provide feedback data to centralized 328 management system, so that new improved intent policies can be 329 created. Most of the data doesn't have to be provided in real time, 330 except for cases when microwave link failure happens and causes loss 331 of data. This means that the autonomic agent didn't provide 332 alternative path in time or all microwave links from the MBH router 333 are down. Historical data, like what were the network conditions 334 under which the autonomic agent enforcing the intent policies are 335 very valuable, as well the performance topology from each device, as 336 it allows to create whole performance view of the MBH. 338 6. Comparison with current solutions 340 There are some vendors (NSN, Ericsson) that are trying to create self 341 organizing networks, but the inteligence is always centralized, which 342 prevents distribution of the network inteligence and using it for 343 autonomic use cases. 345 7. Security Considerations 347 As this stage, author of the draft didn't look into security 348 considerations of the use case. 350 8. IANA Considerations 352 This document requests no action by IANA. 354 9. Acknowledgements 356 10. Change log [RFC Editor: Please remove] 358 11. References 360 [I-D.irtf-nmrg-an-gap-analysis] 361 Behringer, M., Carpenter, B., and S. Jiang, "Gap Analysis 362 for Autonomic Networking", draft-irtf-nmrg-an-gap- 363 analysis-00 (work in progress), April 2014. 365 [I-D.irtf-nmrg-autonomic-network-definitions] 366 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 367 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 368 Networking - Definitions and Design Goals", draft-irtf- 369 nmrg-autonomic-network-definitions-00 (work in progress), 370 December 2013. 372 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 373 June 1999. 375 Author's Address 377 Dean Bogdanovic 378 Juniper Networks 380 Email: deanb@juniper.net