[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

RTGWG Working Group                                              JT. Hao
Internet-Draft                                       Huawei Technologies
Intended status: Informational                                   KH. Soh
Expires: June 21, 2017                                           Singtel
                                                            L. Andersson
                                                                  G. Gai
                                                     Huawei Technologies
                                                       December 18, 2016


               Protocol Independent (Hardened) Bandwidth
                  draft-hao-rtgwg-ip-hard-pipes-02.txt

Abstract

   This document describes Protocol Independent Bandwidth for IP
   Multicast a.k.a "IP Multicast Hard Pipes".  A hard pipe has a
   dedicated bandwidth that can neither be exceeded or infringed upon.

   RFC 7625 described an implementation of MPLS hard pipes, this
   document discusses the hard pipe technology as applied to IP
   Multicast flows.

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 June 21, 2017.

Copyright Notice

   Copyright (c) 2016 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



Hao, et al.               Expires June 21, 2017                 [Page 1]


Internet-Draft           Protocol Independent BW           December 2016


   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
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  PIB Framework . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  PIB Services  . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  PIB Infrastructure  . . . . . . . . . . . . . . . . . . .   5
   3.  PIB Architecture  . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  PIB Configuration . . . . . . . . . . . . . . . . . . . .   5
     3.2.  PIB Flows . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Harden Bandwidth Manager  . . . . . . . . . . . . . . . .   5
       3.3.1.  HBM functions . . . . . . . . . . . . . . . . . . . .   6
       3.3.2.  Operational Praxis  . . . . . . . . . . . . . . . . .   7
       3.3.3.  Response to Simulation results  . . . . . . . . . . .   8
     3.4.  PIB Enabled Router  . . . . . . . . . . . . . . . . . . .   8
     3.5.  Non PIB Enabled Router  . . . . . . . . . . . . . . . . .   9
     3.6.  PIB Tables  . . . . . . . . . . . . . . . . . . . . . . .   9
       3.6.1.  PIB Tables on the Harden Bandwidth Manager  . . . . .   9
       3.6.2.  PIB Table on PIB Enabled routers  . . . . . . . . . .  10
   4.  PIB Configuration Actions . . . . . . . . . . . . . . . . . .  10
     4.1.  Configure PIB Hardened Bandwidth  . . . . . . . . . . . .  10
     4.2.  Confirm PIB Hardened Bandwidth  . . . . . . . . . . . . .  10
     4.3.  Notification of PIB Status  . . . . . . . . . . . . . . .  11
     4.4.  Release PIB Hardened Bandwidth  . . . . . . . . . . . . .  11
     4.5.  Configuration Example . . . . . . . . . . . . . . . . . .  11
       4.5.1.  Primary Configuration . . . . . . . . . . . . . . . .  12
       4.5.2.  Topology Change . . . . . . . . . . . . . . . . . . .  13
   5.  PIB Convergence . . . . . . . . . . . . . . . . . . . . . . .  14
   6.  PIB Configuration Protocol  . . . . . . . . . . . . . . . . .  15
   7.  PIB Applicability . . . . . . . . . . . . . . . . . . . . . .  15
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     11.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16






Hao, et al.               Expires June 21, 2017                 [Page 2]


Internet-Draft           Protocol Independent BW           December 2016


1.  Introduction

   This document describes a way to create hardened high bandwidth for
   multicast flows.  A hardened bandwidth is a bandwidth that has been
   allocated for one single flow, the hardened bandwidth cannot be
   exceeded or infringed upon.  The hardened bandwidth will not
   participate in the port level Diff-Serv scheduling.

1.1.  Terminology

      CIR - Committed Information Rate

      E2E - end to end

      FIB - Forwarding Information Base

      FlexE - Flex Ethernet

      HBM - Harden Bandwidth Manager, aka "the Manager"

      HD-TV - High Definition TV

      HQoS - Hierarchical Quality of Service

      IGP - Interior Gateway Protocol

      LSP - Label Switched Path

      LSR - Label Switching Router

      M-FIB - Multicast FIB

      M-RIB - Multicast RIB

      MPLS - MultiProtocol Label Switching

      NMS - Network Management System

      P (router/node) - Provider router or Provider node

      PIR - Peak Information Rate

      RIB - Routing Information Base

      VLAN - Virtual LAN

      * WAN - Wide Area Network




Hao, et al.               Expires June 21, 2017                 [Page 3]


Internet-Draft           Protocol Independent BW           December 2016


1.2.  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].

