wdiff rfc7625.original rfc7625.txt

Network Working Group
Independent Submission J. T. Hao
Internet-Draft
Request for Comments: 7625 Huawei Technologies Co., Ltd
Intended status:
Category: Informational P. Maheshwari
Expires: November 13, 2015
ISSN: 2070-1721 Bharti Airtel Airtel, Ltd.
R. Huang
L. Andersson
M. Chen
Huawei Technologies Co., Ltd
May 12,
August 2015

Architecture of MPLS/IP an IP/MPLS Network with Hardened Pipes
draft-hao-mpls-ip-hard-pipe-02.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 IP/MPLS network that has an infrastructure
that can be separated into two or more strata. For the
implementation described in this document document, the infrastructure has
been separated into two strata. One strata: one for the 'Hard Pipes', "Hard Pipes", called the
'Hard
"Hard Pipe Stratum". And Stratum", and one for the normal IP/MPLS traffic - traffic, called
the 'Normal "Normal IP/MPLS stratum'. Stratum".

This document introduces the concept of "Hard Pipes", a Hard Pipe is -- an MPLS Label
Switched Path (LSP) or a Pseudowire 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, multiplexing; for the
LSPs and PWs setup set up within this stratum stratum, the bandwidth are is guaranteed
end to end.

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 (VLL) services.

Status of This Memo

This Internet-Draft document is submitted in full conformance with not an Internet Standards Track specification; it is
published for informational purposes.

This is a contribution to the
provisions RFC Series, independently of BCP 78 any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and BCP 79.

Internet-Drafts makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are working documents not a candidate for any level of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list
Standard; see Section 2 of RFC 5741.

Information about the current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 November 13, 2015.
http://www.rfc-editor.org/info/rfc7625.

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 . . Stratified Network . . . . . . . . . . . . . . . . . . . 5
2.1. The Physical Network . . . . . . . . . . . . . . . . . . 5 6
2.2. The Hard Pipe stratum Stratum . . . . . . . . . . . . . . . . . . 6
2.3. The Normal IP/MPLS stratum Stratum . . . . . . . . . . . . . . . 7
2.4. Stratum Networks . . . . . . . . . . . . . . . . . . . . 8 7
3. Configuring the Leased Lines in the Hard Pipe Stratum . . . . . . 8
4. Efficient State Management . . . . . . . . . . . . . . . . . 10 9
4.1. State in the Forwarding Plane . . . . . . . . . . . . . . 10 9
4.2. State in the NMS . . . . . NMS/Controller . . . . . . . . . . . . . . . 10
4.3. Annotations for Configuring Leased Lines . . . . . . . . 10
5. Setting Up Leased Lines . . . . . . . . . . . . . . . . . . . 12
6. Leased Line protection Protection . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 13
8. IANA Considerations . . Informative References . . . . . . . . . . . . . . . . . . . 14
9. 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
10. Informative References . . . . . . . . . . . . . . . . . . . 14 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15

1. Introduction

IP leased line services, Ethernet Private Line (EPL) (EPL), and Time Time-
Division Multiplex Multiplexed (TDM) leased line services are commonly offered
by operators worldwide.

There are customers, e.g. e.g., many enterprises, which that insist on TDM
leased line services. They do so regardless of the fact that the
same operators often offer IP leased line services, services and EPL services, services
at a lower price and with a guaranteed bandwidth.

Today we see a trend that the TDM (in particular SDH/SONET) particular, Synchronous Digital
Hierarchy / Synchronous Optical Network (SDH/SONET)) networks are
gradually carries carrying less and less traffic, and many operators want to
shut their TDM networks down to save cost.

The reduce costs.

In light of these trends, vendors and operators that build have built and deploy
deployed the Hard Pipe service described in this document do so recognizing the trends outlined
above. A document. It is a
way to introduce leased line service with the same characteristics as
TDM leased line services in IP/MPLS networks was
created. networks.

Even if Leased Line leased line has been the initially initial motivation to define the
Hard pipe Pipe technology, the Hard Pipe is by no means limited to support
Leased Line
leased line services. When guaranteed bandwidth is the priority priority,
Virtual Private Wire Services (VPWS), Virtual Private LAN Services
(VPLS)
(VPLS), L3 Virtual Private Networks (L3VPN) (L3VPN), and IP only IP-only Private LAN
Services can be mapped to a tunnel in the Hard Pipe stratum.

