One document matched: draft-li-mpls-serv-driven-co-lsp-fmwk-00.txt
Network Working Group Z. Li
Internet-Draft Z. Zhuang
Intended status: Informational J. Dong
Expires: April 18, 2013 Huawei Technologies
October 15, 2012
A Framework for Service-Driven Co-Routed MPLS Traffic Engineering LSPs
draft-li-mpls-serv-driven-co-lsp-fmwk-00
Abstract
This document provides a framework for setting up service-driven co-
routed MPLS Traffic-Engineered Label-Switched Paths(TE LSP) in Multi-
Protocol Label Switching (MPLS) networks.
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 April 18, 2013.
Copyright Notice
Copyright (c) 2012 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
Li, et al. Expires April 18, 2013 [Page 1]
Internet-Draft A Framework for SD Co-Routed LSPs October 2012
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. MPLS TE Configuration . . . . . . . . . . . . . . . . . . . 3
3.2. Return Path of BFD for LSP . . . . . . . . . . . . . . . . 3
3.3. Upgrading of Co-routed Bidirectional LSP . . . . . . . . . 4
4. Framework and Procedures . . . . . . . . . . . . . . . . . . . 4
4.1. Service-Driven Co-Routed Unidirectional LSPs for L2VPN . . 4
4.1.1. Framework . . . . . . . . . . . . . . . . . . . . . . . 4
4.1.2. Procedures . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Service-Driven Co-Routed Unidirectional LSPs for L3VPN . . 6
4.2.1. Framework . . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Li, et al. Expires April 18, 2013 [Page 2]
Internet-Draft A Framework for SD Co-Routed LSPs October 2012
1. Introduction
MPLS Traffic Engineering (TE) has been widely deployed to support
packet-based services. Rich Traffic Engineering properties can be
provied to satisfy different requirements of services. As the MPLS
TE LSP is deployed in networks of service providers, several
challenges has been proposed about esay operation and management.
This document propose a solution to set up co-routed MPLS TE LSPs on
demand to faciliate the deployment for services.
2. Terminology
This document uses terminology from the MPLS architecture document
[RFC3031] and from the RSVP-TE protocol specification [RFC3209] which
inherits from the RSVP specification [RFC2205].
The PEs can be generally categorized into two types:
1. Active PE: the PE which primarily triggers to set up the LSPs and
informs the remote PE;
2. Passive PE: the PE which secondarily complies with the active
PE's suggestion.
3. Problem Statement
3.1. MPLS TE Configuration
It is a common deployment scenario to set up MPLS Traffic
Engineering(TE) LSPs among a set of Label Switch Routers (LSR). Such
deployment may require the configuration of a potentially large
number of TE tunnels. The operation is not only time consuming but
also prone to misconfiguration for Service Providers. Hence, an
automatic mechanism for setting up MPLS TE tunnels is desirable which
can simplify the complexity of MPLS TE configuration.
3.2. Return Path of BFD for LSP
BFD for LSP ([RFC5884]) is used to detect the possible failure fast
and the failure detected can trigger traffic switch between the
primary LSP and the backup LSP. When BFD for LSP is deployed, the
return path may take IP path which is different from the forwarding
path. The failure that happens in the return path may trigger wrong
traffic switch.
Li, et al. Expires April 18, 2013 [Page 3]
Internet-Draft A Framework for SD Co-Routed LSPs October 2012
3.3. Upgrading of Co-routed Bidirectional LSP
Co-routed bidirectional LSPs can simplify operation and management
for Service Providers. Moreover co-routed bidirectional LSPs require
less states comparing with two unidirectional MPLS TE LSPs. .But the
unidirectlional LSP has been deployed widely and it is difficult for
the service provider to upgrade all possible routers to support co-
routed bidirectional LSPs.
4. Framework and Procedures
The section proposes the solution to trigger setting up MPLS TE LSP
by services. The framework an procedures of the solution are
introduced. With the solution, MPLS TE LSPs can setup on demand
which can reduce the statical configuration. In addition, the
signalling for the service will advertise the tunnel information
between the active PE and the passive PE. The LSP on the passive
side can setup according to RRO information of the LSP setup 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.
4.1. Service-Driven Co-Routed Unidirectional LSPs for L2VPN
4.1.1. Framework
Active PE Passive PE
| |
|<------Signalling Tunnel----->|
| |
| TE LSP1 for PW |
|----------------------------->|
| PW |
|<---------------------------->|
| TE LSP2 for PW |
|<-----------------------------|
+----+ +--+ +--+ +----+
| PE1|===|P1|======|P2|===| PE2|
+----+ +--+ +--+ +----+
| |
Figure 2: Signalling Tunnel Framework of L2VPN
Figure 2 shows a framework for co-routed MPLS TE LSPs driven by PW.
L2VPN is provisioned on PEs and PW is setup. A pair of PEs for a
specific PW will be identified as the active PE and the passive PE.
Li, et al. Expires April 18, 2013 [Page 4]
Internet-Draft A Framework for SD Co-Routed LSPs October 2012
The active PE triggers setting up the primary LSP to the passive PE
and advertises the tunnel information to the passive PE. According
to the information advertised the passive PE will set up the return
MPLS TE LSP which path is co-routed with that of the primary LSP.
4.1.2. Procedures
| (1) Active/passive role election |
| (Here Set PE1 as active role ) |
|<----------------------------------------->|
| |
Active Passive
(2)PE1's PW drives RSVP-TE (2) PE2 waits for Tunnel info
to Create TE LSP: LSP1 advertised from PE1
|(3) PE1 advertises LSP1 Tunnel info to PE2 |
|------------------------------------------>|
| |
(4) PE2 gets Tunnel info from PE1,
Create TE LSP (eg. LSP2) according
to RRO information of LSPl,
Binds LSP1 and LSP2 for PW;
|(5) PE2 advertises LSP2 Tunnel info to PE1 |
|<------------------------------------------|
| |
(6)PE1 binds LSP1 and LSP2 for PW;
| Co-routed TE LSP Established |
|<----------------------------------------->|
| |
Figure 3: Signalling Procedures of L2VPN
Figure 3 shows the detailed signalling procedures for L2VPN to drive
setup of co-routed MPLS TE LSPs:
(1) Active/passive role election through signalling for a pair of PEs
of a PW (Assume PE1 as active PE and PE2 as passive PE after election
);
(2) PE1's PW drives RSVP-TE to create TE LSP(LSP1) while PE2 waits
for tunnel information advertised by PE1;
Li, et al. Expires April 18, 2013 [Page 5]
Internet-Draft A Framework for SD Co-Routed LSPs October 2012
(3) PE1 advertises tunnel information related with LSP1 to PE2;
(4) PE2 gets tunnel information from PE1 and createS TE LSP (eg.
LSP2) according to RRO information derived from LSP1. PE2 binds LSP1
and LSP2 for PW;
(5) PE2 advertises tunnel information related with LSP2 to PE1;
(6) PE1 binds LSP1 and LSP2 for PW.
Through the above signalling 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
Active PE Passive PE
| |
|<------Signalling Tunnel----->|
| |
| TE LSP1 for L3VPN |
|----------------------------->|
| L3VPN |
|<---------------------------->|
| TE LSP2 for L3VPN |
|<-----------------------------|
+----+ +--+ +--+ +----+
| PE1|===|P1|======|P2|===| PE2|
+----+ +--+ +--+ +----+
| |
Figure 4: Signalling Tunnel Framework of L3VPN
Figure 4 shows a framework for co-routed MPLS TE LSPs driven by
L3VPN. L3VPN is provisioned on PEs and VPN members are discovered.
A pair of PEs for L3VPN members will be identified as the active PE
and the passive PE. The active PE triggers set up the primary LSP to
the passive PE and advertises the tunnel information to the passive
PE. According to the information advertised the passive PE will set
up the return MPLS TE LSP which path is co-routed with that of the
primary LSP.
4.2.1.1. Procedures
Li, et al. Expires April 18, 2013 [Page 6]
Internet-Draft A Framework for SD Co-Routed LSPs October 2012
| (0) VPN Member Auto-Discorvery |
|<----------------------------------------->|
| |
| (1) active/passive role election |
| (Here Set PE1 as active role ) |
|<----------------------------------------->|
| |
Active Passive
(2)PE1's L3VPN drives RSVP-TE (2) PE2 waits for Tunnel info
to Create TE LSP: LSP1 advertised from PE1
|(3) PE1 advertises LSP1 Tunnel info to PE2 |
|------------------------------------------>|
| |
(4) PE2 gets Tunnel info from PE1,
Create TE LSP (eg. LSP2) according
to RRO information of LSPl,
Binds LSP1 and LSP2 for L3VPN;
|(5) PE2 advertises LSP2 Tunnel info to PE1 |
|<------------------------------------------|
| |
(6)PE1 binds LSP1 and LSP2 for L3VPN;
| Co-routed TE LSP Established |
|<----------------------------------------->|
| |
Figure 5: Signalling Procedures of L3VPN
Figure 5 shows the detailed signalling procedures for L3VPN to drive
setup of co-routed MPLS TE LSPs :
(0) VPN member auto-discovery process is done through signalling to
identify a pair of VPN members;
(1) Active/passive role election through signalling for a pair of PEs
of a PW (Assume PE1 as active PE and PE2 as passive PE after election
);
(2) PE1's PW drives RSVP-TE to create TE LSP(LSP1) while PE2 waits
for tunnel information advertised by PE1;
(3) PE1 advertises tunnel information related with LSP1 to PE2;
Li, et al. Expires April 18, 2013 [Page 7]
Internet-Draft A Framework for SD Co-Routed LSPs October 2012
(4) PE2 gets tunnel information from PE1 and createS TE LSP (eg.
LSP2) according to RRO information derived from LSP1. PE2 binds LSP1
and LSP2 for L3VPN;
(5) PE2 advertises tunnel information related with LSP2 to PE1;
(6) PE1 binds LSP1 and LSP2 for L3VPN.
Through the above signalling procedure, 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, March 1997.
7.2. Informative References
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, 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.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010.
Li, et al. Expires April 18, 2013 [Page 8]
Internet-Draft A Framework for SD Co-Routed LSPs October 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
URI: jie.dong@huawei.com
Jie Dong
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: jie.dong@huawei.com
Li, et al. Expires April 18, 2013 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-21 19:55:02 |