2.  PIB Framework

   PIB will be working in an environment where we find an infrastructure
   that can support it and have services/applications that need the
   hardened bandwidth.  High Definition TV distribution is an example of
   such a service and Hierarchical QoS and Flex Ethernet are examples of
   infrastructure technologies can support hardened bandwidth.

   There several protcols and other methods that can establish a
   multicast flow, however, PIB will work regardless of how the
   multicast flow has been established.

2.1.  PIB Services

   High Definition TV distribution, since it uses a stream that has a
   constant bandwidth, is a service that will greatly benefit from
   harden bandwidth.

   Consider an IP TV service with 150 channels (e.g. a combination of
   Full HD, Standard HD, etc.) such a traffic stream typically occupies
   1G bps.  The bandwidth does stay constant for the time change over
   time.

   An attractive way to transport such traffiv is to put it into a
   harden stand-alone pipe, like the hardened pipes defined in RFC 7625
   [RFC7625].  Since such is not part of the Diff Serv scheduling it
   will be smoother.

   In IP multicast scenarios (e.g.  RFC 7582 [RFC7582]), a certain
   multicast traffic is identified by the multicast source and group
   (S,G) addresses.  The multicast traffic that belongs to a given group
   will be distributed via a multicast tree.  The multicast tree will be
   established by a multicast protocol, e.g.  PIM.  Nothing exclude the
   multicast tree to carry traffic in a hierarchical fashion, e.g. two
   or more streams share a common tunnel.

   This version is limited to the hardening of (S,G) Multicast flows,
   however other types of flows will be addressed in future versions.







Hao, et al.               Expires June 21, 2017                 [Page 4]


Internet-Draft           Protocol Independent BW           December 2016


2.2.  PIB Infrastructure

   In the industry, there are technologies such as Hierarchical Quality
   of Service (HQoS) and Flex Ethernet (FlexE).  These technologies make
   it possible to allocate a certain bandwidth to part of e.g. an
   Ethernet interface.  This make it possible to allocate a certain
   bandwidth to part of e.g. an Ethernet interface.  The part of the
   interface can be used by a certain multicast flow, as long as it can
   be uniquely identified.

3.  PIB Architecture

   This section discusses the PIB components and paradigms, e.g.
   signalling, the HBM functions, the Manager and PIB enabled routers,
   the PIB tables, flow identification, routers without PIB
   capabilities, etc.

3.1.  PIB Configuration

   A PIB Enabled router will be configured to assign hardened bandwidth
   to a particular multicast flow (see Section 3.2) by the HBM (see
   Section 3.3).

   The method for configuration is optional and there are several
   alternatives, for example signalling, netconf/YANG restful/HTTP.

   Note: I took out SNMP, since there we not be any more read/write and
   read/create MIBs, so SNMP cannot be used.

   When an action to harden the bandwidth for a certain flow this is
   information is made available to all routers in the system.  The
   trigger to request harden bandwidth is outside the scope of this
   document.

3.2.  PIB Flows

   A PIB Flow, i.e. aa flow for which the bandwidth may be hardened,
   must be possible to uniquely identify end to end.

   The current version of this document is limited to harden the
   bandwidth for (S,G) multicast flows.  Other types of flows, like IP
   P2P, (*,G) multicast flows and MPLS are for further study.

3.3.  Harden Bandwidth Manager

   The Harden Bandwidth Manager is the controller of the system that
   provides harden bandwidth for uniquely identifiable flows.  The HBM
   have a set of functions available to optimize the hardening of the



Hao, et al.               Expires June 21, 2017                 [Page 5]


Internet-Draft           Protocol Independent BW           December 2016


   flows.  These functions may be created for the HBM, or generally
   available in carrier grade networks.  Examples of such functions are
   discussed in Section 3.3.1.

