Protocol Independent (Hardened) Bandwidth

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.

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

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.

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.

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 . Since such is not part of the Diff Serv scheduling it will be smoother. In IP multicast scenarios (e.g. RFC 7582 ), 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.

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.

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.

A PIB Enabled router will be configured to assign hardened bandwidth to a particular multicast flow (see ) by the HBM (see ). 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.

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.

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 flows. These functions may be created for the HBM, or generally available in carrier grade networks. Examples of such functions are discussed in .

The list below describes functions that may be used by the HBM and what the output from each function is. 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. 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 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 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. 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.

The functions in the list in 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.

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. 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. 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. 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. This list will be extended in future versions of the document.

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. A PIB enabled router keeps PIB table see , that keeps track of all requests for hardened bandwidth and of all actions the router taken to harden bandwidth.

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.

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.

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.

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).

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. 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 . The Real Time PIB table allow the HBM to have a global view of the multicast tree and bandwidth resource consumption in the network.

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 .

This section list and explain the PIB configuration actions.

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.

When a router learns of the intent to harden the bandwidth for a flow (Trafic ID, bandwidth), it will take the following steps. Add the indicted flow and the amount of bandwidth to be hardened to the routers PIB table, i.e. (Traffic ID, bandwidth). 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) 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

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.

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-

The network example in 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. 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.

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).

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: Allocate 10M hard bandwidth to group G1 on the two interfaces (B1-C1 and (B1-C3). Add entry for G1 to the local PIB table as (G1, 10M, interfaces (B1-C1, B1-C3)) 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. Add entry (G1,10M, interface(NULL)) to the local PIB table; Send the information (G1, 10M ,interface (NULL)) to HBM. When the configuration in response to the configuration parameters (G1, 10M) is complete 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. End to end multicast hardened tree for G1 is established. As the HBM gets the reports form all routers it isi able to build an global view of the 10Mbps hardened tree for G1. -

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.

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: Change the entry in PIB table for G1 to (G1,10M, interfaces(B1-C1, B1-B2)) Allocate 10M hardened bandwidth to G1 on new output interfaces B1-B2. Relese the 10M hardened bandwidth for G1 on the interface B1-C3 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.

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: Change the entry in PIB table for G1 to (G1,10M, interface(B2-C3)) Allocate the hardened bandwidth 10M to interface(B2-C3). 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.

After the IGP/PIM convergence and the required updates of the PIB Tables, the status of the system will be: All routers have their PIB table converged. 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. HBM has its real time PIB table converged, and then it get an global view of all the hardened tree service again.

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

To be discussed in a future version of tis document

This version of the document does describe the PIB hardening IP multicast flows. Other flows are for further study.

To be added in a future version of the document.

There are no requests for IANA actions in this document. Note to the RFC Editor - this section can be removed before publication.