draft-ietf-pce-hierarchy-fwk-01.txt   draft-ietf-pce-hierarchy-fwk-02.txt 
Network Working Group D. King (Ed.) Network Working Group D. King (Ed.)
Internet-Draft Old Dog Consulting Internet-Draft Old Dog Consulting
Intended Status: Informational A. Farrel (Ed.) Intended Status: Informational A. Farrel (Ed.)
Expires: 11 August 2012 Old Dog Consulting Expires: 10 October 2012 Old Dog Consulting
11 March 2012 10 May 2012
The Application of the Path Computation Element Architecture to the The Application of the Path Computation Element Architecture to the
Determination of a Sequence of Domains in MPLS and GMPLS Determination of a Sequence of Domains in MPLS and GMPLS
draft-ietf-pce-hierarchy-fwk-01.txt draft-ietf-pce-hierarchy-fwk-02.txt
Abstract Abstract
Computing optimum routes for Label Switched Paths (LSPs) across Computing optimum routes for Label Switched Paths (LSPs) across
multiple domains in MPLS Traffic Engineering (MPLS-TE) and GMPLS multiple domains in MPLS Traffic Engineering (MPLS-TE) and GMPLS
networks presents a problem because no single point of path networks presents a problem because no single point of path
computation is aware of all of the links and resources in each computation is aware of all of the links and resources in each
domain. A solution may be achieved using the Path Computation domain. A solution may be achieved using the Path Computation
Element (PCE) architecture. Element (PCE) architecture.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on 11 August 2012. This Internet-Draft will expire on 10 October 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 6, line 24 skipping to change at page 6, line 24
breaks confidentiality and does not scale in the routing protocol. breaks confidentiality and does not scale in the routing protocol.
See Section 7 for a discussion of the concept of inter-domain traffic See Section 7 for a discussion of the concept of inter-domain traffic
engineering information exchange known as BGP-TE. engineering information exchange known as BGP-TE.
The primary goal of this document is to define how to derive optimal The primary goal of this document is to define how to derive optimal
end-to-end, multi-domain paths when the sequence of domains is not end-to-end, multi-domain paths when the sequence of domains is not
known in advance. The solution needs to be scalable and to maintain known in advance. The solution needs to be scalable and to maintain
internal domain topology confidentiality while providing the optimal internal domain topology confidentiality while providing the optimal
end-to-end path. It cannot rely on the exchange of TE information end-to-end path. It cannot rely on the exchange of TE information
between domains, and for the confidentiality, scaling, and between domains, and for the confidentiality, scaling, and
aggregation reasons just cited, it cannot utilise a computation aggregation reasons just cited, it cannot utilize a computation
element that has universal knowledge of TE properties and topology element that has universal knowledge of TE properties and topology
of all domains. of all domains.
The sub-sections that follow set out the primary objectives and The sub-sections that follow set out the primary objectives and
requirements to be satisfied by a PCE solution to multi-domain path requirements to be satisfied by a PCE solution to multi-domain path
computation. computation.
1.3.1 Metric Objectives 1.3.1 Metric Objectives
The definition of optimality is dependent on policy, and is based on The definition of optimality is dependent on policy, and is based on
skipping to change at page 9, line 44 skipping to change at page 9, line 44
because the most optimal path in one domain may lead to the choice of because the most optimal path in one domain may lead to the choice of
an entry BN for the next domain that results in a very poor path an entry BN for the next domain that results in a very poor path
across that next domain. across that next domain.
In the case that the domain path (in particular, the sequence of In the case that the domain path (in particular, the sequence of
boundary nodes) is not known, the PCE must select an exit BN based on boundary nodes) is not known, the PCE must select an exit BN based on
some determination of how to reach the destination that is outside some determination of how to reach the destination that is outside
the domain for which the PCE has computational responsibility. the domain for which the PCE has computational responsibility.
[RFC5152] suggest that this might be achieved using the IP shortest [RFC5152] suggest that this might be achieved using the IP shortest
path as advertise by BGP. Note, however, that the existence of an IP path as advertise by BGP. Note, however, that the existence of an IP
forwarding path does guarantee the presence of sufficient bandwidth, forwarding path does not guarantee the presence of sufficient
let alone an optimal TE path. Furthermore, in many GMPLS systems bandwidth, let alone an optimal TE path. Furthermore, in many GMPLS
inter-domain IP routing will not be present. Thus, per-domain path systems inter-domain IP routing will not be present. Thus, per-domain
computation may require a significant number of crankback routing path computation may require a significant number of crankback
attempts to establish even a sub-optimal path. routing attempts to establish even a sub-optimal path.
Note also that the PCEs in each domain may have different computation Note also that the PCEs in each domain may have different computation
capabilities, may run different path computation algorithms, and may capabilities, may run different path computation algorithms, and may
apply different sets of constraints and optimization criteria, etc. apply different sets of constraints and optimization criteria, etc.
This can result in the end-to-end path being inconsistent and sub- This can result in the end-to-end path being inconsistent and sub-
optimal. optimal.
Per-domain path computation can suit simply-connected domains where Per-domain path computation can suit simply-connected domains where
the preferred points of interconnection are known. the preferred points of interconnection are known.
skipping to change at page 12, line 52 skipping to change at page 12, line 52
o Minimize aggregate bandwidth consumption o Minimize aggregate bandwidth consumption
o Minimize or cap the number of transit domains o Minimize or cap the number of transit domains
o Disallow domain re-entry o Disallow domain re-entry
The objective function may be requested by the PCC, the ingress The objective function may be requested by the PCC, the ingress
domain PCE (according to local policy), or maybe applied by the domain PCE (according to local policy), or maybe applied by the
parent PCE according to inter-domain policy. parent PCE according to inter-domain policy.
More than one OF (or a composite OF) may be chosen to apply to a More than one OF (or a composite OF) may be chosen to apply to a
single computation provided they are not contradictory. Composite OFs single computation provided they are not contradictory. Composite OFs
may include weightings and preferences for the fulfilment of pieces may include weightings and preferences for the fulfillment of pieces
of the desired outcome. of the desired outcome.
4.2 Maintaining Domain Confidentiality 4.2 Maintaining Domain Confidentiality
Information about the content of child domains is not shared for Information about the content of child domains is not shared for
scaling and confidentiality reasons. This means that a parent PCE is scaling and confidentiality reasons. This means that a parent PCE is
aware of the domain topology and the nature of the connections aware of the domain topology and the nature of the connections
between domains, but is not aware of the content of the domains. between domains, but is not aware of the content of the domains.
Similarly, a child PCE cannot know the internal topology of another Similarly, a child PCE cannot know the internal topology of another
child domain. Child PCEs also do not know the general domain mesh child domain. Child PCEs also do not know the general domain mesh
skipping to change at page 28, line 29 skipping to change at page 28, line 29
scheme. Subsequent requests to and from the child and parent PCEs do scheme. Subsequent requests to and from the child and parent PCEs do
not differ from other path computation requests and should not have not differ from other path computation requests and should not have
any significant impact on network operations. any significant impact on network operations.
8. Security Considerations 8. Security Considerations
The hierarchical PCE procedure relies on PCEP and inherits the The hierarchical PCE procedure relies on PCEP and inherits the
security requirements defined [RFC5440]. As noted in Section 7, security requirements defined [RFC5440]. As noted in Section 7,
there is a security relationship between child and parent PCEs. there is a security relationship between child and parent PCEs.
This relationship, like any PCEP relationship assumes This relationship, like any PCEP relationship assumes
preconfiguration of identities, authority, and keys, or can pre-configuration of identities, authority, and keys, or can
operate through any key distribution mechanism outside the scope of operate through any key distribution mechanism outside the scope of
PCEP. As PCEP operates over TCP, it may make use of any TCP security PCEP. As PCEP operates over TCP, it may make use of any TCP security
mechanism. mechanism.
The hierarchical PCE architecture makes use of PCE policy The hierarchical PCE architecture makes use of PCE policy
[RFC5394] and the security aspects of the PCE communication protocol [RFC5394] and the security aspects of the PCE communication protocol
documented in [RFC5440]. It is expected that the parent PCE will documented in [RFC5440]. It is expected that the parent PCE will
require all child PCEs to use full security when communicating with require all child PCEs to use full security when communicating with
the parent and that security will be maintained by not supporting the the parent and that security will be maintained by not supporting the
discovery by a parent of child PCEs. discovery by a parent of child PCEs.
 End of changes. 7 change blocks. 
12 lines changed or deleted 12 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/