Internet DRAFT - draft-dhody-pce-of-diverse
draft-dhody-pce-of-diverse
PCE Working Group D. Dhody
Internet-Draft Q. Wu
Intended status: Standards Track Huawei Technologies
Expires: November 18, 2017 May 17, 2017
PCE support for Maximizing Diversity
draft-dhody-pce-of-diverse-07
Abstract
The computation of one or a set of Traffic Engineering Label Switched
Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) networks is subject to a set of one or more
specific optimization criteria, referred to as objective functions.
In the Path Computation Element (PCE) architecture, a Path
Computation Client (PCC) may want a set of services that are required
to be diverse (disjointed) from each other. In case when full
diversity could not be achieved, it is helpful to maximize diversity
as much as possible (or in other words, minimize the common shared
resources).
This document defines objective function code types for three new
objective functions for this purpose to be applied to a set of
synchronized path computation requests.
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 November 18, 2017.
Dhody & Wu Expires November 18, 2017 [Page 1]
Internet-Draft OF-DIVERSE May 2017
Copyright Notice
Copyright (c) 2017 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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Extension to PCEP . . . . . . . . . . . . . . . . . . . . . . 3
4. Other Considerations . . . . . . . . . . . . . . . . . . . . 4
4.1. Relationship between SVEC Diversity Flags and OF . . . . 4
4.2. Inter-Domain Considerations . . . . . . . . . . . . . . . 5
4.3. Domain Diversity . . . . . . . . . . . . . . . . . . . . 5
4.4. Diversity v/s Optimality . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Manageability Considerations . . . . . . . . . . . . . . . . 6
6.1. Control of Function and Policy . . . . . . . . . . . . . 6
6.2. Information and Data Models . . . . . . . . . . . . . . . 6
6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 6
6.4. Verify Correct Operations . . . . . . . . . . . . . . . . 6
6.5. Requirements On Other Protocols . . . . . . . . . . . . . 6
6.6. Impact On Network Operations . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 9
Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
[RFC5440] describes the specifications for the Path Computation
Element Communication Protocol (PCEP). PCEP specifies the
communication between a Path Computation Client (PCC) and a Path
Dhody & Wu Expires November 18, 2017 [Page 2]
Internet-Draft OF-DIVERSE May 2017
Computation Element (PCE), or between two PCEs based on the PCE
architecture [RFC4655].
Further [RFC5440] describes dependent path computation requests in
which case computations cannot be performed independently of each
other, and usually used for diverse path computation. [RFC5440] and
[RFC6006] describe the use of Synchronization VECtor (SVEC)
dependency flags (i.e., Node, Link, or Shared Risk Link Group (SRLG)
diverse flags).
In some scenario it may be noted that full diversity cannot be
achieved because of topology considerations, deployment
considerations, transient network issues etc. In this case it would
be helpful to maximize diversity as much as possible (or in other
words minimize the common shared resources (Node, Link or SRLG)
between a set of paths during path computation).
It is interesting to note that for non synchronized diverse path
computation the X bit in Exclude Route Object (XRO) or Explicit
Exclusion Route subobject (EXRS) [RFC5521] can be used, where X bit
set as 1 indicates that the resource specified SHOULD be excluded
from the path computed by the PCE, but MAY be included subject to PCE
policy and the absence of a viable path that meets the other
constraints and excludes the resource. Thus X bit can be used in a
way to maximize diversity (or minimize common shared resources) when
full diversity cannot be achieved.
This document defines objective function code types for three new
objective functions for this purpose to be applied to a set of
synchronized path computation requests.
1.1. 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 [RFC2119].
2. Terminology
The terminology is as per [RFC5440].
3. Extension to PCEP
[RFC5541] describes and define Objective function (OF) used in PCEP
protocol.
Dhody & Wu Expires November 18, 2017 [Page 3]
Internet-Draft OF-DIVERSE May 2017
To minimize the common shared resources (Node, Link or SRLG) between
a set of paths during path computation three new OF codes are
proposed:
MSL
* Name: Minimize the number of shared (common) Links.
* Objective Function Code: TBD1
* Description: Find a set of paths such that it passes through the
least number of shared (common) links.
MSN
* Name: Minimize the number of shared (common) Nodes.
* Objective Function Code: TBD2
* Description: Find a set of paths such that it passes through the
least number of shared (common) nodes.
MSS
* Name: Minimize the number of shared (common) SRLG.
* Objective Function Code: TBD3
* Description: Find a set of paths such that it share least number
of common SRLGs.
4. Other Considerations
4.1. Relationship between SVEC Diversity Flags and OF
[RFC5440] uses SVEC diversity flag for node, link or SRLG to describe
the potential disjointness between the set of path computation
requests used in PCEP protocol. [I-D.dwpz-pce-domain-diverse]
further extends by adding domain-diverse O-bit in SVEC object and a
new OF Code for minimizing the number of shared transit domain.
This document defines three new OF codes to maximize diversity as
much as possible, in other words, minimize the common shared
resources (Node,Link or SRLG) between a set of paths.
It may be interesting to note that the diversity flags in the SVEC
object and OF for diversity can be used together. Some example of
usage are listed below -
Dhody & Wu Expires November 18, 2017 [Page 4]
Internet-Draft OF-DIVERSE May 2017
o SVEC object with node-diverse bit=1 - ensure full node-diversity.
o SVEC object with node-diverse bit=1 and OF=MSS - full node diverse
with as much as SRLG-diversity as possible.
o SVEC object with domain-diverse bit=1;link diverse bit=1 and
OF=MSS - full domain and node diverse path with as much as SRLG-
diversity as possible.
o SVEC object with node-diverse bit=1 and OF=MSN - ensure full node-
diversity.
4.2. Inter-Domain Considerations
The mechanics for synchronous end to end path computations using
Backward-Recursive PCE-Based Computation (BRPC) procedure [RFC5441]
described in [RFC6006].
In H-PCE [RFC6805] architecture, the parent PCE is used to compute a
multi-domain path based on the domain connectivity information. The
parent PCE may be requested to provide a end to end path or only the
sequence of domains. Child PCE should be able to request
synchronized diverse end to end paths from its parent PCE.
The new objective function described in this document can be used to
maximize diversity when full diverse paths cannot be found.
4.3. Domain Diversity
As per [I-D.dwpz-pce-domain-diverse].
4.4. Diversity v/s Optimality
In case of non-synchronized path computation, PCE may be requested to
provide an optimal primary path first and then PCC requests for a
backup path with exclusion. Note that this approach does not
guarantee diversity comparing to disjoint path computations for
primary and backup path in a synchronized manner.
A synchronized path computation with diversity flags and/or objective
function is used to make sure that both the primary path and the
backup path can be computed simultaneously with full diversity or
optimized to be as diverse as possible. In the latter case we may
sacrifice optimal path for diversity, thus there is a trade-off
between the two.
An implementation may further choose to analyze the trade-off i.e. it
may send multiple request to PCE asking to optimize based on
Dhody & Wu Expires November 18, 2017 [Page 5]
Internet-Draft OF-DIVERSE May 2017
diversity as well as say, cost and make an intelligent choice between
them.
5. Security Considerations
PCEP security mechanisms are described in [RFC5440] and are used to
secure entire PCEP messages. Nothing in this document changes the
message flows or introduces any new messages, so the security
mechanisms set out in [RFC5440] continue to be applicable.
This document add new OF codes that may optionally be carried on PCEP
messages with OF object [RFC5541] and will be automatically secured
using the mechanisms described in [RFC5440].
If a PCEP message is vulnerable to attack (for example, because the
security mechanisms are not used), then the OF object could be used
as part of an attack; however, it is likely that other objects will
provide far more significant ways of attacking a PCE or PCC in this
case.
6. Manageability Considerations
6.1. Control of Function and Policy
In addition to [RFC5440], the PCC should construct the SVECs to
identify and associate diverse SVEC relationships. Considerations
for use of objective functions are mentioned in [RFC5541].
6.2. Information and Data Models
The PCEP MIB Module defined in [RFC7420], there are no additional
parameters identified in this document.
6.3. Liveness Detection and Monitoring
[RFC5440] provides a sufficient description for this document. There
are no additional considerations.
6.4. Verify Correct Operations
[RFC5440] provides a sufficient description for this document. There
are no additional considerations.
6.5. Requirements On Other Protocols
[RFC5440] provides a sufficient description for this document. There
are no additional considerations.
Dhody & Wu Expires November 18, 2017 [Page 6]
Internet-Draft OF-DIVERSE May 2017
6.6. Impact On Network Operations
Mechanisms defined in this document do not have any impact on network
operations in addition to those already listed in [RFC5440] and
[RFC5541].
7. IANA Considerations
As described in Section 3, three new Objective Functions have been
defined. IANA has made the following allocations from the PCEP
"Objective Function" sub-registry:
Value Description Reference
(TBD1) MSL [This I.D.]
(TBD2) MSN [This I.D.]
(TBD3) MSS [This I.D.]
8. Acknowledgments
We would like to thank Adrian Farrel for pointing out the need for
this document.
9. References
9.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>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541,
DOI 10.17487/RFC5541, June 2009,
<http://www.rfc-editor.org/info/rfc5541>.
9.2. Informative References
Dhody & Wu Expires November 18, 2017 [Page 7]
Internet-Draft OF-DIVERSE May 2017
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<http://www.rfc-editor.org/info/rfc4655>.
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
"A Backward-Recursive PCE-Based Computation (BRPC)
Procedure to Compute Shortest Constrained Inter-Domain
Traffic Engineering Label Switched Paths", RFC 5441,
DOI 10.17487/RFC5441, April 2009,
<http://www.rfc-editor.org/info/rfc5441>.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Path Computation Element Communication Protocol (PCEP) for
Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April
2009, <http://www.rfc-editor.org/info/rfc5521>.
[RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T.,
Ali, Z., and J. Meuric, "Extensions to the Path
Computation Element Communication Protocol (PCEP) for
Point-to-Multipoint Traffic Engineering Label Switched
Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010,
<http://www.rfc-editor.org/info/rfc6006>.
[RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the
Path Computation Element Architecture to the Determination
of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
DOI 10.17487/RFC6805, November 2012,
<http://www.rfc-editor.org/info/rfc6805>.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
Hardwick, "Path Computation Element Communication Protocol
(PCEP) Management Information Base (MIB) Module",
RFC 7420, DOI 10.17487/RFC7420, December 2014,
<http://www.rfc-editor.org/info/rfc7420>.
[I-D.dwpz-pce-domain-diverse]
Dhody, D., Wu, Q., Palle, U., and X. Zhang, "PCE support
for Domain Diversity", draft-dwpz-pce-domain-diverse-06
(work in progress), October 2016.
Dhody & Wu Expires November 18, 2017 [Page 8]
Internet-Draft OF-DIVERSE May 2017
Appendix A. Contributor Addresses
Xian Zhang
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R.China
EMail: zhang.xian@huawei.com
Udayasree Palle
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
EMail: udayasreereddy@gmail.com
Avantika
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
EMail: s.avantika.avantika@gmail.com
Appendix B. Example
This section illustrate an example based on SRLG.
(1) (2) (3)
A---------B---------C---------D
| | | |
| (2)| (5)| |
| | | |
+---------E---------F---------+
(4) (2) (5)
Node A is Ingress, Node D is Egress. A synchronized path computation
requests for SRLG disjoint path may be issued using the SVEC object
as described in [RFC5440]. In above topology a full SRLG disjoint
paths are not possible because of some topology considerations.
In such scenario, an OF MSS maybe used instead to minimize the number
of shared (common) SRLG to get maximum diversity when full diversity
may not be possible.
Dhody & Wu Expires November 18, 2017 [Page 9]
Internet-Draft OF-DIVERSE May 2017
In case of sequential non-synchronized path computation, primary path
will be computed first, say the path is (A--B--C--D) with SRLG list
(1,2,3). A backup path computation using XRO and SRLG sub-object
with X bit (loose) set as 1, can be used to achieve a similar result.
Authors' Addresses
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
EMail: dhruv.ietf@gmail.com
Qin Wu
Huawei Technologies
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
EMail: bill.wu@huawei.com
Dhody & Wu Expires November 18, 2017 [Page 10]
