Internet DRAFT - draft-hao-rtgwg-ip-hard-pipes
draft-hao-rtgwg-ip-hard-pipes
RTGWG Working Group JT. Hao
Internet-Draft Huawei Technologies
Intended status: Informational K. Soh
Expires: December 15, 2017 Singtel
L. Andersson
G. Gai
Huawei Technologies
June 13, 2017
Protocol Independent (Hardened) Bandwidth
draft-hao-rtgwg-ip-hard-pipes-03.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 December 15, 2017.
Copyright Notice
Copyright (c) 2017 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 December 15, 2017 [Page 1]
Internet-Draft Protocol Independent BW June 2017
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 December 15, 2017 [Page 2]
Internet-Draft Protocol Independent BW June 2017
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 December 15, 2017 [Page 3]
Internet-Draft Protocol Independent BW June 2017
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 December 15, 2017 [Page 4]
Internet-Draft Protocol Independent BW June 2017
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 December 15, 2017 [Page 5]
Internet-Draft Protocol Independent BW June 2017
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 December 15, 2017 [Page 6]
Internet-Draft Protocol Independent BW June 2017
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 December 15, 2017 [Page 7]
Internet-Draft Protocol Independent BW June 2017
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 December 15, 2017 [Page 8]
Internet-Draft Protocol Independent BW June 2017
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 December 15, 2017 [Page 9]
Internet-Draft Protocol Independent BW June 2017
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 December 15, 2017 [Page 10]
Internet-Draft Protocol Independent BW June 2017
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 December 15, 2017 [Page 11]
Internet-Draft Protocol Independent BW June 2017
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 December 15, 2017 [Page 12]
Internet-Draft Protocol Independent BW June 2017
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 December 15, 2017 [Page 13]
Internet-Draft Protocol Independent BW June 2017
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 December 15, 2017 [Page 14]
Internet-Draft Protocol Independent BW June 2017
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 December 15, 2017 [Page 15]
Internet-Draft Protocol Independent BW June 2017
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 December 15, 2017 [Page 16]
