Architecture of MPLS/IP Network with Hardened Pipes
draft-hao-mpls-ip-hard-pipe-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7625.
|
|
|---|---|---|---|
| Authors | JiangTao Hao , Praveen Maheshwari , River Huang , Loa Andersson , Mach Chen | ||
| Last updated | 2015-03-23 (Latest revision 2014-09-29) | ||
| RFC stream | Independent Submission | ||
| Formats | |||
| IETF conflict review | conflict-review-hao-mpls-ip-hard-pipe, conflict-review-hao-mpls-ip-hard-pipe, conflict-review-hao-mpls-ip-hard-pipe, conflict-review-hao-mpls-ip-hard-pipe, conflict-review-hao-mpls-ip-hard-pipe | ||
| Additional resources | |||
| Stream | ISE state | In ISE Review | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 7625 (Informational) | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hao-mpls-ip-hard-pipe-01
Network Working Group J. T. Hao
Internet-Draft Huawei Technologies Co., Ltd
Intended status: Informational P. Maheshwari
Expires: April 2, 2015 Bharti Airtel Ltd.
R. Huang
L. Andersson
M. Chen
Huawei Technologies Co., Ltd
September 29, 2014
Architecture of MPLS/IP Network with Hardened Pipes
draft-hao-mpls-ip-hard-pipe-01.txt
Abstract
This document is intended to become an Informational RFC on the
independent stream. The document does not specify any new protocol
or procedures. It does explain how the MPLS standards
implementation, has been deployed and operated to meet the
requirements from operators that offer traditional Virtual Leased
Line services.
This document describes an MPLS/IP network that has an infrastructure
that can be separated into two or more strata. For the
implementation described in this document the infrastructure has been
separated into two strata. One for the 'Hard Pipes', called the
'Hard Pipe Stratum". And one for the normal IP/MPLS traffic - called
the 'Normal IP/MPLS stratum'.
This document introduces the concept of "Hard Pipes", a Hard Pipe is
an MPLS Label Switched Path (LSP) or a Pseudowire (PW) with a
bandwidth that is guaranteed and can neither be exceeded nor
infringed upon.
The Hard Pipe stratum does not use statistical multiplexing, for the
LSPs and PWs setup within this stratum the bandwidth are guaranteed
end to end.
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/.
T. Hao, et al. Expires April 2, 2015 [Page 1]
Internet-Draft Hard IP Pipes September 2014
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 April 2, 2015.
Copyright Notice
Copyright (c) 2014 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2. The strata network . . . . . . . . . . . . . . . . . . . . . 5
2.1. The Physical Network . . . . . . . . . . . . . . . . . . 5
2.2. The Hard Pipe stratum . . . . . . . . . . . . . . . . . . 5
2.3. The Normal IP/MPLS stratum . . . . . . . . . . . . . . . 6
2.4. Stratum Networks . . . . . . . . . . . . . . . . . . . . 7
3. Configuring the Leased Lines in Hard Pipe Stratum . . . . . . 7
4. Efficient State Management . . . . . . . . . . . . . . . . . 8
4.1. State in the Forwarding Plane . . . . . . . . . . . . . . 9
4.2. State in the NMS . . . . . . . . . . . . . . . . . . . . 9
4.3. Annotations for Configuring Leased Lines . . . . . . . . 9
5. Setting Up Leased Lines . . . . . . . . . . . . . . . . . . . 11
6. Leased Line protection . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10. Informative References . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
T. Hao, et al. Expires April 2, 2015 [Page 2]
Internet-Draft Hard IP Pipes September 2014
1. Introduction
IP leased line services and Time Division Multiplex (TDM) leased line
services are commonly offered by operators worldwide.
There are customers, e.g. many enterprises, which insist on TDM
leased line services. They do so regardless of that the same
operators often offer IP leased line services to a lower price and
with a guaranteed bandwidth.
Today we see a trend that the TDM networks gradually carries less and
less traffic, and many operators want to shut their TDM networks down
to save cost.
The operators and vendors that built and deployed the Hard Pipe
service described in this document did so recognizing the trends
outlined above. A way to introduce leased line service with the same
characteristics as TDM leased line services in IP/MPLS networks was
created.
Even if Leased Lines has been the initially motivation to define the
Hard pipe technology, the Hard Pipes is by no means limited to
support Leased Line services. When guaranteed bandwidth are the
priority Virtual Private Wire Services (VPWS), Virtual Private LAN
Services (VPLS) L3 Virtual Private Networks (L3VPN) and IP only
Private LAN Services can be mapped to a tunnel in the Hard Pipe
stratum.
The Virtual Leased Line (VLL) service is used for the examples
throughout this document.
The solution soon to be deployed has an Ethernet infrastructure,
which has been split into two parallel logical networks - two
parallel strata. The first stratum - the Hard Pipe stratum - does
not use statistical multiplexing, and bandwidth is guaranteed end to
end. The second stratum - Normal IP/MPLS stratum - works as a normal
IP/MPLS network. The two strata share the same physical network,
i.e. routers and links. The routers will handle the traffic
belonging to one stratum different from how traffic the other stratum
is handled.
The reader of this document is assumed to be familiar with RFC 3031
[RFC3031] and RFC 5921 [RFC5921].
T. Hao, et al. Expires April 2, 2015 [Page 3]
Internet-Draft Hard IP Pipes September 2014
1.1. Scope
This document has the following purposes:
o To introduce a two strata MPLS/IP network, the purpose of one of
the strata is to provide capabilities for services that are from a
customer's point of view functionally identical to TDM like leased
lines.
o To indicate how a router differentiates the traffic of the two
strata.
1.2. Abbreviations
CC, Continuity Check
CV, Connection Verification
L-label, Leased Line label
LSP, Label Switched Path
LSR, Label Switching Router
MPLS-TP, MPLS Transport Profile
NMS, Network Management System
OAM, Operation, Administration and Maintenance
P, Provider Router
PE, Provider Edge Router
PW, Pseudowire
T-label, Tunnel label
TDM, Time Division Multiplexing
tLDP, Targeted LDP
VLL, Virtual Leased Line
VPLS, Virtual Private LAN Service
VPWS, Virtual Private Wire Service
T. Hao, et al. Expires April 2, 2015 [Page 4]
Internet-Draft Hard IP Pipes September 2014
2. The strata network
The concept of stratified or strata networks has been around for some
time. It has come to have different meaning in different contexts.
The way we use the concept is that we logically assign certain
characteristics to part of the network. The part of the network that
has the special characteristics form one stratum and the "reminder" a
second stratum. The network described in this document uses a single
link layer technology, Ethernet.
In many cases, a whole physical interface is assigned to hard
stratum. Especially in the scenario that there are many physical
links between two nodes.
2.1. The Physical Network
Consider a network with 10 routers and all the links between are 10G
Ethernet, such as shown in Figure 1. This is the network topology
we've used for this model, and also (with topology variations) in our
first deployment.
+---+ 10G +---+ 10G +---+ 10G +---+
+---| B |-----------| C |-----------| D |----------| E |---+
10G | +---+ +---+ +---+ +---+ | 10G
| | | | | |
+---+ | 10G 10G | 10G | 10G | +---+
--| F | | | | | | G |--
+---+ | | | | +---+
| | | | | |
10G | +---+ +---+ +---+ +---+ | 10G
+---| H |-----------| J |-----------| K |----------| L |---+
+---+ 10G +---+ 10G +---+ 10G +---+
Figure 1
In this document we use the term traffic matrix or estimated traffic
matrix to indicate an estimate of how much traffic that will flow
between the ingress and egress (PE) nodes. This may be translated
into how much bandwidth is needed per link in the Hard Pipe stratum.
2.2. The Hard Pipe stratum
We now wish to to define a Hard Pipe stratum, i.e. a part of the
network that treat all packets without introducing any delay.
T. Hao, et al. Expires April 2, 2015 [Page 5]
Internet-Draft Hard IP Pipes September 2014
Starting from an estimated traffic matrix it is possible reserve
bandwidth on the links of the Ethernet Link Layer network for the
Hard Pipes.
Note that the implication is that he normal traffic get the remainder
of the available bandwidth. Thus the link layer network will be
split into two logical networks, or two strata. One stratum to be
used for the hardened pipe network, the other for the 'normal' IP and
MPLS traffic. This is shown in Figure 2 and Figure 3.
The Hard Pipe Stratum:
+---+ 2G +---+ +---+
+---| B |-----------| C | | E |---+
1G | +---+ +---+ +---+ | 2G
| | | |
+---+ 2G | 1G | +---+
--| F | | | | G |--
+---+ | | +---+
| | | |
1G | +---+ +---+ +---+ +---+ | 2G
+---| H |-----------| J |-----------| K |----------| L |---+
+---+ 2G +---+ 4G +---+ 4G +---+
Figure 2
It is worth noting that even if the figures in this document are
drawn to indicate "bandwidth on the link", the only bandwidth
information that the nodes have available is the bandwidth assigned
to the Hard Pipe stratum and the Normal IP/MPLS stratum. All other
information is kept on the NMS. The NMS keeps a global bandwidth
resource table for the Hard Pipe stratum.
2.3. The Normal IP/MPLS stratum
Given that the starting point is the physical network in Figure 1 and
the Hard Pipe stratum as defined in in Figure 2, the Normal IP/MPLS
stratum will look as in Figure 3:
T. Hao, et al. Expires April 2, 2015 [Page 6]
Internet-Draft Hard IP Pipes September 2014
The Normal IP/MPLS Stratum:
+---+ 8G +---+ 10G +---+ 10G +---+
+---| B |-----------| C |-----------| D |----------| E |---+
9G | +---+ +---+ +---+ +---+ | 8G
| | | | | |
+---+ | 10G 8G | 10G | 9G | +---+
--| F | | | | | | G |--
+---+ | | | | +---+
| | | | | |
9G | +---+ +---+ +---+ +---+ | 9G
+---| H |-----------| J |-----------| K |----------| L |---+
+---+ 8G +---+ 6G +---+ 6G +---+
Figure 3
2.4. Stratum Networks
Stratum networks as we use the concept can be seen as two basically
parallel logical networks with strictly separated resources. Traffic
sent over one stratum network can not infringe on traffic in the
other stratum network.
In the case described here, all the traffic in the Hard Pipe stratum
is MPLS-encapsulated. A number of the labels have been set aside so
other applications can't allocate them and so the routers recognize
them as belonging to the Hard Pipe application.
3. Configuring the Leased Lines in Hard Pipe Stratum
o If an operator want to set up a leased line it is first checked
that there is a path available in the Hard Pipe stratum that
matches the criteria (e.g. bandwidth) for the requested leased
line.
* if such a path does exist, it is checked if there is a matching
MPLS tunnel available over that path.
+ if such a tunnel exists, it is used to establish the leased
line by adding L-labels forming an LSP that are carried by
the tunnel. L-labels are onlt understood know by the
ingress and egress LSRs. They local to the end points the
same way as label signalled by Targeted LDP (tLDP) [RFC5036]
are local the end points of a targeted session LSP.
T. Hao, et al. Expires April 2, 2015 [Page 7]
Internet-Draft Hard IP Pipes September 2014
At the same time the available bandwidth in the Hard Pipe
stratum is decremented by the bandwidth that is needed for
the leased line for every hop across this stratum in the
global resource table (for the Hard Pipe stratum).
+ if such a tunnel does not exist, it can be established so
that the leased line can be set up as above.
* If the path does not exist (not enough bandwidth in Hard Pipe
stratum for the leased line), available bandwidth on the links
is checked to see if the stratum can be expanded to accommodate
such a path.
+ If the Hard Pipe stratum can be expanded, this is done and
the tunnel for the leased line is established as described
above.
It is likely that other modifications of the Hard Pipe
stratum, e.g. consolidating already set up Hard IP tunnels
on to existing links so that room for new Leased Lines are
created may have implication that goes well outside the
Leased Line service, and it is currently not viewed as a
fully automated operation.
+ If it is not possible to expand the Hard Pipe stratum to
accommodate the new path, set up of the leased line will
need to be declined.
Thus, given the existing of a viable Hard Pipe stratum, Leased Lines
are configured in two very simple steps. First, establish a hop-by-
hop tunnel (T-labels), and second configure the leased lines
(L-labels). The T-labels need to be configured on both PE and P
routers, while L-Labels only need to be configured on the PE routers.
Note that L labels may be used for normal IP service [RFC3031], for
BGP/MPLS VPNs [RFC4364] or for PWs [RFC3985].
4. Efficient State Management
The system as described here generates a very small amount of state,
and most of it is kept in the NMS.
T. Hao, et al. Expires April 2, 2015 [Page 8]
Internet-Draft Hard IP Pipes September 2014
4.1. State in the Forwarding Plane
The only configured information that are actually kept on the LSRs
are
o the information needed for the label swapping procedures, i.e.
incoming label to outgoing label and port, and whether the label
belongs to the set of labels that are set aside for the Hard Pipe
stratum tunnels.
o the bandwidth available for the Hard Pipe stratum and the Normal
IP/MPLS stratum
4.2. State in the NMS
The following state needs to be kept in the NMS
o the topology and bandwidth resources available in the Hard Pipe
network, see Figure 2.
o the total and available bandwidth per link in the Hard Pipe
network see Figure 4.
o the tunnel label mappings (T-labels) see Figure 5.
o the Leased Line label mappings (L-labels) see Figure 6.
o the reserved bandwidth, as well as other constraints and the path
per Leased Line (L-labels)
4.3. Annotations for Configuring Leased Lines
The annotations given below are not a programming guideline or an
indication how this architecture could be implemented. It is rather
an indication of how much data that needs to be saved for each
stratum and leased line, as well as where this data could be stored.
Consider the Hard Pipe stratum as it has been outline in Figure 2,
actually there is some additional information related to the Hard
Pipe Stratum that not is shown in the figure.
Looking explicitly on the link between LSR J and K we find:
T. Hao, et al. Expires April 2, 2015 [Page 9]
Internet-Draft Hard IP Pipes September 2014
+---+ +---+ +---+ +---+
---| H |-----------| J |-----------| K |----------| L |---
+---+ +---+ +---+ +---+
[4,0]G
Figure 4
The annotation [4,0]G means that the bandwidth on the link between J
and K there are 4G allocated to the stratum and of these 0G has been
allocated to a service.
If we were to allocate two tunnels labels from the labels that has
been configured to work within the Hard Pipe stratum the resource
view would look like this:
+---+ +---+ +---+ +---+
---| H |-----------| J |-----------| K |----------| L |---
+---+ +---+ +---+ +---+
[4,0]G T1 ,T2
Figure 5
Note that allocating the tunnel labels does not reserve bandwidth for
the tunnel from the Hard Pipe stratum.
When the leased line labels (L-labels) are assigned this will consume
bandwidth, so we need to keep track of the bandwidth per leased line
and the total of bandwidth allocated from the Hard Pipe stratum.
The annotation for the link between J and K could look like this:
+---+ +---+ +---+ +---+
---| H |-----------| J |-----------| K |----------| L |---
+---+ +---+ +---+ +---+
[4,1.5]G, T1, L1 [.5], L2 [.5], T2, L1 [.5]
Figure 6
The line [4,1.5]G, T1, L1 [.5], L2 [.5], T2, L1 [.5] would be
interpreted as:
T. Hao, et al. Expires April 2, 2015 [Page 10]
Internet-Draft Hard IP Pipes September 2014
The Hard Pipe Stratum link between nodes J and K has 4 G bandwidth
allocated; of the total bandwidth 1.5 G are allocated for Leased
Lines.
Tunnel label T1, carries two Leased Lines, each of 0.5G and tunnel
label T2 carries a third Leased Line of 0.5G.
Note that it is not necessary to keep this information in the nodes,
it is held within the NMS, it is also strictly not necessary to keep
the bandwidth per leased line, but some operations are simplified
(e.g. removing a leased line) if this is done.
5. Setting Up Leased Lines
Consider that the case where an operator want to set up a Leased Line
of 0.4G from F to G in the Hard Pipe stratum in Figure 2.
Since there are no other constraints than bandwidth and ingress and
egress PEs, the shortest path will be chosen. A tunnel will be
configure from F to G over the following nodes. F, H, J, K, L and G,
and a Leased Line label (a) will be configured on F and G, and the
available resources recalculated.
A second leased line of 0.3G between the same PEs is easily configure
by adding a new Leased Line label (b) at the ingress and egress PEs.
After these operations a view of the Hard Pipe stratum resources
(avaiable bandwidth) would look like this:
The Hard Pipe Stratum:
+---+ 2G +---+ +---+
+---| B |-----------| C | | E |---+
1G | +---+ +---+ +---+ | 2G
| | | |
+---+ 2G | 1G | +---+
--| F | | | | G |--
+---+ | | +---+
| | | |
.3G | +---+ +---+ +---+ +---+ | 1.3G
+---| H |-----------| J |-----------| K |----------| L |---+
+---+ 1.3G +---+ 3.3G +---+ 3.3G +---+
Figure 7
T. Hao, et al. Expires April 2, 2015 [Page 11]
Internet-Draft Hard IP Pipes September 2014
If the operator now wishes to establish a new leased line with the
criteria that it should originate from F and terminate at G, have
0.4G bandwidth and pass through node E, analysis of the Hard Pipe
stratum (after establishing the first two listed lines) and the
criteria for the new leased line would give the following;
o the existing tunnel cannot be used, since it does not pass through
E; a new tunnel need to be established.
o the hop from F to H cannot be used since the available bandwidth
is insufficient.
o since no existing meet the criteria requested, a new tunnel will
be set up from F, to B, C, J, K, L, E (the criteria to pass
through E) and to G.
A new L-label (c) to be carried over T2 will be configured on F and
G, and the available resources of the Hard Pipe stratum will be
recalculated.
6. Leased Line protection
This leased line service uses the MPLS Transport Profile (MPLS-TP)
line protection as it is defined in RFC 6378 [RFC6378], updated as
specified in RFC 7271 [RFC7271] and RFC 7324 [RFC7324]
The Connection Verification (CV) and Continuity Check (CC) are run
over the tunnels, i.e. the entire tunnel is protected end to end.
In general all of the MPLS-TP Operation, Administration and
Maintenance (OAM), as defined in RFC 6371 [RFC6371] is applicable.
7. Security Considerations
The security considerations as defined in RFC 5920 "Security
Framework for MPLS and GMPLS Networks" [RFC5920] and RFC RFC 6941
"MPLS Transport Profile (MPLS-TP) Security Framework" [RFC6941] apply
to this document.
8. IANA Considerations
There are no requests for IANA actions in this document.
Note to the RFC Editor, this section may be removed before
publication.
T. Hao, et al. Expires April 2, 2015 [Page 12]
Internet-Draft Hard IP Pipes September 2014
9. Acknowledgements
The authors want to thank Andy Malis for detailed technical and
language review and for valuable comments.
10. Informative References
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "A Framework for MPLS in Transport Networks", RFC
5921, July 2010.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
Maintenance Framework for MPLS-Based Transport Networks",
RFC 6371, September 2011.
[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and
A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear
Protection", RFC 6378, October 2011.
[RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R.
Graveman, "MPLS Transport Profile (MPLS-TP) Security
Framework", RFC 6941, April 2013.
[RFC7271] Ryoo, J., Gray, E., van Helvoort, H., D'Alessandro, A.,
Cheung, T., and E. Osborne, "MPLS Transport Profile (MPLS-
TP) Linear Protection to Match the Operational
Expectations of Synchronous Digital Hierarchy, Optical
Transport Network, and Ethernet Transport Network
Operators", RFC 7271, June 2014.
[RFC7324] Osborne, E., "Updates to MPLS Transport Profile Linear
Protection", RFC 7324, July 2014.
T. Hao, et al. Expires April 2, 2015 [Page 13]
Internet-Draft Hard IP Pipes September 2014
Authors' Addresses
JiangTao Hao
Huawei Technologies Co., Ltd
Q13 Huawei Campus
No. 156 Beiqing Road
Hai-dian District
Beijing 100095
China
Email: haojiangtao@huawei.com
Praveen Maheshwari
Bharti Airtel Ltd.
Plot No. 16, Udyog Bihar,
Phase IV, Gurgaon - 122015
Haryana
India
Email: Praveen.Maheshwari@in.airtel.com
River Huang
Huawei Technologies Co., Ltd
Q13 Huawei Campus
No. 156 Beiqing Road
Hai-dian District
Beijing 100095
China
Email: river.huang@huawei.com
Loa Andersson
Huawei Technologies Co., Ltd
Stockholm
Sweden
Email: loa@mail01.huawei.com
T. Hao, et al. Expires April 2, 2015 [Page 14]
Internet-Draft Hard IP Pipes September 2014
Mach Chen
Huawei Technologies Co., Ltd
Q13 Huawei Campus
No. 156 Beiqing Road
Hai-dian District
Beijing 100095
China
Email: mach.chen@huawei.com
T. Hao, et al. Expires April 2, 2015 [Page 15]