| RTGWG Working Group | KH. Soh |
| Internet-Draft | Singtel |
| Intended status: Informational | JT. Hao |
| Expires: June 19, 2017 | L. Andersson |
| G. Gai | |
| Huawei Technologies | |
| December 16, 2016 |
Protocol Independent (Hardened) Bandwidth
draft-hao-rtgwg-ip-hard-pipes-01.txt
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.
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 19, 2017.
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 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.
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.
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].
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 [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.
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 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.
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 Section 3.3.1.
The list below describes functions that may be used by the HBM and what the output from each function is.
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.
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 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 Section 3.6.2, 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 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.
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.
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.
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 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.
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).
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:
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.
When the configuration in response to the configuration parameters (G1, 10M) is complete
-
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:
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:
After the IGP/PIM convergence and the required updates of the PIB Tables, the status of the system will be:
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.
-
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [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. |
| [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. |