Internet DRAFT - draft-li-teas-serv-driven-co-lsp-fmwk
draft-li-teas-serv-driven-co-lsp-fmwk
Network Working Group Z. Li
Internet-Draft S. Zhuang
Intended status: Informational J. Dong
Expires: September 18, 2016 Huawei Technologies
March 17, 2016
A Framework for Service-Driven Co-Routed MPLS Traffic Engineering LSPs
draft-li-teas-serv-driven-co-lsp-fmwk-00
Abstract
MPLS Traffic Engineering (TE) has been widely deployed to satifisfy
all kinds of requirements of traffic engineering for transport of
services. Complexity of configuration has much negative effect on
the MPLS TE deployment in the large-scale network. The document
identifies the configuration issues for MPLS TE deployment and
proposes a new mechanism, the service-driven mechanism, by which the
setup of co-routed MPLS Traffic-Engineered Label-Switched Paths(TE
LSPs) is triggered by the bidirectional service. Then the document
proposes the framework for setting up service-driven co-routed MPLS
TE LSP for L2VPN and L3VPN.
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].
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 September 18, 2016.
Li, et al. Expires September 18, 2016 [Page 1]
Internet-Draft A Framework for SD Co-Routed LSPs March 2016
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Massive Configuration Issue of TE LSPs . . . . . . . . . 4
3.2. Return Path Issue of BFD for MPLS LSPs . . . . . . . . . 5
3.3. Upgrading Issue of Co-routed Bidirectional LSP . . . . . 6
4. Framework and Procedures . . . . . . . . . . . . . . . . . . 6
4.1. Service-Driven Co-Routed Unidirectional LSPs for L2VPN . 7
4.1.1. Framework . . . . . . . . . . . . . . . . . . . . . . 7
4.1.2. Procedures . . . . . . . . . . . . . . . . . . . . . 7
4.2. Service-Driven Co-Routed Unidirectional LSPs for L3VPN . 9
4.2.1. Framework . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Procedures . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
Multiprotocol Label Switching (MPLS) traffic engineering (TE) can
satisfy specific traffic engineering attributes [RFC2702]. MPLS
TEcan effectively schedule, allocate, and use existing network
resources to provide bandwidth guarantee and traffic protection for
transport of services. MPLS TE is being widely deployed to support
packet-based services. Since rich set of traffic engineering
attributes have to be specified for each LSP and a great deal of
configuration has to be done as the number of MPLS TE LSPs increases,
a scalable and simple solution is required to implement TE in a
Li, et al. Expires September 18, 2016 [Page 2]
Internet-Draft A Framework for SD Co-Routed LSPs March 2016
large-scale network and reduce complexity in operation and management
of TE LSPs.
LDP LSP setup is topology-driven which is a scalable way to adapt to
the large-scale network. The similar way cannot be used for MPLS TE
since the traffic engineering attributes should be specified for MPLS
TE LSP which is not necessary for LDP LSP. On the other hand, MPLS
TE LSP is always setup to bear specific services such as L3VPN and
L2VPN. That is, MPLS TE LSPs will not be setup aimlessly which is
always inevitable for MPLS topology-driven LSP if there is no complex
policy applied on it. So it is a natural way to combine setup of
MPLS TE LSP with the service it bears. Setup of MPLS TE LSP can be
triggered automatically by the service instead of explicitly
configuring each MPLS TE LSP and corresponding traffic engineering
attributes. We call this method as service-driven comparing to
topology-driven. Moreover the service-driven method has much
advantage in the process of setting up co-routed TE LSPs. The
service transported by MPLS TE LSPs is always bi-directional. The
characteristic can be utilized to setup the forward MPLS TE LSP and
the co-routed reverse MPLS TE LSP.
This document describes the framework of automatic setup of co-routed
MPLS TE LSPs on demand of L2VPN and L3VPN services. The mechanism
can facilitate the provisioning of services and the TE LSPs greatly.
2. Terminology
This document uses terminology from the MPLS architecture document
[RFC3031], the RSVP-TE protocol specification [RFC3209] which
inherits from the RSVP specification [RFC2205] and the Provider
Provisioned VPN terminology document [RFC4026].
The document introduces two new concepts by which PEs of VPN can be
generally categorized into two types:
o Active PE: the PE triggers the setup of the LSPs and informs the
remote PE;
o Passive PE: the PE complies with the Active PE's suggestion to set
up LSPs.
In this document, the terminology of "tunnel" is identical to the "TE
Tunnel" defined in Section 2.1 of [RFC3209], which is uniquely
identified by a SESSION object that includes Tunnel end point
address, Tunnel ID and Extended Tunnel ID. The terminology "LSP" is
identical to the "LSP tunnel" defined in Section 2.1 of [RFC3209],
which is uniquely identified by the SESSION object together with
Li, et al. Expires September 18, 2016 [Page 3]
Internet-Draft A Framework for SD Co-Routed LSPs March 2016
SENDER_TEMPLATE (or FILTER_SPEC) object that consists of LSP ID and
Tunnel end point address.
3. Problem Statement
3.1. Massive Configuration Issue of TE LSPs
Deployment MPLS TE in a large-scale networks may require
configuration of a potentially large number of TE LSPs.
----------------
/ \
/ \
/ \
+------+ +----+ Access +----+
|eNodeB|---|CSG1| Ring 1 |ASG1|-------------
+------+ +----+ +----+ \
\ / \
\ / +----+ +---+
\ +----+ |RSG1|----|RNC|
-------------| | Aggregate +----+ +---+
|ASG2| Ring |
-------------| | +----+ +---+
/ +----+ |RSG2|----|RNC|
/ \ +----+ +---+
/ \ /
+------+ +----+ Access +----+ /
|eNodeB|---|CSG2| Ring 2 |ASG3|------------
+------+ +----+ +----+
\ /
\ /
\ /
-----------------
Figure 1 Mobile Backhaul Network
Figure 1 shows an example of the mobile backhaul network. Mobile
multimedia devices such as smartphones are ubiquitous now which runs
a wide variety of bandwidth-intensive applications and causes
unprecedented growth in mobile data traffic. In order to cope with
the growth, more cell sites are introduced into the network: more LTE
eNodeBs and associated Cell Site Gateways(CSGs) are added in the
networks. This causes the network scale expands fast and more and
more MPLS TE tunnels need setup between Cell Site Gateways(CSGs)
which connect the eNodeBs and RNC Site Gateways(RSGs) which connect
the RNCs.
Typically, we assume that:
Li, et al. Expires September 18, 2016 [Page 4]
Internet-Draft A Framework for SD Co-Routed LSPs March 2016
1. There are 1,000 CSGs need to connect to one RSG.
2. There are three types of bi-directional services transported
between one CSG and one RSG. Each type of service needs one VPN and
one TE tunnel.
3. There are 10 command lines to configure necessary attributes for
each MPLS TE LSP.
So in one RSG it may take 30,000 command lines to set up MPLS TE
LSPs. And all CSGs need another 30,000 commands to set up MPLS TE
LSPs to one RSG. The huge configuration work is not only time
consuming but also prone to mis-configuration. Hence a mechanism to
set up MPLS TE LSPs automatically is desirable which can
significantly reduce complexity of MPLS TE configuration.
3.2. Return Path Issue of BFD for MPLS LSPs
| |
|<--------Dynamic BFD--------->|
| |
| (1) TE Primary LSP |
|----------------------------->|
| (2) TE Backup LSP |
|----------------------------->|
+----+ +--+ +--+ +----+
| PE1|===|P1|======|P2|===| PE2|
+----+ +--+ +--+ +----+
| (3) IP Path (Return Path) |
|<-----------------------------|
Figure 2: BFD for TE LSPs Scenario
As shown in Figure 2, BFD for MPLS LSPs ([RFC5884]) can be used to
detect the possible failure fast which can trigger traffic switch
between the primary LSP and the backup LSP. When BFD for MPLS LSPs
is deployed, the return path may take an IP path which is different
from the forward path. The failure that happens in the return path
may cause wrong traffic switch.
In order to solve the return path issue of BFD for MPLS LSPs, it has
to be guaranteed that the forward path and the return path must be
co-routed. For MPLS TE LSPs the explicit path has to be configured
for the forward LSP and the return LSP. In addition, another
configuration has to be introduced to bind the return BFD traffic
corresponding to the forward BFD traffic to the right return MPLS TE
LSP at the ingress node or the egress node. This will deteriorate
the configuration work described above. Morerover, if the forward
Li, et al. Expires September 18, 2016 [Page 5]
Internet-Draft A Framework for SD Co-Routed LSPs March 2016
path changes, the return path may not change accordingly owing to
statically binding the forward path and the return path. It will
cause that the return path issue of BFD for MPLS LSPs happens again.
3.3. Upgrading Issue of Co-routed Bidirectional LSP
The co-routed bidirectional LSP is defined in [RFC3945]. If co-
routed bidirectional LSP is used, the return path is not necessary to
configure and the return path issue of BFD for LSPs can be solved
naturally. This can simplify operation and management for Service
Providers. But it is still necessary to configure each LSP. On the
other hand, the unidirectional MPLS TE LSPs have been deployed widely
and it is difficult for the service providers to upgrade all possible
routers to support co-routed bidirectional LSPs.
4. Framework and Procedures
MPLS TE LSPs depend heavily on manual configuration. So some auto
provision methods (e.g. auto mesh [RFC4972]) have been proposed.
This document proposes a new mechanism, the service-driven mechanism,
to reduce the operation cost of MPLS TE networks.
It is well known that LDP LSP setup is topology-driven which is a
scalable way to adapt to the large-scale network. The similar way
cannot be used for MPLS TE since the traffic engineering attributes
has to be specified for the MPLS TE tunnel. On the other hand, MPLS
TE LSP is always setup to bear specific services such as L3VPN and
L2VPN. That is, MPLS TE LSPs will not be setup aimlessly which is
always inevitable for MPLS topology-driven LSP if there is no complex
policy applied on it. So it is a natural way to trigger MPLS TE LSP
setup by the service instead of explicitly configuring each LSP. We
call this method as service-driven comparing to topology-driven. In
fact BGP-based MVPN ([RFC6513] and [RFC6514]) provides an example of
service-driven method which can trigger P2MP TE LSP setup after MVPN
membership auto-discovery.
The service-driven method also has much advantage in the process of
setting up co-routed MPLS TE LSPs. The service transported by MPLS
TE LSPs is always bi-directional. The characteristic can be utilized
to setup the forward MPLS TE LSP and the co-routed reverse MPLS TE
LSP. This section describes the framework and procedures of setting
up the co-routed MPLS TE LSPs. The method needs the signaling of the
service advertises the tunnel information between PEs. PEs of VPN
can be generally categorized into two types: Active PE and Passive
PE. The Passive PE can set up the reverse LSP to the Active PE based
on RRO information of the forward LSP which is from the Active PE to
the Passive PE. Thus the path of the reverse LSP can be co-routed
with the path of the forward LSP.
Li, et al. Expires September 18, 2016 [Page 6]
Internet-Draft A Framework for SD Co-Routed LSPs March 2016
Service-driven co-routed MPLS TE LSP has following advantages:
1) Set up LSPs on demand and save massive configuration effort.
2) Reuse existing mechanism as much as possible. It only needs
upgrading of PEs instead of whole network upgrading.
4.1. Service-Driven Co-Routed Unidirectional LSPs for L2VPN
4.1.1. Framework
Active PE Passive PE
PE1 PE2
| |
|<----Signaling Tunnel Info--->|
| |
| TE LSP1 for PW |
|----------------------------->|
| PW |
|<---------------------------->|
| TE LSP2 for PW |
|<-----------------------------|
+----+ +--+ +--+ +----+
| PE1|===|P1|======|P2|===| PE2|
+----+ +--+ +--+ +----+
| |
Figure 3: Framework of L2VPN Driven TE LSP
L2VPN, as defined in [RFC4664], is a proven and widely deployed
technology. Figure 3 shows a framework for co-routed MPLS TE LSPs
driven by L2VPN service. L2VPN is provisioned on PEs and the PW is
setup between a pair of PEs. The pair of PEs for a specific PW will
be identified as the Active PE and the Passive PE respectively. The
Active PE triggers the set up of the forward LSP (TE LSP1) to the
Passive PE and advertises the tunnel information to the Passive PE.
According to the information advertised by the Active PE, the Passive
PE will set up the reverse LSP (TE LSP2) which is co-routed with the
forward LSP.
4.1.2. Procedures
Li, et al. Expires September 18, 2016 [Page 7]
Internet-Draft A Framework for SD Co-Routed LSPs March 2016
PE1 PE2
| (1) Active/Passive role election |
| (Here PE1 is elected as Active PE) |
|<----------------------------------------->|
| |
Active PE Passive PE
(2)PE1's PW drives RSVP-TE (2) PE2 waits for Tunnel info
to create TE LSP(e.g. LSP1) advertised from PE1
|(3) PE1 advertises LSP1 Tunnel info |
| to PE2 through PW signaling |
|------------------------------------------>|
| |
(4) PE2 gets forward Tunnel info from
PE1,
Create TE LSP (e.g. LSP2) according
to RRO information of LSP1,
Binds LSP1 and LSP2 for PW;
|(5) PE2 advertises LSP2 Tunnel info to PE1 |
|<------------------------------------------|
| |
(6)PE1 binds LSP1 and LSP2 for the PW;
| Co-routed TE LSP Established |
|<----------------------------------------->|
| |
Figure 4: Signaling Procedures of L2VPN Driven Co-Routed TE LSPs
Figure 4 shows the detailed procedures for L2VPN driven co-routed
MPLS TE LSPs. Through the above procedures, the co-routed MPLS TE
LSPs driven by the PW are established between a pair of PEs.
4.1.2.1. Active/Passive Role Election
The Active and Passive roles of PEs can be determined through manual
configuration or dynamic election between a pair of PEs for a
specific PW. When the dynamic election method is used, LSR IDs of a
pair of PEs between which PW is setup are compared as unsigned
integers and the PE with the larger value of LSR ID assumes the
Active role.
Li, et al. Expires September 18, 2016 [Page 8]
Internet-Draft A Framework for SD Co-Routed LSPs March 2016
4.1.2.2. Signaling Tunnel Information
In the service-driven co-routed MPLS TE framework for L2VPN, the
tunnel information needs to be advertised between the Active PE and
the Passive PE. The Passive PE uses the tunnel information to get
corresponding MPLS TE tunnel and RRO information which is used to
setup the reverse co-routed MPLS TE LSP.
[I-D.ietf-pwe3-mpls-tp-pw-over-bidir-lsp] defines how the
bidirectional Tunnel/LSP identifier information is advertised between
a pair of PEs for PW. The similar mechanism can be reused for
advertising MPLS TE tunnel/LSP identifier information for service-
driven MPLS TE LSPs for L2VPN.
4.1.2.3. Procedures
Step 1: Active/Passive role election through signaling between a pair
of PEs of a PW. In this case, assume PE1 as Active PE and PE2 as
Passive PE after election;
Step 2: As the active role, the PW service on PE1 drives RSVP-TE to
create the forward TE LSP(e.g. LSP1). As the passive role, PE2
waits for tunnel information advertised by PE1;
Step 3: PE1 advertises tunnel information of LSP1 to PE2;
Step 4: PE2 gets tunnel information from PE1 and creates the reverse
TE LSP (e.g. LSP2) according to RRO information derived from LSP1.
PE2 binds LSP1 and LSP2 for the PW;
Step 5: PE2 advertises tunnel information of LSP2 to PE1;
Step 6: PE1 binds LSP1 and LSP2 for the PW.
Through the above procedures, the co-routed MPLS TE LSPs driven by
the PW are established.
4.2. Service-Driven Co-Routed Unidirectional LSPs for L3VPN
4.2.1. Framework
Li, et al. Expires September 18, 2016 [Page 9]
Internet-Draft A Framework for SD Co-Routed LSPs March 2016
Active PE Passive PE
PE1 PE2
| |
|<----Signaling Tunnel Info--->|
| |
| TE LSP1 for L3VPN |
|----------------------------->|
| L3VPN |
|<---------------------------->|
| TE LSP2 for L3VPN |
|<-----------------------------|
+----+ +--+ +--+ +----+
| PE1|===|P1|======|P2|===| PE2|
+----+ +--+ +--+ +----+
| |
Figure 5: Framework of L3VPN Driven TE LSP
L3VPN services are provided by [RFC4110]. Figure 5 shows a framework
for co-routed MPLS TE LSPs driven by L3VPN service. L3VPN is
provisioned on PEs and VPN membership is discovered.
The pair of PEs for a specific L3VPN will be identified as the Active
PE and the Passive PE respectively. The Active PE triggers the set
up of the forward LSP(TE LSP1) to the Passive PE and advertises the
tunnel information to the Passive PE. According to the information
advertised by the Active PE, the Passive PE will set up the reverse
LSP (TE LSP2) which is co-routed with the forward LSP.
4.2.2. Procedures
Li, et al. Expires September 18, 2016 [Page 10]
Internet-Draft A Framework for SD Co-Routed LSPs March 2016
PE1 PE2
| (1) VPN Membership Auto-Discorvery |
|<----------------------------------------->|
| |
| (2) Active/Passive role election |
| (Here PE1 is elected as Active PE) |
|<----------------------------------------->|
| |
Active PE Passive PE
(3)PE1's L3VPN drives RSVP-TE (3) PE2 waits for Tunnel info
to create TE LSP(e.g. LSP1) advertised from PE1
|(4) PE1 advertises LSP1 Tunnel info |
| to PE2 through L3VPN signaling |
|------------------------------------------>|
| |
(5) PE2 gets forward Tunnel info
from PE1,
Create TE LSP (e.g. LSP2) according
to RRO information of LSP1,
Binds LSP1 and LSP2 for L3VPN;
|(6) PE2 advertises LSP2 Tunnel info to PE1 |
|<------------------------------------------|
| |
(7)PE1 binds LSP1 and LSP2 for L3VPN;
| Co-routed TE LSP Established |
|<----------------------------------------->|
| |
Figure 6: Signaling Procedures of L3VPN Driven Co-Routed TE LSPs
Figure 6 shows the detailed procedures for L3VPN to drive the set up
of co-routed MPLS TE LSPs. Through the above procedure, the co-
routed MPLS TE LSPs driven by the L3VPN are established between a
pair of PEs.
4.2.2.1. VPN Membership Auto-Discovery
In order to set up co-routed MPLS TE LSPs in L3VPN, a point-to-point
connection between any two VRFs of a particular VPN needs to be
established. VPN membership auto-discovery should be done firstly
Li, et al. Expires September 18, 2016 [Page 11]
Internet-Draft A Framework for SD Co-Routed LSPs March 2016
and the mechanism defined in [I-D.dong-l3vpn-pm-framework] can be
used.
4.2.2.2. Active/Passive Role Election
After obtaining the VPN membership information via VPN membership
auto-discovery process, we can identify a pair of VPN members.
The Active and Passive role of PEs can be determined through manual
configuration or dynamic election between a pair of PEs for a
specific L3PVN. When the dynamic election method is used, LSR IDs of
a pair of PEs between which existing the pair of VPN members are
compared as unsigned integers and the PE with the larger value of LSR
ID assumes the Active role.
4.2.2.3. Signaling Tunnel Information
In the service-driven co-routed MPLS TE framework for L3VPN, the
tunnel information needs to be advertised between the Active PE and
the Passive PE. The Passive PE uses the tunnel information to get
corresponding MPLS TE tunnel and RRO information which is used to
setup the reverse co-routed MPLS TE LSP. MP-BGP signaling needs
extensions to advertise the MPLS TE tunnel/LSP identifier information
for service-driven MPLS TE LSPs for L3VPN.
4.2.2.4. Procedures
Step 1: VPN Membership Auto-Discovery process is done through
signaling to identify a pair of VPN members;
Step 2: Active/Passive role election through signaling between a pair
of PEs of a L3VPN. In this case, assume PE1 as Active PE and PE2 as
Passive PE after election;
Step 3: As the active role, L3VPN service on PE1 drives RSVP-TE to
create forward TE LSP(e.g. LSP1), as the passive role, PE2 waits for
tunnel information advertised by PE1;
Step 4: PE1 advertises tunnel information of LSP1 to PE2;
Step 5: PE2 gets tunnel information from PE1 and creates TE LSP (e.g.
LSP2) according to RRO information derived from LSP1. PE2 binds LSP1
and LSP2 for the L3VPN;
Step 6: PE2 advertises tunnel information of LSP2 to PE1;
Step 7: PE1 binds LSP1 and LSP2 for the L3VPN.
Li, et al. Expires September 18, 2016 [Page 12]
Internet-Draft A Framework for SD Co-Routed LSPs March 2016
Through the above procedures, the co-routed MPLS TE LSPs driven by
the L3VPN are established.
5. IANA Considerations
This document makes no request of IANA.
6. Security Considerations
This document does not change the security properties of L2VPN &
L3VPN.
7. References
7.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>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
7.2. Informative References
[I-D.dong-l3vpn-pm-framework]
Dong, J., Li, Z., and B. Parise, "A Framework for L3VPN
Performance Monitoring", draft-dong-l3vpn-pm-framework-03
(work in progress), October 2014.
[I-D.ietf-pwe3-mpls-tp-pw-over-bidir-lsp]
Chen, M., Cao, W., Takacs, A., and P. Pan, "LDP extensions
for Pseudowire Binding to LSP Tunnels", draft-ietf-pwe3-
mpls-tp-pw-over-bidir-lsp-03 (work in progress), September
2014.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <http://www.rfc-editor.org/info/rfc2205>.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, DOI 10.17487/RFC2702, September 1999,
<http://www.rfc-editor.org/info/rfc2702>.
Li, et al. Expires September 18, 2016 [Page 13]
Internet-Draft A Framework for SD Co-Routed LSPs March 2016
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945,
DOI 10.17487/RFC3945, October 2004,
<http://www.rfc-editor.org/info/rfc3945>.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026,
DOI 10.17487/RFC4026, March 2005,
<http://www.rfc-editor.org/info/rfc4026>.
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3
Provider-Provisioned Virtual Private Networks (PPVPNs)",
RFC 4110, DOI 10.17487/RFC4110, July 2005,
<http://www.rfc-editor.org/info/rfc4110>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.
[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer
2 Virtual Private Networks (L2VPNs)", RFC 4664,
DOI 10.17487/RFC4664, September 2006,
<http://www.rfc-editor.org/info/rfc4664>.
[RFC4972] Vasseur, JP., Ed., Leroux, JL., Ed., Yasukawa, S.,
Previdi, S., Psenak, P., and P. Mabbey, "Routing
Extensions for Discovery of Multiprotocol (MPLS) Label
Switch Router (LSR) Traffic Engineering (TE) Mesh
Membership", RFC 4972, DOI 10.17487/RFC4972, July 2007,
<http://www.rfc-editor.org/info/rfc4972>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<http://www.rfc-editor.org/info/rfc5880>.
Li, et al. Expires September 18, 2016 [Page 14]
Internet-Draft A Framework for SD Co-Routed LSPs March 2016
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
June 2010, <http://www.rfc-editor.org/info/rfc5884>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<http://www.rfc-editor.org/info/rfc6514>.
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Shunwan Zhuang
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: zhuangshunwan@huawei.com
Jie Dong
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: jie.dong@huawei.com
Li, et al. Expires September 18, 2016 [Page 15]
