idnits 2.17.1 draft-hao-rtgwg-ip-hard-pipes-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 18, 2016) is 2686 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG Working Group JT. Hao 3 Internet-Draft Huawei Technologies 4 Intended status: Informational KH. Soh 5 Expires: June 21, 2017 Singtel 6 L. Andersson 7 G. Gai 8 Huawei Technologies 9 December 18, 2016 11 Protocol Independent (Hardened) Bandwidth 12 draft-hao-rtgwg-ip-hard-pipes-02.txt 14 Abstract 16 This document describes Protocol Independent Bandwidth for IP 17 Multicast a.k.a "IP Multicast Hard Pipes". A hard pipe has a 18 dedicated bandwidth that can neither be exceeded or infringed upon. 20 RFC 7625 described an implementation of MPLS hard pipes, this 21 document discusses the hard pipe technology as applied to IP 22 Multicast flows. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 21, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 61 2. PIB Framework . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. PIB Services . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. PIB Infrastructure . . . . . . . . . . . . . . . . . . . 5 64 3. PIB Architecture . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. PIB Configuration . . . . . . . . . . . . . . . . . . . . 5 66 3.2. PIB Flows . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.3. Harden Bandwidth Manager . . . . . . . . . . . . . . . . 5 68 3.3.1. HBM functions . . . . . . . . . . . . . . . . . . . . 6 69 3.3.2. Operational Praxis . . . . . . . . . . . . . . . . . 7 70 3.3.3. Response to Simulation results . . . . . . . . . . . 8 71 3.4. PIB Enabled Router . . . . . . . . . . . . . . . . . . . 8 72 3.5. Non PIB Enabled Router . . . . . . . . . . . . . . . . . 9 73 3.6. PIB Tables . . . . . . . . . . . . . . . . . . . . . . . 9 74 3.6.1. PIB Tables on the Harden Bandwidth Manager . . . . . 9 75 3.6.2. PIB Table on PIB Enabled routers . . . . . . . . . . 10 76 4. PIB Configuration Actions . . . . . . . . . . . . . . . . . . 10 77 4.1. Configure PIB Hardened Bandwidth . . . . . . . . . . . . 10 78 4.2. Confirm PIB Hardened Bandwidth . . . . . . . . . . . . . 10 79 4.3. Notification of PIB Status . . . . . . . . . . . . . . . 11 80 4.4. Release PIB Hardened Bandwidth . . . . . . . . . . . . . 11 81 4.5. Configuration Example . . . . . . . . . . . . . . . . . . 11 82 4.5.1. Primary Configuration . . . . . . . . . . . . . . . . 12 83 4.5.2. Topology Change . . . . . . . . . . . . . . . . . . . 13 84 5. PIB Convergence . . . . . . . . . . . . . . . . . . . . . . . 14 85 6. PIB Configuration Protocol . . . . . . . . . . . . . . . . . 15 86 7. PIB Applicability . . . . . . . . . . . . . . . . . . . . . . 15 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 92 11.2. Informative References . . . . . . . . . . . . . . . . . 16 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 95 1. Introduction 97 This document describes a way to create hardened high bandwidth for 98 multicast flows. A hardened bandwidth is a bandwidth that has been 99 allocated for one single flow, the hardened bandwidth cannot be 100 exceeded or infringed upon. The hardened bandwidth will not 101 participate in the port level Diff-Serv scheduling. 103 1.1. Terminology 105 CIR - Committed Information Rate 107 E2E - end to end 109 FIB - Forwarding Information Base 111 FlexE - Flex Ethernet 113 HBM - Harden Bandwidth Manager, aka "the Manager" 115 HD-TV - High Definition TV 117 HQoS - Hierarchical Quality of Service 119 IGP - Interior Gateway Protocol 121 LSP - Label Switched Path 123 LSR - Label Switching Router 125 M-FIB - Multicast FIB 127 M-RIB - Multicast RIB 129 MPLS - MultiProtocol Label Switching 131 NMS - Network Management System 133 P (router/node) - Provider router or Provider node 135 PIR - Peak Information Rate 137 RIB - Routing Information Base 139 VLAN - Virtual LAN 141 * WAN - Wide Area Network 143 1.2. Requirements Language 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119[RFC2119]. 149 2. PIB Framework 151 PIB will be working in an environment where we find an infrastructure 152 that can support it and have services/applications that need the 153 hardened bandwidth. High Definition TV distribution is an example of 154 such a service and Hierarchical QoS and Flex Ethernet are examples of 155 infrastructure technologies can support hardened bandwidth. 157 There several protcols and other methods that can establish a 158 multicast flow, however, PIB will work regardless of how the 159 multicast flow has been established. 161 2.1. PIB Services 163 High Definition TV distribution, since it uses a stream that has a 164 constant bandwidth, is a service that will greatly benefit from 165 harden bandwidth. 167 Consider an IP TV service with 150 channels (e.g. a combination of 168 Full HD, Standard HD, etc.) such a traffic stream typically occupies 169 1G bps. The bandwidth does stay constant for the time change over 170 time. 172 An attractive way to transport such traffiv is to put it into a 173 harden stand-alone pipe, like the hardened pipes defined in RFC 7625 174 [RFC7625]. Since such is not part of the Diff Serv scheduling it 175 will be smoother. 177 In IP multicast scenarios (e.g. RFC 7582 [RFC7582]), a certain 178 multicast traffic is identified by the multicast source and group 179 (S,G) addresses. The multicast traffic that belongs to a given group 180 will be distributed via a multicast tree. The multicast tree will be 181 established by a multicast protocol, e.g. PIM. Nothing exclude the 182 multicast tree to carry traffic in a hierarchical fashion, e.g. two 183 or more streams share a common tunnel. 185 This version is limited to the hardening of (S,G) Multicast flows, 186 however other types of flows will be addressed in future versions. 188 2.2. PIB Infrastructure 190 In the industry, there are technologies such as Hierarchical Quality 191 of Service (HQoS) and Flex Ethernet (FlexE). These technologies make 192 it possible to allocate a certain bandwidth to part of e.g. an 193 Ethernet interface. This make it possible to allocate a certain 194 bandwidth to part of e.g. an Ethernet interface. The part of the 195 interface can be used by a certain multicast flow, as long as it can 196 be uniquely identified. 198 3. PIB Architecture 200 This section discusses the PIB components and paradigms, e.g. 201 signalling, the HBM functions, the Manager and PIB enabled routers, 202 the PIB tables, flow identification, routers without PIB 203 capabilities, etc. 205 3.1. PIB Configuration 207 A PIB Enabled router will be configured to assign hardened bandwidth 208 to a particular multicast flow (see Section 3.2) by the HBM (see 209 Section 3.3). 211 The method for configuration is optional and there are several 212 alternatives, for example signalling, netconf/YANG restful/HTTP. 214 Note: I took out SNMP, since there we not be any more read/write and 215 read/create MIBs, so SNMP cannot be used. 217 When an action to harden the bandwidth for a certain flow this is 218 information is made available to all routers in the system. The 219 trigger to request harden bandwidth is outside the scope of this 220 document. 222 3.2. PIB Flows 224 A PIB Flow, i.e. aa flow for which the bandwidth may be hardened, 225 must be possible to uniquely identify end to end. 227 The current version of this document is limited to harden the 228 bandwidth for (S,G) multicast flows. Other types of flows, like IP 229 P2P, (*,G) multicast flows and MPLS are for further study. 231 3.3. Harden Bandwidth Manager 233 The Harden Bandwidth Manager is the controller of the system that 234 provides harden bandwidth for uniquely identifiable flows. The HBM 235 have a set of functions available to optimize the hardening of the 236 flows. These functions may be created for the HBM, or generally 237 available in carrier grade networks. Examples of such functions are 238 discussed in Section 3.3.1. 240 3.3.1. HBM functions 242 The list below describes functions that may be used by the HBM and 243 what the output from each function is. 245 o Planning 247 A planning function helps the operator to extend and change the 248 network in such a way that the network can accommodate traffic 249 with the set of characteristics that the operator want. The 250 overall goal of the planning functions is to optimize the network 251 throughput. The planning function may be used to calculate and 252 advice on the potentially hardened bandwidth in such a way that 253 primary and secondary paths are available for all hardened flows. 255 o Simulation 257 A simulation function is critical for the smooth operation of a 258 system that offers hardened bandwidth. 260 Whenever an operator want to harden the bandwidth of a certain 261 flow a set of simulations will be done. 263 * Primary Path Simulation 265 The first will run a simulation to see if it is possible to 266 harden the bandwidth for a particular tree. This is basically 267 a check to see if there is enough bandwidth that can be 268 hardened on the interface(s) the multicast tree uses. 270 * Back-up Path(s) Simulation 272 The next set of simulations is to see if there is enough 273 resources in the network to create a back-up path if any of the 274 resources that a hardened tee uses fail. 276 * Since hardening the bandwidth for one multicast group might 277 have an impact on the possibilities to establish a back-up path 278 for an earlier hardened multicast group, quite a bit of re- 279 iterative simulation should be done. 281 * Actions based on the outcome of the simulation 282 If the simulations say that there are enough resources in the 283 network both to harden the bandwidth of the tree and move the 284 traffic to back-up path, for example due to a topology change, 285 then the bandwidth will be hardened. 287 * Advanced actions 289 However, here might be operator policies that allow 290 establishment of harden trees even if all simulations does not 291 come out "positive", see Section 3.3.3 293 o Deployment 295 To deploy a hardened bandwidth for a (S,G) multicast group the 296 deployment function (part of the HBM) all the routers in the 297 network is configured with the identity of the multicast group to 298 be hardened and what amount of bandwidth should be reserved. The 299 routers will inform the HBM with if the hardening succeeded or 300 not. 302 o Accounting 304 The HBM (by means of the accounting function) will keep track of 305 the state of hardened bandwidth on every router, every link and 306 every multicast group. This give the HBM a global and up to date 307 view of all the active PIB services. 309 3.3.2. Operational Praxis 311 The functions in the list in Section 3.3.1 are describe as if they 312 were highly independent. Even though one function may operate on its 313 own, there is a high degree of interdependency. 315 The planning function can be seen to rely heavily on the outcome of 316 the simulation function. If the simulation function runs a couple of 317 simulations where the outcome is lack of resources in certain parts 318 of the network, the planning function can take this information and 319 give the operator indications on how the network could be extended or 320 changed. 322 In operational context, the relationship between the two functions 323 are such that one often speak of or write Planning/Simulation. 325 The deployment function has a similar strong relationship with the 326 accounting function. While the deployment function informs the 327 routers what should be done with respect to hardened bandwidth for 328 the flows, the accounting function keeps track of everything that 329 happens as a result of the requests from the deployment function. 331 3.3.3. Response to Simulation results 333 The simulation might give many responses (a few examples is listed in 334 this section), where the action to take is not intuitive. An 335 operator might want to define policies how to respond to the 336 different responses. 338 o The simulation might show that there are enough resources to 339 harden the bandwidth for the indicated multicast group, the second 340 step might show that whatever single failure that might occur 341 there is always a way to find a back-up path. 343 If this is the outcome of the simulation, there is nothing that 344 stops the hardening of the bandwidth. 346 o The simulations might show that there are enough resources to 347 harden the indicated multicast group, but that there are no 348 possibilities to establish a back-up path. 350 In this case the operator might have a policy that allows the 351 hardening of the primary path, while feeding the result from the 352 simulation into the planning function. 354 Or the policy might be that no primary hardening will take place 355 unless there are at least one back-up path. 357 o The simulation might show that there are enough resources on most 358 routers but not all. 360 In this case the operator policy might say that if a low number of 361 routers might not be able to support the hardening of the 362 bandwidth for a multicast group, it will still be OK to go ahead 363 and harden the bandwidth on the routers that are able to do so, 364 while the router that are unable to do that may support the 365 multicast group on a best effort basis. 367 Or the policy might say that no hardening of multicast groups will 368 happen unless all routers can support it. 370 o This list will be extended in future versions of the document. 372 3.4. PIB Enabled Router 374 The term "PIB Enabled Router" is used for a router that can, after 375 being told to do so by the HBM, harden the bandwidth for an indicated 376 multicast flow. The PIB Enabled Router also have a way to 377 communicate with the HBM. 379 A PIB enabled router keeps PIB table see Section 3.6.2, that keeps 380 track of all requests for hardened bandwidth and of all actions the 381 router taken to harden bandwidth. 383 3.5. Non PIB Enabled Router 385 The term "Non PIB Enabled Router" is used for a router that lack 386 capability to harden bandwidth for a flow or to communicate with the 387 HBM. It is quite possible to have PIB Flows being forwarded by a Non 388 PIB Enabled Router in a network that otherwise have PIB Enabled 389 Routers. 391 3.6. PIB Tables 393 A PIB Enabled Router and the HBM keep PIB Tables, although the name 394 is the same, there are differences between the tables on the routers 395 and the HBM. 397 3.6.1. PIB Tables on the Harden Bandwidth Manager 399 The HBM keeps two PIB tables, one reflects the commands given to the 400 routers to harden bandwidth for multicast groups. The second 401 reflects the real time detailed situation of the entire network. 403 3.6.1.1. General PIB Table 405 The General PIB Table contain all the active configurations that the 406 HBM has made on the routers in the network. 408 When the HBM does a configuration for a new multicast group or 409 traffic flow it informs the routers of the Traffic ID (for this 410 version of the document it is the multicast group address) and the 411 bandwidth to be hardened, i.e. the key information in the General PIB 412 Table is (Traff ID, bandwidth). 414 3.6.1.2. Real Time PIB Table 416 The real time PIB table reflect the configurations on all the PIB 417 enabled routers in the entire network. It builds on what the routers 418 have reported. 420 To some extent there is a dependency, in that the General PIB table 421 is used to create the PIB table on the routers, and the router tables 422 are used to create the Real Time PIB table. 424 The Real Time table has - apart from an indication which router the 425 information originates from - no other rows or columns than the 426 routers have. 428 The Real Time table information include (router ID, Traffic ID, 429 bandwidth, interfaces) for interfaces that the configuration were 430 successful. 432 After a router have done the configuration requested by the HBM it 433 will report the outcome of the configuration to the HBM. The report 434 include only information for the interfaces where the were 435 successfully performed see Section 4.5. 437 The Real Time PIB table allow the HBM to have a global view of the 438 multicast tree and bandwidth resource consumption in the network. 440 3.6.2. PIB Table on PIB Enabled routers 442 Each new entry in the PIB table (i.e. a row in the table) on and PIB 443 enabled router is created as the HBM request that the router harden 444 the flow for a certain multicast group. 446 The PIB table on a router has include information on Traffic ID, 447 allocated bandwidth and configured interfaces, i.e. the key 448 information in the PIB Table on a router is (Traffic ID, Bandwidth, 449 Interfaces), see Section 4.5. 451 4. PIB Configuration Actions 453 This section list and explain the PIB configuration actions. 455 4.1. Configure PIB Hardened Bandwidth 457 The HBM initiate the hardening of the bandwidth for a flow, by 458 informing all the routers in the domain about which flow to harden 459 and what bandwidth that harden, i.e. the critical information that 460 needs to be configured on all PIB enabled routers in the system that 461 carries the flow is (Traffic ID, bandwidth). 463 In the event that the flow is not carried by a router when it 464 receives the configuration, it will save the Traffic ID and bandwidth 465 in the router PIB Table, but set the interfaces to NULL. 467 4.2. Confirm PIB Hardened Bandwidth 469 When a router learns of the intent to harden the bandwidth for a flow 470 (Trafic ID, bandwidth), it will take the following steps. 472 o Add the indicted flow and the amount of bandwidth to be hardened 473 to the routers PIB table, i.e. (Traffic ID, bandwidth). 475 o Check in the Multicast RIB if the flow is available going through 476 router. 478 * If the flow is present on the router, the outgoing interfaces 479 will be identified. 481 * The bandwidth will be harden for the flow on the outgoing 482 interfaces. 484 * The router will then add the outgoing interfaces to the new 485 entry in the router PIB table, i.e. the critical info will be 486 (Traffic ID, bandwidth, interfaces). 488 * The router will then report the status of the hardening for the 489 indicated flow, i.e. (Traffic ID, bandwidth, interfaces) 491 o If the flow is not available on the router, the following steps 492 will be taken. 494 * The router will add to its new PIB table a entry "NULL" 495 indicating that the flow is not available on any interfaces on 496 the router, i.e. (Trafic ID, bandwidth, NULL). 498 * The router report the information of (Trafic ID, bandwidth, 499 NULL) to HBM 501 4.3. Notification of PIB Status 503 If there is an event on the router that the HBM needs to be aware of 504 a notification will be sent to the HBM by the router. Such an event 505 might be that the multicast protocol removes a multicast group from 506 the router. 508 This might be done by sending the row for the flow or the entire PIB 509 table for the router to the HBM. 511 4.4. Release PIB Hardened Bandwidth 513 If the HBM want to remove a certain flow from hardening, the HBM will 514 configure all routers accordingly. The result of the release will be 515 reported to the HBM by the router- 517 4.5. Configuration Example 519 The network example in Figure 1 will serve to show how the PIB 520 configuration works. Below we are only disussing one flow or 521 multicast group, a production network will have many multicast trees, 522 but the principles for the PIB configuration is the same. 524 In the network there is a (S,G1) multicast group established, the 525 source sends to A, A sends to B1, B1 sends to C1 and C3, C1 sends to 526 sends to recerver 1 and C2 sends to receiver 2. 528 4.5.1. Primary Configuration 530 To configure this multicast tree with hardened bandwidth the HBM will 531 configure all routers in the network that multicast group G1 should 532 have a 10Mbit/s hardened bandwidth, the configuration parameters is 533 (G1, 10M). 535 Source 536 / 537 A 538 / \ 539 B1---B2 540 /|\ /\ 541 / | \ / \ 542 C1 C2 C3 C4 543 / \ 544 / \ 545 Receiver1 Receiver2 547 Figure 1: Topology where multicast traffic run 549 After receiving this information, router B1 check its M-RIB and find 550 that there are two output interfaces: B1-C1, B1-C3. B1 will then 551 take 3 actions: 553 o Allocate 10M hard bandwidth to group G1 on the two interfaces 554 (B1-C1 and (B1-C3). 556 o Add entry for G1 to the local PIB table as (G1, 10M, interfaces 557 (B1-C1, B1-C3)) 559 o Report the successful configuration by sending the configured 560 information (G1,10M interfaces(B1-C1,B1-C3)) to HBM. 562 Router B2 will receive the configuration information at the same time 563 as B1. B2 will check its M-RIB table, and find the (S,G) multicast 564 group does not pass through B2. B2 will then take 2 actions. 566 o Add entry (G1,10M, interface(NULL)) to the local PIB table; 568 o Send the information (G1, 10M ,interface (NULL)) to HBM. 570 When the configuration in response to the configuration parameters 571 (G1, 10M) is complete 573 o All routers finished deploying the (G1,10M), either after 574 hardening the bandwidth on the interface or taken note of the flow 575 and bandwidth, but that the flow is not presently present on the 576 router. 578 o End to end multicast hardened tree for G1 is established. 580 o As the HBM gets the reports form all routers it isi able to build 581 an global view of the 10Mbps hardened tree for G1. 583 - 585 4.5.2. Topology Change 587 In case of there is topology change, if for example, the link B1-C3 588 fails, the IGP and PIM will convergence and the multicast traffic for 589 "receiver 1" will now go over the links B1-B2-C3. 591 The IGP/PIM convergence will trigger all routers to check entire PIB 592 table. They will check the new M-RIB to see if the multicast group 593 earlier configured on the router still go through the node and if 594 there are new multicast groups going through the node, 596 If there are multicast groups that does no longer passes through the 597 node, the interfaces entry for that flow in the PIB table will be 598 marked "NULL" 600 If there are new multicast group passing through the not, for which 601 there are already entries (with the interfaces set to NULL) in the 602 PIB table, these multicast group will be hardened. 604 4.5.2.1. Actions taken by B1 due to the topology change 606 B1 will be triggered by the topology change to check the consistency 607 between the PIB Table and the M-RIB. When B1 checks for multicast 608 group G1 it will find that the outgoing interfaces are now B1-C1 and 609 B1-B2. 611 B1 will take four actions: 613 o Change the entry in PIB table for G1 to (G1,10M, interfaces(B1-C1, 614 B1-B2)) 616 o Allocate 10M hardened bandwidth to G1 on new output interfaces 617 B1-B2. 619 o Relese the 10M hardened bandwidth for G1 on the interface B1-C3 621 o After the updates of all entries in the PIB table that were 622 impacted by the topology change, B1 will report the whole new PIB 623 table to the HBM. 625 4.5.2.2. Actions taken by B2 due to the topology change 627 B2 will be triggered by the topology change to check the consistency 628 between the PIB Table and the M-RIB. When B2 checks for multicast 629 group G1 it will find that there is new outgoing interface B2-C3. 631 B2 will take three actions: 633 o Change the entry in PIB table for G1 to (G1,10M, interface(B2-C3)) 635 o Allocate the hardened bandwidth 10M to interface(B2-C3). 637 o After the updates of all entries in the PIB table that were 638 impacted by the topology change, B1 will report the whole new PIB 639 table to the HBM. 641 4.5.2.3. PIB Table Convergence 643 After the IGP/PIM convergence and the required updates of the PIB 644 Tables, the status of the system will be: 646 o All routers have their PIB table converged. 648 o End to end multicast hardened tree for G1 have tree have been 649 established. The same is true for all other trees with PIB 650 hardened bandwidth. 652 o HBM has its real time PIB table converged, and then it get an 653 global view of all the hardened tree service again. 655 5. PIB Convergence 657 For a single router, when topology change, and after IGP/PIM 658 converged, it will take some time for the router to re-deploy or 659 release PIB hardened for each traffic flow (i.e. change each of the 660 entry of the local PIB table). When the router have finished to re- 661 deploy the hardened bandwidth all the flows, we say that the PIB have 662 converged. 664 After the PIB Table on a router have converged, it will report the 665 whole PIB table to the HBM. 667 After the HBM have received the post-topology change reports for all 668 routers, the HBM is able to bring the Real Time PIB table up to date, 669 and thus have a global of all the active PIB services. 671 In order to allow the HBM to have an accurate view of the network 672 topology 674 6. PIB Configuration Protocol 676 To be discussed in a future version of tis document 678 7. PIB Applicability 680 This version of the document does describe the PIB hardening IP 681 multicast flows. 683 Other flows are for further study. 685 8. Security Considerations 687 To be added in a future version of the document. 689 9. IANA Considerations 691 There are no requests for IANA actions in this document. 693 Note to the RFC Editor - this section can be removed before 694 publication. 696 10. Acknowledgements 698 - 700 11. References 702 11.1. Normative References 704 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 705 Requirement Levels", BCP 14, RFC 2119, 706 DOI 10.17487/RFC2119, March 1997, 707 . 709 [RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, 710 "Multicast Virtual Private Network (MVPN): Using 711 Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582, 712 July 2015, . 714 11.2. Informative References 716 [RFC7625] Hao, J., Maheshwari, P., Huang, R., Andersson, L., and M. 717 Chen, "Architecture of an IP/MPLS Network with Hardened 718 Pipes", RFC 7625, DOI 10.17487/RFC7625, August 2015, 719 . 721 Authors' Addresses 723 Jiangtao Hao 724 Huawei Technologies 725 Huanbaoyuan, No.156, BeiQing Road 726 Beijing 727 China 729 Email: haojiangtao@huawei.com 731 Soh Keng Hock 732 Singtel 733 31 Exeter Road, Comcentre 734 Singapore 239732 735 Singapore 737 Email: khsoh@singtel.com 739 Loa Andersson 740 Huawei Technologies 742 Email: loa@pi.nu 744 Gang Gai 745 Huawei Technologies 746 Huanbaoyuan, No.156, BeiQing Road 747 Beijing 748 China 750 Email: gaigang@huawei.com