EPL and EPLAN (Ethernet Ethernet Private LAN) LAN (EPLAN) are out of scope for this
document.

The

Virtual Leased Line (VLL) service is used for the in examples throughout this
document.

The solution soon to be deployed has an Ethernet infrastructure,
which infrastructure that
has been split into two parallel logical networks - -- two parallel
strata. The first stratum - -- the Hard Pipe stratum - Stratum -- does not use
statistical multiplexing, and bandwidth is guaranteed end to end.
The second stratum - -- the Normal IP/MPLS stratum - Stratum -- works as a normal
IP/MPLS network. The two strata share the same physical network,
i.e.
i.e., routers and links. But links, but the resource reserved for the Hard Pipe
stratum will never be preempted by the Normal IP/MPLS stratum.

The routers will handle the traffic belonging to one stratum
different
differently from how traffic from the other stratum is handled. This
separation in traffic handling is based on support in hardware.

The reader of this document is assumed to be familiar with RFC 3031
[RFC3031] and RFC 5921 [RFC5921].

1.1. Scope

This document has the following purposes:

o To to introduce a two strata MPLS/IP network, IP/MPLS network: the purpose of one of
the strata is to provide capabilities for services that are are, from
a customer's point of view view, functionally identical to TDM like TDM-like
leased
lines. lines; and

o To to indicate how a router differentiates the traffic of the two
strata.

1.2. Abbreviations

CC,

CC: Continuity Check

CV,

CV: Connection Verification

L-label,

L-label: Leased Line label

LSP,

LSP: Label Switched Path

LSR,
LSR: Label Switching Router

MPLS-TP,

MPLS-TP: MPLS Transport Profile

NMS,

NMS: Network Management System

OAM, Operation, Administration

OAM: Operations, Administration, and Maintenance

P: Provider Router

PE,

PE: Provider Edge Router

PW,

PW: Pseudowire

T-label,

T-label: Tunnel label

TDM, Time Division

TDM: Time-Division Multiplexing

tLDP,

tLDP: Targeted LDP

VLL,

VLL: Virtual Leased Line

VPLS,

VPLS: Virtual Private LAN Service
VPWS,

VPWS: Virtual Private Wire Service

2. The strata network Stratified Network

The concept of stratified or strata networks has been around for some
time. It appears 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 stratum, and the "remainder " "remainder"
forms a second stratum. The network described in this document uses
a single link layer link-layer technology, Ethernet.

In many cases, a whole physical interface is assigned to a single
hard stratum. Especially stratum, especially in the scenario that where there are many
physical links between two nodes.

This document does not address the network configuration
possibilities for Hard Pipe and IP/MPLS strata in detail. There are
configuration options, the basic configuration is that one Hard Pipe
stratum and one IP/MPLS stratum are provisioned.

However

However, it is also possible to provision more than one Hard Pipe
stratum, e.g. e.g., if customers want enhanced separation for their leased
line. Even though the main driver for the Hard Pipe technology is
the leased lines, any service for which an operator does not want to
use statistical multiplexing will benefit from using the Hard Pipes.

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, 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 document, we use the term traffic matrix terms "traffic matrix" or estimated "estimated
traffic
matrix 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 Stratum

When the intention is to define a Hard Pipe stratum, it is is, for
example
example, possible to start from an estimated traffic matrix to
estimate how much bandwidth to reserve on the links of the Ethernet
Link Layer
link-layer network for the Hard Pipes.

Note that the implication is that the normal traffic gets the
remainder of the available bandwidth. Thus Thus, the link layer link-layer network
will be split into two logical networks, or two strata. One strata -- one stratum
to be used
for the hardened pipe network, network and the other for the "normal" IP and
MPLS traffic. This is shown in Figure Figures 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 2: The Hard Pipe Stratum

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. NMS/Controller. The NMS NMS/Controller keeps
a global bandwidth resource table for the Hard Pipe stratum.

2.3. The Normal IP/MPLS stratum 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 is shown in Figure 3:

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 3: The Normal IP/MPLS Stratum

2.4. Stratum Networks

Stratum networks the way we use

In this document, the concept can be seen as two of stratum network is used to indicate
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. 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 the Hard Pipe Stratum

When the strata are provisioned provisioned, the IP/MPLS stratum is set up
exactly as any other IP/MPLS network. The one small difference
between provisioning the Hard Pipe stratum and the IP/MPLS stratum is
that no overbooking is done for the Hard Pipe stratum.