3.3.1.  HBM functions

   The list below describes functions that may be used by the HBM and
   what the output from each function is.

   o  Planning

      A planning function helps the operator to extend and change the
      network in such a way that the network can accommodate traffic
      with the set of characteristics that the operator want.  The
      overall goal of the planning functions is to optimize the network
      throughput.  The planning function may be used to calculate and
      advice on the potentially hardened bandwidth in such a way that
      primary and secondary paths are available for all hardened flows.

   o  Simulation

      A simulation function is critical for the smooth operation of a
      system that offers hardened bandwidth.

      Whenever an operator want to harden the bandwidth of a certain
      flow a set of simulations will be done.

      *  Primary Path Simulation

         The first will run a simulation to see if it is possible to
         harden the bandwidth for a particular tree.  This is basically
         a check to see if there is enough bandwidth that can be
         hardened on the interface(s) the multicast tree uses.

      *  Back-up Path(s) Simulation

         The next set of simulations is to see if there is enough
         resources in the network to create a back-up path if any of the
         resources that a hardened tee uses fail.

      *  Since hardening the bandwidth for one multicast group might
         have an impact on the possibilities to establish a back-up path
         for an earlier hardened multicast group, quite a bit of re-
         iterative simulation should be done.

      *  Actions based on the outcome of the simulation





Hao, et al.               Expires June 21, 2017                 [Page 6]


Internet-Draft           Protocol Independent BW           December 2016


         If the simulations say that there are enough resources in the
         network both to harden the bandwidth of the tree and move the
         traffic to back-up path, for example due to a topology change,
         then the bandwidth will be hardened.

      *  Advanced actions

         However, here might be operator policies that allow
         establishment of harden trees even if all simulations does not
         come out "positive", see Section 3.3.3

   o  Deployment

      To deploy a hardened bandwidth for a (S,G) multicast group the
      deployment function (part of the HBM) all the routers in the
      network is configured with the identity of the multicast group to
      be hardened and what amount of bandwidth should be reserved.  The
      routers will inform the HBM with if the hardening succeeded or
      not.

   o  Accounting

      The HBM (by means of the accounting function) will keep track of
      the state of hardened bandwidth on every router, every link and
      every multicast group.  This give the HBM a global and up to date
      view of all the active PIB services.

3.3.2.  Operational Praxis

   The functions in the list in Section 3.3.1 are describe as if they
   were highly independent.  Even though one function may operate on its
   own, there is a high degree of interdependency.

   The planning function can be seen to rely heavily on the outcome of
   the simulation function.  If the simulation function runs a couple of
   simulations where the outcome is lack of resources in certain parts
   of the network, the planning function can take this information and
   give the operator indications on how the network could be extended or
   changed.

   In operational context, the relationship between the two functions
   are such that one often speak of or write Planning/Simulation.

   The deployment function has a similar strong relationship with the
   accounting function.  While the deployment function informs the
   routers what should be done with respect to hardened bandwidth for
   the flows, the accounting function keeps track of everything that
   happens as a result of the requests from the deployment function.



Hao, et al.               Expires June 21, 2017                 [Page 7]


Internet-Draft           Protocol Independent BW           December 2016


3.3.3.  Response to Simulation results

   The simulation might give many responses (a few examples is listed in
   this section), where the action to take is not intuitive.  An
   operator might want to define policies how to respond to the
   different responses.

   o  The simulation might show that there are enough resources to
      harden the bandwidth for the indicated multicast group, the second
      step might show that whatever single failure that might occur
      there is always a way to find a back-up path.

      If this is the outcome of the simulation, there is nothing that
      stops the hardening of the bandwidth.

   o  The simulations might show that there are enough resources to
      harden the indicated multicast group, but that there are no
      possibilities to establish a back-up path.

      In this case the operator might have a policy that allows the
      hardening of the primary path, while feeding the result from the
      simulation into the planning function.

      Or the policy might be that no primary hardening will take place
      unless there are at least one back-up path.

   o  The simulation might show that there are enough resources on most
      routers but not all.

      In this case the operator policy might say that if a low number of
      routers might not be able to support the hardening of the
      bandwidth for a multicast group, it will still be OK to go ahead
      and harden the bandwidth on the routers that are able to do so,
      while the router that are unable to do that may support the
      multicast group on a best effort basis.

      Or the policy might say that no hardening of multicast groups will
      happen unless all routers can support it.

   o  This list will be extended in future versions of the document.

