PCE support for Domain Diversity
draft-dwpz-pce-domain-diverse-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Dhruv Dhody , Qin Wu , Udayasree Palle , Xian Zhang | ||
| Last updated | 2013-09-24 | ||
| Replaced by | draft-ietf-pce-hierarchy-extensions, RFC 8685, RFC 8685 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-dwpz-pce-domain-diverse-00
PCE Working Group D. Dhody
Internet-Draft Q. Wu
Intended status: Experimental U. Palle
Expires: March 28, 2014 X. Zhang
Huawei Technologies
September 24, 2013
PCE support for Domain Diversity
draft-dwpz-pce-domain-diverse-00
Abstract
The Path Computation Element (PCE) may be used for computing path for
services that traverse multi-area and multi-AS Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE)
networks.
Path computation should facilitate the selection of paths with domain
diversity. This document examines the existing mechanisms to do so
and further propose some extensions to Path Computation Element
Protocol (PCEP).
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 March 28, 2014.
Copyright Notice
Copyright (c) 2013 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
Dhody, et al. Expires March 28, 2014 [Page 1]
Internet-Draft DOMAIN-DIVERSE September 2013
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. Domain Diversity . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Per Domain Path Computation . . . . . . . . . . . . . . . 4
3.2. Backward-Recursive PCE-based Computation . . . . . . . . 4
3.3. Hierarchical PCE . . . . . . . . . . . . . . . . . . . . 4
3.3.1. End to End Path . . . . . . . . . . . . . . . . . . . 5
3.3.2. Domain-Sequence . . . . . . . . . . . . . . . . . . . 5
4. Extension to PCEP . . . . . . . . . . . . . . . . . . . . . . 5
4.1. SVEC Object . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Transit Domain Identifier . . . . . . . . . . . . . . . . 6
4.3. Minimize Shared Domains . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Manageability Considerations . . . . . . . . . . . . . . . . 7
6.1. Control of Function and Policy . . . . . . . . . . . . . 7
6.2. Information and Data Models . . . . . . . . . . . . . . . 7
6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 7
6.4. Verify Correct Operations . . . . . . . . . . . . . . . . 7
6.5. Requirements On Other Protocols . . . . . . . . . . . . . 7
6.6. Impact On Network Operations . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 9
1. Introduction
The ability to compute shortest constrained TE LSPs in Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across
multiple domains has been identified as a key requirement. In this
context, a domain is a collection of network elements within a common
sphere of address management or path computational responsibility
such as an Interior Gateway Protocol (IGP) area or an Autonomous
Systems (AS).
Dhody, et al. Expires March 28, 2014 [Page 2]
Internet-Draft DOMAIN-DIVERSE September 2013
In a multi-domain environment, Domain Diversity is defined in
[RFC6805]. A pair of paths are domain-diverse if they do not
traverse any of the same transit domains. Domain diversity may be
maximized for a pair of paths by selecting paths that have the
smallest number of shared domains. Path computation should
facilitate the selection of domain diverse paths as a way to reduce
the risk of shared failure and automatically helps to ensure path
diversity for most of the route of a pair of LSPs.
This document examine a way to achieve domain diversity with existing
inter-domain path computation mechanism like per-domain path
computation technique [RFC5152], Backward Recursive Path Computation
(BRPC) mechanism [RFC5441] and Hierarchical PCE [RFC6805]. This
document also considers synchronized dependent path computations as
well as non-synchronized path computation. Since independent and
synchronized path computation cannot be used to apply diversity, it
is not discussed in this document.
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. Domain Diversity
As described in [RFC6805], a set of paths are considered to be domain
diverse if they do not share any transit domains, apart from ingress
and egress domains.
Some additional parameters to consider would be -
Minimize shared domain: When a fully domain diverse path is not
possible, PCE could be requested to minimize the number of shared
transit domains. This can also be termed as maximizing partial
domain diversity.
Boundary Nodes: TBD
Dhody, et al. Expires March 28, 2014 [Page 3]
Internet-Draft DOMAIN-DIVERSE September 2013
3.1. Per Domain Path Computation
The per domain path computation technique [RFC5152] defines a method
where the path is computed during the signaling process (on a per-
domain basis). The entry Boundary Node (BN) of each domain is
responsible for performing the path computation for the section of
the LSP that crosses the domain, or for requesting that a PCE for
that domain computes that piece of the path.
Non-Synchronized Path Computation: Path computations are performed
in a serialized and independent fashion. After the setup of
primary path, a domain diverse path can be signaled by encoding
the transit domain identifiers in XRO or EXRS using domain sub-
objects defined in [DOMAIN-SUBOBJ] and [RFC3209] in RSVP-TE. Note
that the head end LSR should be aware of transit domain
identifiers of the primary path to be able to do so.
Synchronized Path Computation: Not Applicable.
3.2. Backward-Recursive PCE-based Computation
The BRPC [RFC5441] technique involves cooperation and communication
between PCEs in order to compute an optimal end-to-end path across
multiple domains. The sequence of domains to be traversed maybe
known before the path computation, but it can also be used when the
domain path is unknown and determined during path computation.
Non-Synchronized Path Computation: Path computations are performed
in a serialized and independent fashion. After the path
computation and setup of primary path, a domain diverse path
computation request is sent by PCC to the PCE, by encoding the
transit domain identifiers in XRO or EXRS using domain sub-objects
defined in [PCE-DOMAIN] and [RFC3209] in PCEP. Note that the PCC
should be aware of transit domain identifiers of the primary path
to be able to do so.
Synchronized Path Computation: Not Applicable. [Since different
transit domain PCEs are involved , there is no way to achieve
synchronization for domain diverse paths]. BTW [RFC5440]
describes other diversity parameters (node, link etc).
3.3. Hierarchical PCE
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.
Dhody, et al. Expires March 28, 2014 [Page 4]
Internet-Draft DOMAIN-DIVERSE September 2013
3.3.1. End to End Path
Non-Synchronized Path Computation: Path computations are performed
in a serialized and independent fashion. After the path
computation and setup of primary path, a domain diverse path
computation request is sent to the parent PCE, by encoding the
transit domain identifiers in XRO or EXRS using domain sub-objects
defined in [PCE-DOMAIN] and [RFC3209] in PCEP. Note that the PCC
should be aware of transit domain identifiers of the primary path
to be able to do so. The parent PCE should provide a domain
diverse end to end path.
Synchronized Path Computation: Child PCE should be able to request
dependent and synchronized domain diverse end to end paths from
its parent PCE. A new flag is added in SVEC object for this
(Refer Section 4.1).
3.3.2. Domain-Sequence
Non-Synchronized Path Computation: Path computations are performed
in a serialized and independent fashion. After the primary path
computation using H-PCE (involving domain-sequence selection by
parent PCE and end-to-end path computation via BRPC or Per-Domain
mechanisms) and setup, a domain diverse path computation request
is sent to the parent PCE, by encoding the transit domain
identifiers in XRO or EXRS using domain sub-objects defined in
[PCE-DOMAIN] and [RFC3209] in PCEP. Note that the PCC should be
aware of transit domain identifiers of the primary path to be able
to do so. The parent PCE should provide a diverse domain
sequence.
Synchronized Path Computation: Child PCE should be able to request
dependent and synchronized diverse domain-sequence(s) from its
parent PCE. A new flag is added in SVEC object for this (Refer
Section 4.1). The parent PCE should reply with diverse domain
sequence(s) encoded in ERO as described in [PCE-DOMAIN].
4. Extension to PCEP
4.1. SVEC Object
[RFC5440] defines SVEC object which includes flags for the potential
dependency between the set of path computation requests (Link, Node
and SRLG diverse). This document proposes a new flag O for domain
diversity.
The format of the SVEC object body is as follows:
Dhody, et al. Expires March 28, 2014 [Page 5]
Internet-Draft DOMAIN-DIVERSE September 2013
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |O|P|D|S|N|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number #1 |
// //
| Request-ID-number #M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SVEC Body Object Format
Following new bit is added in the Flags field:
* O (Domain diverse) bit: when set, this indicates that the computed
paths corresponding to the requests specified by the following RP
objects MUST NOT have any transit domain(s) in common.
The Domain Diverse O-bit can be used in Hierarchical PCE path
computation to compute synchronized domain diverse end to end path or
diverse domain sequences as described in Section 3.3.
When domain diverse O bit is set, it is applied to the transit
domains. The other bit in SVEC object (N, L etc) is set, should
still be applied in the ingress and egress domain.
4.2. Transit Domain Identifier
In case of non-synchronized path computation, Ingress node (i.e. a
PCC) should be aware of transit domain identifiers of the primary
path. So during the path computation or signaling of the primary
path, the transit domain should be identified.
A possible solution for path computation could be a flag in RP object
requesting domain identifier to be returned in the PCEP path reply
message. Further details - TBD
4.3. Minimize Shared Domains
A new Objective function (OF) [RFC5541] code for synchronized path
computation requests is proposed:
MCTD
* Name: Minimize the number of Common Transit Domains.
* Objective Function Code: TBD
Dhody, et al. Expires March 28, 2014 [Page 6]
Internet-Draft DOMAIN-DIVERSE September 2013
* Description: Find a set of paths such that it passes through the
least number of common transit domains.
The MCTD OF can be used in Hierarchical PCE path computation to
request synchronized domain diverse end to end paths or diverse
domain sequences as described in Section 3.3.
For non synchronized diverse domain path computation the X bit in XRO
or EXRS [RFC5521] sub-objects can be used, where X bit set as 1
indicates that the domain 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 domain.
5. Security Considerations
TBD.
6. Manageability Considerations
6.1. Control of Function and Policy
TBD.
6.2. Information and Data Models
TBD.
6.3. Liveness Detection and Monitoring
TBD.
6.4. Verify Correct Operations
TBD.
6.5. Requirements On Other Protocols
TBD.
6.6. Impact On Network Operations
TBD.
7. IANA Considerations
TBD.
Dhody, et al. Expires March 28, 2014 [Page 7]
Internet-Draft DOMAIN-DIVERSE September 2013
8. Acknowledgments
We would like to thank Qilei Wang for starting this discussion in the
mailing list.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[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.
[RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain
Path Computation Method for Establishing Inter-Domain
Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC
5152, February 2008.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440, March
2009.
[RFC5441] Vasseur, JP., 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, April 2009.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Path Computation Element Communication Protocol (PCEP) for
Route Exclusions", RFC 5521, April 2009.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541, June 2009.
[RFC6805] King, D. and A. Farrel, "The Application of the Path
Computation Element Architecture to the Determination of a
Sequence of Domains in MPLS and GMPLS", RFC 6805, November
2012.
[DOMAIN-SUBOBJ]
Dhody, D., Palle, U., Kondreddy, V., and R. Casellas,
"Domain Subobjects for Resource ReserVation Protocol -
Dhody, et al. Expires March 28, 2014 [Page 8]
Internet-Draft DOMAIN-DIVERSE September 2013
Traffic Engineering (RSVP-TE). (draft-dhody-ccamp-rsvp-te-
domain-subobjects)", July 2013.
[PCE-DOMAIN]
Dhody, D., Palle, U., and R. Casellas, "Standard
Representation Of Domain Sequence. (draft-ietf-pce-pcep-
domain-sequence)", July 2013.
Appendix A. Contributor Addresses
Ramon Casellas
CTTC - Centre Tecnologic de Telecomunicacions de Catalunya
Av. Carl Friedrich Gauss n7
Castelldefels, Barcelona 08860
SPAIN
EMail: ramon.casellas@cttc.es
Avantika
Huawei Technologies
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: avantika.sushilkumar@huawei.com
Authors' Addresses
Dhruv Dhody
Huawei Technologies
Leela Palace
Bangalore, Karnataka 560008
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, et al. Expires March 28, 2014 [Page 9]
Internet-Draft DOMAIN-DIVERSE September 2013
Udayasree Palle
Huawei Technologies
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: udayasree.palle@huawei.com
Xian Zhang
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R.China
EMail: zhang.xian@huawei.com
Dhody, et al. Expires March 28, 2014 [Page 10]