Overbooking and/or congestion in the IP/MPLS stratum can not effect affect
the Hard Pipe stratum.

All labels used for the Hard Pipe stratum are "Configured Labels",
i.e.
i.e., labels that are provisioned and reclaimed by management
actions. These management actions can be by manual actions or by an
NMS
NMS/Controller or a centralized controller. For the size of network
being
deployed deployed, manual configuration is not practical, practical; we are doing both
provisioning and reclaiming a labels label from an NMS. NMS/Controller.

o If an operator want wants to set up a leased line line, it is first checked
if there is a path available in the Hard Pipe stratum that matches
the criteria (e.g. (e.g., bandwidth) for the requested leased line.

* if If such a path does exist, it is checked if there is a matching
MPLS tunnel available over that path.

+ if 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 known only by the ingress and
egress LSRs. They are local to the end points endpoints the same way
as
that the label signalled signaled by Targeted LDP (tLDP) [RFC5036] are is local to
the end points endpoints of a targeted session LSP. (Here, "Targeted
LDP" means LDP as defined in RFC 5036 [RFC5036], using
Targeted Hello messages.)

At the same time 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 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 the 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. e.g., consolidating already set up Hard IP tunnels
on to existing links so that room for new Leased Lines leased lines are
created
created, may have implication implications that goes go well outside the
Leased Line
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 existence of a viable Hard Pipe stratum, Leased Lines leased lines
are configured in two very simple steps. First, establish a hop-by-
hop tunnel (T-labels), and second second, configure the leased lines
(L-labels). The T-labels need to be configured on both the PE and P
routers,
routers while L-Labels L-labels only need to be configured on the PE routers.

Note that L labels L-labels may be used for normal IP service [RFC3031], BGP/
MPLS
BGP/MPLS VPNs [RFC4364] [RFC4364], or 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. NMS/Controller.

4.1. State in the Forwarding Plane

The only configured information that is actually kept on the LSRs is

o the information needed for the label swapping procedures, i.e. 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. tunnels; and

o the bandwidth available for the Hard Pipe stratum and the Normal
IP/MPLS stratum stratum.

4.2. State in the NMS NMS/Controller

The following state needs to be kept in the NMS NMS/Controller:

o the topology and bandwidth resources available in the Hard Pipe
network,
network; see Figure 2.

o the total and available bandwidth per link in the Hard Pipe
network
network; see Figure 4.

o the tunnel label mappings (T-labels) T-label mappings; see Figure 5.

o the Leased Line label mappings (L-labels) L-label mappings; see Figure 6.

o the reserved bandwidth, as well as other constraints and the path
per Leased Line (L-labels) L-label.

4.3. Annotations for Configuring Leased Lines

The annotations given below are neither a programming guideline nor
an indication how this architecture could be implemented. It is
rather an indication of how much data needs to be saved for each
stratum and leased line, as well as where this data could be stored.

Considering the Hard Pipe stratum as it has been outline outlined in
Figure 2, there is actually some additional information related to
the Hard Pipe Stratum stratum that not is shown in the figure.

Looking explicitly on the link between LSR J and K we find:

+---+ +---+ +---+ +---+
---| H |-----------| J |-----------| K |----------| L |---
+---+ +---+ +---+ +---+
[4,0]G

Figure 4

The annotation [4,0]G means that 4G is allocated to the stratum on
the link between J and K, and of these these, 0G has been allocated to a
service.

If we were to allocate two tunnels labels from the labels that has have
been configured to work within the Hard Pipe stratum 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) L-labels are assigned, this will consume bandwidth. So 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: as follows:

The Hard Pipe Stratum stratum link between nodes J and K has 4 G 4G bandwidth
allocated; of the total bandwidth 1.5 G bandwidth, 1.5G is allocated for Leased
Lines. leased
lines.

Tunnel label T1, T1 carries two Leased Lines, leased lines, each of 0.5G 0.5G, and tunnel
label T2 carries a third Leased Line leased line of 0.5G.