3.4.  PIB Enabled Router

   The term "PIB Enabled Router" is used for a router that can, after
   being told to do so by the HBM, harden the bandwidth for an indicated
   multicast flow.  The PIB Enabled Router also have a way to
   communicate with the HBM.




Hao, et al.               Expires June 21, 2017                 [Page 8]


Internet-Draft           Protocol Independent BW           December 2016


   A PIB enabled router keeps PIB table see Section 3.6.2, that keeps
   track of all requests for hardened bandwidth and of all actions the
   router taken to harden bandwidth.

3.5.  Non PIB Enabled Router

   The term "Non PIB Enabled Router" is used for a router that lack
   capability to harden bandwidth for a flow or to communicate with the
   HBM.  It is quite possible to have PIB Flows being forwarded by a Non
   PIB Enabled Router in a network that otherwise have PIB Enabled
   Routers.

3.6.  PIB Tables

   A PIB Enabled Router and the HBM keep PIB Tables, although the name
   is the same, there are differences between the tables on the routers
   and the HBM.

3.6.1.  PIB Tables on the Harden Bandwidth Manager

   The HBM keeps two PIB tables, one reflects the commands given to the
   routers to harden bandwidth for multicast groups.  The second
   reflects the real time detailed situation of the entire network.

3.6.1.1.  General PIB Table

   The General PIB Table contain all the active configurations that the
   HBM has made on the routers in the network.

   When the HBM does a configuration for a new multicast group or
   traffic flow it informs the routers of the Traffic ID (for this
   version of the document it is the multicast group address) and the
   bandwidth to be hardened, i.e. the key information in the General PIB
   Table is (Traff ID, bandwidth).

3.6.1.2.  Real Time PIB Table

   The real time PIB table reflect the configurations on all the PIB
   enabled routers in the entire network.  It builds on what the routers
   have reported.

   To some extent there is a dependency, in that the General PIB table
   is used to create the PIB table on the routers, and the router tables
   are used to create the Real Time PIB table.

   The Real Time table has - apart from an indication which router the
   information originates from - no other rows or columns than the
   routers have.



Hao, et al.               Expires June 21, 2017                 [Page 9]


Internet-Draft           Protocol Independent BW           December 2016


   The Real Time table information include (router ID, Traffic ID,
   bandwidth, interfaces) for interfaces that the configuration were
   successful.

   After a router have done the configuration requested by the HBM it
   will report the outcome of the configuration to the HBM.  The report
   include only information for the interfaces where the were
   successfully performed see Section 4.5.

   The Real Time PIB table allow the HBM to have a global view of the
   multicast tree and bandwidth resource consumption in the network.

3.6.2.  PIB Table on PIB Enabled routers

   Each new entry in the PIB table (i.e. a row in the table) on and PIB
   enabled router is created as the HBM request that the router harden
   the flow for a certain multicast group.

   The PIB table on a router has include information on Traffic ID,
   allocated bandwidth and configured interfaces, i.e. the key
   information in the PIB Table on a router is (Traffic ID, Bandwidth,
   Interfaces), see Section 4.5.

4.  PIB Configuration Actions

   This section list and explain the PIB configuration actions.

4.1.  Configure PIB Hardened Bandwidth

   The HBM initiate the hardening of the bandwidth for a flow, by
   informing all the routers in the domain about which flow to harden
   and what bandwidth that harden, i.e. the critical information that
   needs to be configured on all PIB enabled routers in the system that
   carries the flow is (Traffic ID, bandwidth).

   In the event that the flow is not carried by a router when it
   receives the configuration, it will save the Traffic ID and bandwidth
   in the router PIB Table, but set the interfaces to NULL.

4.2.  Confirm PIB Hardened Bandwidth

   When a router learns of the intent to harden the bandwidth for a flow
   (Trafic ID, bandwidth), it will take the following steps.

   o  Add the indicted flow and the amount of bandwidth to be hardened
      to the routers PIB table, i.e. (Traffic ID, bandwidth).





Hao, et al.               Expires June 21, 2017                [Page 10]


