One document matched: draft-li-mpls-serv-driven-co-lsp-fmwk-02.txt
Differences from draft-li-mpls-serv-driven-co-lsp-fmwk-01.txt
Network Working Group Z. Li
Internet-Draft Z. Zhuang
Intended status: Informational J. Dong
Expires: July 20, 2014 Huawei Technologies
January 16, 2014
A Framework for Service-Driven Co-Routed MPLS Traffic Engineering LSPs
draft-li-mpls-serv-driven-co-lsp-fmwk-02
Abstract
MPLS TE has been widely deployed to provide traffic engineering and
traffic protection. The complexity in configuration has much 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 TE LSPs is triggered by the bidirectional
service. Then the document provides the framework for setting up
service-driven co-routed MPLS Traffic-Engineered Label-Switched
Paths(TE LSPs) 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 July 20, 2014.
Li, et al. Expires July 20, 2014 [Page 1]
Internet-Draft A Framework for SD Co-Routed LSPs January 2014
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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 8
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)
effectively schedules, allocates, and uses existing network resources
to provide bandwidth guarantee and traffic protection. MPLS TE
establishes label switched paths (LSPs) satisfying specific traffic
engineering attributes [RFC2702]. 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
Li, et al. Expires July 20, 2014 [Page 2]
Internet-Draft A Framework for SD Co-Routed LSPs January 2014
on a large-scale network and reduce the 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 the
MPLS TE tunnel 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 policy exerted on it. So it seems a natural way to combine the
MPLS TE LSP setup with the service it beared. The MPLS TE LSP setup
can be triggered automatically by the service instead of explicitly
configuring each tunnel and its traffic engineering attributes. We
call this method as service-driven comparing to topology-driven. In
addition the service-driven method has much advantage in the process
of setting up co-routed TE LSPs. The service beared 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 automatically setting up co-
routed TE LSPs, in which the co-routed MPLS TE LSPs are automatically
setting up on demand of the services, e.g. VPNs. This mechanism
facilitates the provisioning of services and the TE LSPs.
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 VPN PEs can be
generally categorized into two types:
1. Active PE: the PE which primarily triggers the set up of the LSPs
and informs the remote PE;
2. Passive PE: the PE which secondarily 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 July 20, 2014 [Page 3]
Internet-Draft A Framework for SD Co-Routed LSPs January 2014
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
It is a common deployment scenario to set up MPLS TE LSPs among a set
of Label Switching Routers (LSR). Such deployment may require the
configuration of a potentially large number of TE tunnels.
----------------
/ \
/ \
/ \
+----+ Access +----+
|CSG1| Ring 1 |ASG1|-------------
+----+ +----+ \
\ / \
\ / +----+
\ +----+ |RSG1|
-------------| | Aggregate +----+
|ASG2| Ring |
-------------| | +----+
/ +----+ |RSG2|
/ \ +----+
/ \ /
+----+ Access +----+ /
|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)
connects the eNodeBs and RNC site gateways(RSGs) connects the RNCs.
Typically, we assume that:
Li, et al. Expires July 20, 2014 [Page 4]
Internet-Draft A Framework for SD Co-Routed LSPs January 2014
1. There are 1,000 CSGs need to connect to one RSG.
2. There are three types of bi-directional services beared 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 TE tunnel and at least one command line to bind one VPN to one
TE tunnel.
Then there are at least 66,000 command lines to configure MPLS TE
tunnels and VPN and TE tunnel bindings. It is truly a huge
configuration work. The operation is not only time consuming but
also prone to mis-configuration for Service Providers. Hence, a
mechanism to set up MPLS TE tunnels automatically is desirable which
can significantly reduce the 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]) is 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 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 explicit path has to be configured for
the forward LSP and the return LSP. In addition, there is at least
one configuration to bind the return BFD traffic corresponding to the
forward BFD traffic to the right return MPLS TE tunnel at the ingress
node or the egress node. This will deteriorate the configuration
Li, et al. Expires July 20, 2014 [Page 5]
Internet-Draft A Framework for SD Co-Routed LSPs January 2014
work described above. In addition, if the forward 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 to some extent. But as to the example described in sec 3.2
it is still necessary to configure each tunnel and configure explicit
binding of each tunnel and VPN pair. The configuration work is still
a little complex. In addition, the unidirectional 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
configuration method (e.g. auto mesh [RFC4972]) has 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 policy
exerted on it. So it is a natural way to trigger MPLS TE LSP setup
by the service instead of explicitly configuring each tunnel. We
call this method as service-driven comparing to topology-driven.
BGP-based MVPN ([RFC6513] and [RFC6514]) provides an example of
service-driven tunnel which can trigger P2MP TE tunnel setup after
MVPN membership auto-discovery.
The service-driven method also has much advantage in the process of
setting up co-routed TE LSPs. The service beared 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. In this method, MPLS TE LSPs can be set up on
demand which can reduce the manual configuration. The signaling of
the service will advertise the tunnel information between the active
PE and the passive PE. The PE on the passive side can set up the
Li, et al. Expires July 20, 2014 [Page 6]
Internet-Draft A Framework for SD Co-Routed LSPs January 2014
reverse LSP based on RRO information of the LSP from the active PE to
the passive PE. Thus the path of the reverse LSP can be co-routed
with the path of the LSP from the active PE to the passive PE.
Service-driven co-routed MPLS TE LSP has following advantages:
1) Setup LSP on demand and save massive configuration effort.
2) Reuse current mechanism 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 of 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. A 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 primary LSP 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
MPLS TE LSP which is co-routed with the LSP from the active PE to the
passive PE LSP.
Li, et al. Expires July 20, 2014 [Page 7]
Internet-Draft A Framework for SD Co-Routed LSPs January 2014
4.1.2. Procedures
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 procedure, the co-routed MPLS TE
LSPs driven by the PW are established.
4.1.2.1. Active/Passive Role Election
The active and passive role of PEs can be determined through manual
configuration or dynamic election between two PEs. If 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 July 20, 2014 [Page 8]
Internet-Draft A Framework for SD Co-Routed LSPs January 2014
4.1.2.2. Signaling Tunnel Information
In the service-driven co-routed MPLS TE framework for L2VPN, the
tunnel information need 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. Operation
Step 1: Active/passive role election through signaling between 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 TE LSP(e.g. LSP1), as the passive role, PE2 waits for tunnel
information advertised by PE1;
Step 3: PE1 advertises tunnel information related with LSP1 to PE2;
Step 4: 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 PW;
Step 5: PE2 advertises tunnel information related with LSP2 to PE1;
Step 6: PE1 binds LSP1 and LSP2 for PW.
Through the above procedure, 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 July 20, 2014 [Page 9]
Internet-Draft A Framework for SD Co-Routed LSPs January 2014
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 Tunnel
L3VPN services are provided by [RFC4110]. Figure 5 shows a framework
for co-routed MPLS TE LSPs driven by L3VPN. L3VPN is provisioned on
PEs and VPN membership is discovered.
A pair of PEs for a specific L3VPN are identified as the active PE
and the passive PE respectively. The active PE initiates the set up
of the primary LSP 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
MPLS TE LSP which is co-routed with the forward LSP from the active
PE to the passive PE.
4.2.2. Procedures
Li, et al. Expires July 20, 2014 [Page 10]
Internet-Draft A Framework for SD Co-Routed LSPs January 2014
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.
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
and the mechanism defined in [I-D.dong-l3vpn-pm-framework] can be
used.
Li, et al. Expires July 20, 2014 [Page 11]
Internet-Draft A Framework for SD Co-Routed LSPs January 2014
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 two PEs. If the dynamic
election method is used, LSR IDs of a pair of PEs corresponding to
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 need 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 need
extensions to advertise the MPLS TE tunnel/LSP identifier information
for service-driven MPLS TE LSPs for L3VPN.
4.2.2.4. Operation
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 TE LSP(e.g. LSP1), as the passive role, PE2 waits for tunnel
information advertised by PE1;
Step 4: PE1 advertises tunnel information related with 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 L3VPN;
Step 6: PE2 advertises tunnel information related with LSP2 to PE1;
Step 7: PE1 binds LSP1 and LSP2 for L3VPN.
Through the above procedure, the co-routed MPLS TE LSPs driven by the
L3VPN are established.
Li, et al. Expires July 20, 2014 [Page 12]
Internet-Draft A Framework for SD Co-Routed LSPs January 2014
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, March 1997.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
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-01
(work in progress), April 2013.
[I-D.ietf-mpls-return-path-specified-lsp-ping]
Chen, M., Cao, W., Ning, S., JOUNAY, F., and S. DeLord,
"Return Path Specified LSP Ping", draft-ietf-mpls-return-
path-specified-lsp-ping-15 (work in progress), October
2013.
Li, et al. Expires July 20, 2014 [Page 13]
Internet-Draft A Framework for SD Co-Routed LSPs January 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-02 (work in progress), November
2013.
[I-D.zheng-l3vpn-pm-analysis]
Zheng, L., Li, Z., Aldrin, S., and B. Parise, "Performance
Monitoring Analysis for L3VPN", draft-zheng-l3vpn-pm-
analysis-02 (work in progress), October 2013.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3
Provider-Provisioned Virtual Private Networks (PPVPNs)",
RFC 4110, July 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", RFC 4664, September 2006.
Li, et al. Expires July 20, 2014 [Page 14]
Internet-Draft A Framework for SD Co-Routed LSPs January 2014
[RFC4972] Vasseur, JP., Leroux, JL., 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,
July 2007.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
VPNs", RFC 6513, February 2012.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, February 2012.
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
Li, et al. Expires July 20, 2014 [Page 15]
Internet-Draft A Framework for SD Co-Routed LSPs January 2014
Jie Dong
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: jie.dong@huawei.com
Li, et al. Expires July 20, 2014 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-21 19:50:17 |