Note that it is not necessary to keep this information in the nodes, nodes;
it is held within the NMS, NMS/Controller. Also, it is also strictly not necessary to
keep the bandwidth per leased line, but some operations are
simplified
(e.g. (e.g., removing a leased line) if this is done.

5. Setting Up Leased Lines

Consider that the case where an operator want wants to set up a Leased Line leased line of
0.4G from F to G in the Hard Pipe stratum in Figure 2.

Since there are no other constraints other than bandwidth and ingress and
egress PEs, the shortest path will be chosen. A tunnel will be
configure
configured from F to G over the following nodes. nodes F, H, J, K, L L, and G, and a
Leased Line label (a) will be configured on F and G, and the
available resources will be recalculated.

A second leased line of 0.3G between the same PEs is easily configure
configured by adding a new Leased Line label (b) at the ingress and
egress PEs.

After these operations operations, a view of the Hard Pipe stratum resources
(available 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 7: The Hard Pipe Stratum after Operations

If the operator now wishes to establish a new leased line with the
criteria being that it should originate from F and terminate at G,
have 0.4G bandwidth bandwidth, and pass through node E, then 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; following:

o the The existing tunnel cannot be used, used since it does not pass through
E; a new tunnel need to be established.

o the The hop from F to H cannot be used since the available bandwidth
is insufficient.

o since Since no existing tunnels 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) 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 Protection

This leased line service uses the MPLS Transport Profile (MPLS-TP)
line protection as it is defined in RFC 6378 [RFC6378], [RFC6378] and is updated
as specified in RFC 7271 [RFC7271] and RFC 7324 [RFC7324]

The Connection Verification (CV) CV and Continuity Check (CC) CC are run over the tunnels between the Maintenance Entity
Group End Points (MEP) at each end, i.e. i.e., the entire tunnel is
protected end to end.

In general general, all of the MPLS-TP Operation, Administration Operations, Administration, and
Maintenance (OAM), (OAM) as defined in RFC 6371 [RFC6371] is v applicable.

7. Security Considerations

The security considerations as defined in RFC 5920 "Security Framework for
MPLS and GMPLS Networks" [RFC5920] (RFC 5920 [RFC5920]) and RFC RFC 6941 "MPLS Transport
Profile (MPLS-TP) Security Framework" [RFC6941] (RFC 6941 [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.

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,
DOI 10.17487/RFC3031, January 2001. 2001,
<http://www.rfc-editor.org/info/rfc3031>.

[RFC3985] Bryant, S. S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-
Edge
Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005. 2005,
<http://www.rfc-editor.org/info/rfc3985>.

[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006.
2006, <http://www.rfc-editor.org/info/rfc4364>.

[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007. 2007, <http://www.rfc-editor.org/info/rfc5036>.

[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010. 2010,
<http://www.rfc-editor.org/info/rfc5920>.

[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., and L. Berger, "A Framework for MPLS in Transport
Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010. 2010,
<http://www.rfc-editor.org/info/rfc5921>.

[RFC6371] Busi, I. I., Ed. and D. Allan, Ed., "Operations,
Administration, and Maintenance Framework for MPLS-Based
Transport Networks", RFC 6371, DOI 10.17487/RFC6371,
September 2011. 2011, <http://www.rfc-editor.org/info/rfc6371>.

[RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher,
N., and A. Fulignoli, Ed., "MPLS Transport Profile
(MPLS-TP) Linear Protection", RFC 6378,
DOI 10.17487/RFC6378, October 2011. 2011,
<http://www.rfc-editor.org/info/rfc6378>.

[RFC6941] Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed.,
and R. Graveman, Ed., "MPLS Transport Profile (MPLS-TP)
Security Framework", RFC 6941, DOI 10.17487/RFC6941, April 2013.
2013, <http://www.rfc-editor.org/info/rfc6941>.

[RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H.,
D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS
Transport Profile (MPLS-
TP) (MPLS-TP) Linear Protection to Match the
Operational Expectations of Synchronous Digital Hierarchy,
Optical Transport Network, and Ethernet Transport Network
Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014. 2014,
<http://www.rfc-editor.org/info/rfc7271>.

[RFC7324] Osborne, E., "Updates to MPLS Transport Profile Linear
Protection", RFC 7324, DOI 10.17487/RFC7324, July 2014. 2014,
<http://www.rfc-editor.org/info/rfc7324>.

Acknowledgements

The authors want to thank Andy Malis for detailed technical and
language review and for valuable comments.

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

Mach
Mach(Guoyi) Chen
Huawei Technologies Co., Ltd
Q13
Q14 Huawei Campus
No. 156 Beiqing Road
Hai-dian District
Beijing 100095
China

Email: mach.chen@huawei.com