Internet-Draft           Protocol Independent BW           December 2016


   o  Check in the Multicast RIB if the flow is available going through
      router.

      *  If the flow is present on the router, the outgoing interfaces
         will be identified.

      *  The bandwidth will be harden for the flow on the outgoing
         interfaces.

      *  The router will then add the outgoing interfaces to the new
         entry in the router PIB table, i.e. the critical info will be
         (Traffic ID, bandwidth, interfaces).

      *  The router will then report the status of the hardening for the
         indicated flow, i.e. (Traffic ID, bandwidth, interfaces)

   o  If the flow is not available on the router, the following steps
      will be taken.

      *  The router will add to its new PIB table a entry "NULL"
         indicating that the flow is not available on any interfaces on
         the router, i.e. (Trafic ID, bandwidth, NULL).

      *  The router report the information of (Trafic ID, bandwidth,
         NULL) to HBM

4.3.  Notification of PIB Status

   If there is an event on the router that the HBM needs to be aware of
   a notification will be sent to the HBM by the router.  Such an event
   might be that the multicast protocol removes a multicast group from
   the router.

   This might be done by sending the row for the flow or the entire PIB
   table for the router to the HBM.

4.4.  Release PIB Hardened Bandwidth

   If the HBM want to remove a certain flow from hardening, the HBM will
   configure all routers accordingly.  The result of the release will be
   reported to the HBM by the router-

4.5.  Configuration Example

   The network example in Figure 1 will serve to show how the PIB
   configuration works.  Below we are only disussing one flow or
   multicast group, a production network will have many multicast trees,
   but the principles for the PIB configuration is the same.



Hao, et al.               Expires June 21, 2017                [Page 11]


Internet-Draft           Protocol Independent BW           December 2016


   In the network there is a (S,G1) multicast group established, the
   source sends to A, A sends to B1, B1 sends to C1 and C3, C1 sends to
   sends to recerver 1 and C2 sends to receiver 2.

4.5.1.  Primary Configuration

   To configure this multicast tree with hardened bandwidth the HBM will
   configure all routers in the network that multicast group G1 should
   have a 10Mbit/s hardened bandwidth, the configuration parameters is
   (G1, 10M).


                          Source
                           /
                          A
                        /  \
                       B1---B2
                      /|\   /\
                     / | \ /  \
                    C1 C2 C3   C4
                    /      \
                   /        \
              Receiver1   Receiver2



              Figure 1: Topology where multicast traffic run

   After receiving this information, router B1 check its M-RIB and find
   that there are two output interfaces: B1-C1, B1-C3.  B1 will then
   take 3 actions:

   o  Allocate 10M hard bandwidth to group G1 on the two interfaces
      (B1-C1 and (B1-C3).

   o  Add entry for G1 to the local PIB table as (G1, 10M, interfaces
      (B1-C1, B1-C3))

   o  Report the successful configuration by sending the configured
      information (G1,10M interfaces(B1-C1,B1-C3)) to HBM.

   Router B2 will receive the configuration information at the same time
   as B1.  B2 will check its M-RIB table, and find the (S,G) multicast
   group does not pass through B2.  B2 will then take 2 actions.

   o  Add entry (G1,10M, interface(NULL)) to the local PIB table;

   o  Send the information (G1, 10M ,interface (NULL)) to HBM.



Hao, et al.               Expires June 21, 2017                [Page 12]


Internet-Draft           Protocol Independent BW           December 2016


   When the configuration in response to the configuration parameters
   (G1, 10M) is complete

   o  All routers finished deploying the (G1,10M), either after
      hardening the bandwidth on the interface or taken note of the flow
      and bandwidth, but that the flow is not presently present on the
      router.

   o  End to end multicast hardened tree for G1 is established.

   o  As the HBM gets the reports form all routers it isi able to build
      an global view of the 10Mbps hardened tree for G1.

   -

4.5.2.  Topology Change

   In case of there is topology change, if for example, the link B1-C3
   fails, the IGP and PIM will convergence and the multicast traffic for
   "receiver 1" will now go over the links B1-B2-C3.

   The IGP/PIM convergence will trigger all routers to check entire PIB
   table.  They will check the new M-RIB to see if the multicast group
   earlier configured on the router still go through the node and if
   there are new multicast groups going through the node,

   If there are multicast groups that does no longer passes through the
   node, the interfaces entry for that flow in the PIB table will be
   marked "NULL"

   If there are new multicast group passing through the not, for which
   there are already entries (with the interfaces set to NULL) in the
   PIB table, these multicast group will be hardened.

4.5.2.1.  Actions taken by B1 due to the topology change

   B1 will be triggered by the topology change to check the consistency
   between the PIB Table and the M-RIB.  When B1 checks for multicast
   group G1 it will find that the outgoing interfaces are now B1-C1 and
   B1-B2.

   B1 will take four actions:

   o  Change the entry in PIB table for G1 to (G1,10M, interfaces(B1-C1,
      B1-B2))

   o  Allocate 10M hardened bandwidth to G1 on new output interfaces
      B1-B2.



Hao, et al.               Expires June 21, 2017                [Page 13]


Internet-Draft           Protocol Independent BW           December 2016


   o  Relese the 10M hardened bandwidth for G1 on the interface B1-C3

   o  After the updates of all entries in the PIB table that were
      impacted by the topology change, B1 will report the whole new PIB
      table to the HBM.

4.5.2.2.  Actions taken by B2 due to the topology change

   B2 will be triggered by the topology change to check the consistency
   between the PIB Table and the M-RIB.  When B2 checks for multicast
   group G1 it will find that there is new outgoing interface B2-C3.

   B2 will take three actions:

   o  Change the entry in PIB table for G1 to (G1,10M, interface(B2-C3))

   o  Allocate the hardened bandwidth 10M to interface(B2-C3).

   o  After the updates of all entries in the PIB table that were
      impacted by the topology change, B1 will report the whole new PIB
      table to the HBM.

4.5.2.3.  PIB Table Convergence

   After the IGP/PIM convergence and the required updates of the PIB
   Tables, the status of the system will be:

   o  All routers have their PIB table converged.

   o  End to end multicast hardened tree for G1 have tree have been
      established.  The same is true for all other trees with PIB
      hardened bandwidth.

   o  HBM has its real time PIB table converged, and then it get an
      global view of all the hardened tree service again.

5.  PIB Convergence

   For a single router, when topology change, and after IGP/PIM
   converged, it will take some time for the router to re-deploy or
   release PIB hardened for each traffic flow (i.e. change each of the
   entry of the local PIB table).  When the router have finished to re-
   deploy the hardened bandwidth all the flows, we say that the PIB have
   converged.

   After the PIB Table on a router have converged, it will report the
   whole PIB table to the HBM.




Hao, et al.               Expires June 21, 2017                [Page 14]


Internet-Draft           Protocol Independent BW           December 2016


   After the HBM have received the post-topology change reports for all
   routers, the HBM is able to bring the Real Time PIB table up to date,
   and thus have a global of all the active PIB services.

   In order to allow the HBM to have an accurate view of the network
   topology

6.  PIB Configuration Protocol

   To be discussed in a future version of tis document

7.  PIB Applicability

   This version of the document does describe the PIB hardening IP
   multicast flows.

   Other flows are for further study.

8.  Security Considerations

   To be added in a future version of the document.

9.  IANA Considerations

   There are no requests for IANA actions in this document.

   Note to the RFC Editor - this section can be removed before
   publication.

10.  Acknowledgements

   -

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC7582]  Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers,
              "Multicast Virtual Private Network (MVPN): Using
              Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582,
              July 2015, <http://www.rfc-editor.org/info/rfc7582>.





Hao, et al.               Expires June 21, 2017                [Page 15]


Internet-Draft           Protocol Independent BW           December 2016


11.2.  Informative References

   [RFC7625]  Hao, J., Maheshwari, P., Huang, R., Andersson, L., and M.
              Chen, "Architecture of an IP/MPLS Network with Hardened
              Pipes", RFC 7625, DOI 10.17487/RFC7625, August 2015,
              <http://www.rfc-editor.org/info/rfc7625>.

Authors' Addresses

   Jiangtao Hao
   Huawei Technologies
   Huanbaoyuan, No.156, BeiQing Road
   Beijing
   China

   Email: haojiangtao@huawei.com


   Soh Keng Hock
   Singtel
   31 Exeter Road, Comcentre
   Singapore  239732
   Singapore

   Email: khsoh@singtel.com


   Loa Andersson
   Huawei Technologies

   Email: loa@pi.nu


   Gang Gai
   Huawei Technologies
   Huanbaoyuan, No.156, BeiQing Road
   Beijing
   China

   Email: gaigang@huawei.com











Hao, et al.               Expires June 21, 2017                [Page 16]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/