draft-ietf-pce-path-key-01.txt   draft-ietf-pce-path-key-02.txt 
Networking Working Group Rich Bradford (Ed) Networking Working Group Rich Bradford (Ed)
Internet-Draft JP Vasseur Internet-Draft JP Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
Intended Status: Standards Track Intended Status: Standards Track
Expires: March 12, 2008 Expires: Aug 23, 2008
September 12, 2007 Feb 23, 2008
draft-ietf-pce-path-key-01.txt draft-ietf-pce-path-key-02.txt
Preserving Topology Confidentiality in Inter-Domain Path Preserving Topology Confidentiality in Inter-Domain Path
Computation Using a Key-Based Mechanism Computation Using a Key-Based Mechanism
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at line 39 skipping to change at page 10, line ?
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 March 12, 2008. This Internet-Draft will expire on August 8, 2008.
Bradford, Vasseur and Farrel 1
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). All rights reserved. Copyright (C) The IETF Trust (2008). All rights reserved.
Abstract Abstract
Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
Traffic Engineering (TE) Label Switched Paths (LSPs) may be Traffic Engineering (TE) Label Switched Paths (LSPs) may be
computed by Path Computation Elements (PCEs). Where the TE LSP computed by Path Computation Elements (PCEs). Where the TE LSP
crosses multiple domains, such as Autonomous Systems (ASes), the crosses multiple domains, such as Autonomous Systems (ASes), the
path may be computed by multiple PCEs that cooperate, with each path may be computed by multiple PCEs that cooperate, with each
responsible for computing a segment of the path. However, in some responsible for computing a segment of the path. However, in some
cases (e.g. when ASes are administered by separate Service cases (e.g., when ASes are administered by separate Service
Providers), it would break confidentiality rules for a PCE to Providers), it would break confidentiality rules for a PCE to
supply a path segment to a PCE in another domain, thus disclosing supply a path segment to a PCE in another domain, thus disclosing
internal topology information. This issue may be circumvented by AS-internal topology information. This issue may be circumvented
returning a loose hop and by invoking a new path computation from by returning a loose hop and by invoking a new path computation
the domain boundary LSR during TE LSP setup as the signaling from the domain boundary Label Switching Router (LSR) during TE
message enters the second domain, but this technique has several LSP setup as the signaling message enters the second domain, but
issues including the problem of maintaining path diversity. this technique has several issues including the problem of
maintaining path diversity.
This document defines a mechanism to hide the contents of a This document defines a mechanism to hide the contents of a
segment of a path, called the Confidential Path Segment (CPS). The segment of a path, called the Confidential Path Segment (CPS). The
CPS may be replaced by a path-key that can be conveyed in the PCE CPS may be replaced by a path-key that can be conveyed in the PCE
Communication Protocol (PCEP) and signaled within in a Resource Communication Protocol (PCEP) and signaled within in a Resource
Reservation Protocol TE (RSVP-TE) explicit route object. Reservation Protocol TE (RSVP-TE) explicit route object.
Table of contents Table of contents
1. Terminology..................................................3 1. Introduction.................................................3
2. Introduction.................................................4 1.1. Terminology.................................................5
3. Path-Key Solution............................................5 2. Path-Key Solution............................................5
3.1. Mode of Operation...........................................6 2.1. Mode of Operation...........................................6
4. PCEP Protocol Extensions.....................................7 2.2. Example.....................................................7
4.1. PATH-KEY Object.............................................7 3. PCEP Protocol Extensions.....................................8
4.2. PKS subobject...............................................7 3.1. Path Keys in PCRep Messages.................................8
4.3. Path Key Bit...............................................10 3.1.1. PKS with 32-bit PCE ID....................................9
5. PCEP Mode of Operation......................................10 3.1.2. PKS with 128-bit PCE ID..................................10
6. Security Considerations.....................................11 3.2. Unlocking Path Keys........................................11
7. Manageability Considerations................................12 3.2.1. Path Key Bit.............................................11
7.1. Control of Function Through Configuration and Policy.......12 3.2.2. PATH-KEY Object..........................................11
7.2. Information and Data Models................................13 3.2.3. Path Computation Request (PCReq) message with Path Key...11
7.3. Liveness Detection and Monitoring..........................13 4. PCEP Mode of Operation for Path Key Expansion...............12
7.4. Verifying Correct Operation................................14 5. Security Considerations.....................................13
7.5. Requirements on Other Protocols and Functional Components..14 6. Manageability Considerations................................14
7.6. Impact on Network Operation................................14
Bradford, Vasseur, and Farrel 2 Bradford, Vasseur, and Farrel [Page 2]
8. IANA Considerations.........................................15 6.1. Control of Function Through Configuration and Policy.......14
8.1. New Subobjects for the ERO Object..........................15 6.2. Information and Data Models................................15
8.2. New PCEP Object............................................15 6.3. Liveness Detection and Monitoring..........................15
8.3. New RP Object Bit Flag.....................................16 6.4. Verifying Correct Operation................................16
9. Intellectual Property Considerations........................16 6.5. Requirements on Other Protocols and Functional Components..16
10. References.................................................17 6.6. Impact on Network Operation................................16
10.1. Normative References.....................................17 7. IANA Considerations.........................................17
10.2. Informational References.................................17 7.1. New Subobjects for the ERO Object..........................17
11. Authors' Addresses:........................................18 7.2. New PCEP Object............................................17
7.3. New RP Object Bit Flag.....................................18
7.4. New NO-PATH-VECTOR TLV Bit Flag............................18
8. Normative References........................................18
9. Informational References....................................18
10. Acknowledgements...........................................19
11. Authors' Addresses.........................................19
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
RFC-2119 [RFC2119]. RFC-2119 [RFC2119].
1. Terminology 1. Introduction
AS: Autonomous System.
ASBR: Autonomous System Border Routers used to connect to another
AS of a different or the same Service Provider via one or more
links inter-connecting between ASes.
CPS: Confidential Path Segment. A segment of a path that contains
nodes and links that the AS policy requires to not be disclosed
outside the AS.
Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
LSR: Label Switching Router.
LSP: Label Switched Path.
PCC: Path Computation Client: Any client application requesting a
path computation to be performed by a Path Computation Element.
PCE: Path Computation Element: An entity (component, application
or network node) that is capable of computing a network path or
Bradford, Vasseur, and Farrel 3
route based on a network graph and applying computational
constraints.
TE LSP: Traffic Engineering Label Switched Path
2. Introduction
Path computation techniques using the Path Computation Element Path computation techniques using the Path Computation Element
(PCE) are described in [RFC4655] and allow for path computation of (PCE) are described in [RFC4655] and allow for path computation of
inter-domain Multiprotocol Label Switching (MPLS) Traffic inter-domain Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) and Generalized MPLS (GMPLS) Label Switched Paths Engineering (TE) and Generalized MPLS (GMPLS) Label Switched Paths
(LSPs). (LSPs).
An important element of inter-domain TE is that TE information is An important element of inter-domain TE is that TE information is
not shared between domains for scalability and confidentiality not shared between domains for scalability and confidentiality
reasons ([RFC4105] and [RFC4216]). Therefore, a single PCE is reasons ([RFC4105] and [RFC4216]). Therefore, a single PCE is
unlikely to be able to compute a full inter-domain path. unlikely to be able to compute a full inter-domain path.
Two path computation scenarios can be used for inter-domain TE Two path computation scenarios can be used for inter-domain TE
LSPs: one using per-domain path computation (defined in [PD-PATH- LSPs: one using per-domain path computation (defined in [PD-PATH-
COMP]), and the other using a PCE-based path computation technique COMP]), and the other using a PCE-based path computation technique
with cooperation between PCEs (as described in [RFC4655]). In this with cooperation between PCEs (as described in [RFC4655]). In this
Bradford, Vasseur, and Farrel [Page 3]
second case, paths for inter-domain LSPs can be computed by second case, paths for inter-domain LSPs can be computed by
cooperation between PCEs each of which computes a segment of the cooperation between PCEs each of which computes a segment of the
path across one domain. Such a path computation procedure is path across one domain. Such a path computation procedure is
described in [BRPC]. described in [BRPC].
If confidentiality is required between domains (such as would very If confidentiality is required between domains (such as would very
likely be the case between ASes belonging to different Service likely be the case between Autonomous Systems (ASes) belonging to
Providers) then cooperating PCEs cannot exchange path segments or different Service Providers) then cooperating PCEs cannot exchange
else the receiving PCE and the Path Computation Client (PCC) will path segments or else the receiving PCE and the Path Computation
be able to see the individual hops through another domain thus Client (PCC) will be able to see the individual hops through
breaking the confidentiality requirement stated in [RFC4105] and another domain thus breaking the confidentiality requirement
[RFC4216]. We define the part of the path which we wish to keep stated in [RFC4105] and [RFC4216]. We define the part of the path
confidential as the Confidential Path Segment (CPS). which we wish to keep confidential as the Confidential Path
Segment (CPS).
One mechanism for preserving the confidentiality of the CPS is for One mechanism for preserving the confidentiality of the CPS is for
the PCE to return a path containing a loose hop in place of the the PCE to return a path containing a loose hop in place of the
segment that must be kept confidential. The concept of loose and segment that must be kept confidential. The concept of loose and
strict hops for the route of a TE LSP is described in [RFC3209]. strict hops for the route of a TE LSP is described in [RFC3209].
The Path Computation Element Communication Protocol (PCEP) defined The Path Computation Element Communication Protocol (PCEP) defined
in [PCEP] supports the use of paths with loose hops, and it is a in [PCEP] supports the use of paths with loose hops, and it is a
local policy decision at a PCE whether it returns a full explicit local policy decision at a PCE whether it returns a full explicit
path with strict hops or uses loose hops. Note that a Path path with strict hops or uses loose hops. Note that a Path
computation Request may request an explicit path with strict hops computation Request may request an explicit path with strict hops
or may allow loose hops as detailed in [PCEP]. or may allow loose hops as detailed in [PCEP].
Bradford, Vasseur, and Farrel 4
The option of returning a loose hop in place of the CPS can be The option of returning a loose hop in place of the CPS can be
achieved without further extensions to PCEP or the signaling achieved without further extensions to PCEP or the signaling
protocol. If loose hops are used, the TE LSPs are signaled as protocol. If loose hops are used, the TE LSPs are signaled as
normal ([RFC3209]), and when a loose hop is encountered in the normal ([RFC3209]), and when a loose hop is encountered in the
explicit route it is resolved by performing a secondary path explicit route it is resolved by performing a secondary path
computation to reach the resource or set of resources identified computation to reach the resource or set of resources identified
by the loose hop. Given the nature of the cooperation between PCEs by the loose hop. Given the nature of the cooperation between PCEs
in computing the original path, this secondary computation occurs in computing the original path, this secondary computation occurs
at or on behalf of a Label Switching Router (LSR) at a domain at or on behalf of a Label Switching Router (LSR) at a domain
boundary (i.e., an ABR or ASBR) and the path is expanded as boundary (i.e., an Area Border Router (ABR) or an AS Border Router
described in [PD-PATH-COMP]. (ASBR)) and the path is expanded as described in [PD-PATH-COMP].
The PCE-based computation model is particularly useful for The PCE-based computation model is particularly useful for
determining mutually disjoint inter-domain paths such as might be determining mutually disjoint inter-domain paths such as might be
required for service protection [INTER-DOM-REC]. A single path required for service protection [INTER-DOM-REC]. A single path
computation request is used. However, if loose hops are returned, computation request is used. However, if loose hops are returned,
the path of each TE LSP must be recomputed at the domain the path of each TE LSP must be recomputed at the domain
boundaries as the TE LSPs are signaled, and since the TE LSP boundaries as the TE LSPs are signaled, and since the TE LSP
signaling proceeds independently for each TE LSP, disjoint paths signaling proceeds independently for each TE LSP, disjoint paths
cannot be guaranteed since the LSRs in charge of expanding the cannot be guaranteed since the LSRs in charge of expanding the
EROs are not synchronized. Therefore, if the loose hop technique EROs are not synchronized. Therefore, if the loose hop technique
Bradford, Vasseur, and Farrel [Page 4]
is used without further extensions, path segment confidentiality is used without further extensions, path segment confidentiality
and path diversity are mutually incompatible requirements. and path diversity are mutually incompatible requirements.
This document defines the notion of a Path Key that is a token This document defines the notion of a Path Key that is a token
that replaces a path segment in an explicit route. The Path Key is that replaces a path segment in an explicit route. The Path Key is
encoded as a Path Key Subobject (PKS) returned in the PCEP Path encoded as a Path Key Subobject (PKS) returned in the PCEP Path
Computation Reply message (PCRep) ([PCEP]). Upon receiving the Computation Reply message (PCRep) ([PCEP]). Upon receiving the
computed path, the PKS will be carried in an RSVP-TE Path message computed path, the PKS will be carried in an RSVP-TE Path message
(RSVP-TE [RFC3209] and [RSVP-PKS]) during signaling. (RSVP-TE [RFC3209] and [RSVP-PKS]) during signaling.
3. Path-Key Solution 1.1. Terminology
This document makes use of the following terminology and acronyms.
AS: Autonomous System.
ASBR: Autonomous System Border Routers used to connect to another
AS of a different or the same Service Provider via one or more
links inter-connecting between ASes.
CPS: Confidential Path Segment. A segment of a path that contains
nodes and links that the AS policy requires to not be disclosed
outside the AS.
Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
LSR: Label Switching Router.
LSP: Label Switched Path.
PCC: Path Computation Client: Any client application requesting a
path computation to be performed by a Path Computation Element.
PCE: Path Computation Element: An entity (component, application
or network node) that is capable of computing a network path or
route based on a network graph and applying computational
constraints.
TE LSP: Traffic Engineering Label Switched Path
2. Path-Key Solution
The Path-Key solution may be applied in the PCE-based path The Path-Key solution may be applied in the PCE-based path
computation context as follows. A PCE computes a path segment computation context as follows. A PCE computes a path segment
related to a particular domain and replaces any CPS in the path related to a particular domain and replaces any CPS in the path
reported to the requesting PCC (or another PCE) by one or more reported to the requesting PCC (or another PCE) by one or more
subobjects referred to as PKSes. The entry boundary LSR of each
CPS SHOULD be specified as a hop in the returned path immediately
preceding the CPS, but where two PKSes are supplied in sequence
with no intervening nodes, the entry node to the second CPS MAY be
part of the first CPS and does not need to be explicitly present
in the returned path. The exit node of a CPS MAY be present as a
strict hop immediately following the PKS.
Bradford, Vasseur, and Farrel 5 Bradford, Vasseur, and Farrel [Page 5]
subobjects referred to as PKSes. The entry boundary LSR of each
CPS SHOULD be specified using its TE Router Id as a hop in the
returned path immediately preceding the CPS, and other sub-objects
MAY be included in the path immediately before the hop identifying
the boundary LSR to indicate link and label choices. Where two
PKSes are supplied in sequence with no intervening nodes, the
entry node to the second CPS MAY be part of the first CPS and does
not need to be explicitly present in the returned path. The exit
node of a CPS MAY be present as a strict hop immediately following
the PKS.
3.1. Mode of Operation 2.1. Mode of Operation
During path computation, when local policy dictates that During path computation, when local policy dictates that
confidentiality must be preserved for all or part of the path confidentiality must be preserved for all or part of the path
segment being computed or if explicitly requested by the Path segment being computed or if explicitly requested by the Path
Computation Request, the PCE associates a path-key with the Computation Request, the PCE associates a path-key with the
computed path for the CPS, places its own identifier (its PCE ID computed path for the CPS, places its own identifier (its PCE ID
as defined in section 4.2. ) along with the path-key in a PKS, and as defined in Section 3.1) along with the path-key in a PKS, and
inserts the PKS object in the path returned to the requesting PCC inserts the PKS object in the path returned to the requesting PCC
or PCE immediately after the IPv4 subobject defined in [RFC3209] or PCE immediately after the subobject that identifies (using the
subobject that identifies the LSR that will expand the PKS into a TE Router Id) the LSR that will expand the PKS into explicit path
explicit path hops. This will usually be the LSR that is the start hops.This will usually be the LSR that is the start point of the
point of the CPS. The PCE that generates a PKS SHOULD store the CPS. The PCE that generates a PKS SHOULD store the computed path
computed path segment and the path-key for later retrieval. A segment and the path-key for later retrieval. A local policy
local policy SHOULD be used to determine for how long to retain SHOULD be used to determine for how long to retain such stored
such stored information, and whether to discard the information information, and whether to discard the information after it has
after it has been queried using the procedures described below. It been queried using the procedures described below. It is
is RECOMMENDED for a PCE to store the PKS for a period of 10 RECOMMENDED for a PCE to store the PKS for a period of 10 minutes.
minutes.
A path-key value is scoped to the PCE that computed it as A path-key value is scoped to the PCE that computed it as
identified by the PCE-ID carried in the PKS. A PCE MUST NOT re-use identified by the PCE-ID carried in the PKS. A PCE MUST NOT re-use
a path-key value to represent a new CPS for at least 30 minutes a path-key value to represent a new CPS for at least 30 minutes
after discarding the previous use of the same path-key. A PCE that after discarding the previous use of the same path-key. A PCE that
is unable to retain information about previously used path-key is unable to retain information about previously used path-key
values over a restart SHOULD use some other mechanism to guarantee values over a restart SHOULD use some other mechanism to guarantee
uniqueness of path-key values such as embedding a timestamp or uniqueness of path-key values such as embedding a timestamp or
version number in the path-key. version number in the path-key.
A head-end LSR that is a PCC converts the path returned by a PCE A head-end LSR that is a PCC converts the path returned by a PCE
into an explicit route object (ERO) that it includes in the into an explicit route object (ERO) that it includes in the
Resource Reservation Protocol (RSVP) Path message. If the path Resource Reservation Protocol (RSVP) Path message. If the path
returned by the PCE contains a PKS, this is included in the ERO. returned by the PCE contains a PKS, this is included in the ERO.
Like any other subobjects, the PKS is passed transparently from Like any other subobjects, the PKS is passed transparently from
hop to hop, until it becomes the first subobject in the ERO. This hop to hop, until it becomes the first subobject in the ERO. This
will occur at the start of the CPS which will usually be the will occur at the start of the CPS which will usually be the
domain boundary. The PKS MUST be preceded by an ERO subobject that domain boundary. The PKS MUST be preceded by an ERO subobject that
Bradford, Vasseur, and Farrel [Page 6]
identifies the LSR that must expand the PKS, so the PKS will not identifies the LSR that must expand the PKS, so the PKS will not
be encountered in ERO processing until the LSR that can process be encountered in ERO processing until the LSR that can process
it. it.
An LSR that encounters a PKS when trying to identify the next-hop An LSR that encounters a PKS when trying to identify the next-hop
retrieves the PCE-ID from the PKS and sends a Path Computation retrieves the PCE-ID from the PKS and sends a Path Computation
Request (PCReq) message as defined in [PCEP] to the PCE identified Request (PCReq) message as defined in [PCEP] to the PCE identified
by the PCE-ID that contains the path-key object . by the PCE-ID that contains the path-key object .
Bradford, Vasseur, and Farrel 6
Upon receiving the PCReq message, the PCE identifies the computed Upon receiving the PCReq message, the PCE identifies the computed
path segment using the supplied path-key, and returns the path segment using the supplied path-key, and returns the
previously computed path segment in the form of explicit hops previously computed path segment in the form of explicit hops
using an ERO object contained in the Path Computation Reply using an ERO object contained in the Path Computation Reply
(PCReqp) to the requesting node as defined in [PCEP]. The (PCReqp) to the requesting node as defined in [PCEP]. The
requesting node inserts the explicit hops into the ERO and requesting node inserts the explicit hops into the ERO and
continues to process the TE LSP setup as per [RFC3209]. continues to process the TE LSP setup as per [RFC3209].
4. PCEP Protocol Extensions 2.2. Example
4.1. PATH-KEY Object Figure 1 shows a simple two-AS topology with a PCE responsible
When a PCC needs to expand a path-key in order to expand a CPS it for the path computations in each AS. An LSP is requested from
issues a path computation request (PCReq) to the PCE identified in the the ingress LSR in one AS to the egress LSR in the other AS. The
PKS in the RSVP-TE ERO that it is processing. The PCC supplies the PKS ingress, acting as PCC, sends a path computation request to PCE-
to be expanded in a PATH-KEY Object in the PCReq message. 1. PCE-1 is unable to compute an end-to-end path and invokes PCE-
2 (possibly using the techniques described in [BRPC]). PCE-2
computes a path segment from ASBR-2 to the egress as {ASBR-2, C,
D, Egress}. It could pass this path segment back to PCE-1 in
full, or it could send back the path {ASBR-2, Egress} where the
second hop is a loose hop.
The PATH-KEY Object is defined as follows. However, in order to protect the confidentiality of the topology
in the second AS while still specifying the path in full, PCE-2
may send PCE-1 a path segment expressed as {ASBR-2, PKS, Egress}
where the PKS is a Path Key Subobject as defined in this
document. In this case, PCE-2 has identified the segment {ASBR-2,
C, D, Egress} as a Confidential Path Segment (CPS). PCE-1 will
compute the path segment that it is responsible for, and will
supply the full path to the PCC as {Ingress, A, B, ASBR-1, ASBR-
2, PKS, Egress}.
PATH-KEY Object-Class is to be assigned by IANA (recommended Signaling proceeds in the first AS as normal, but when the Path
value=16) message reaches ASBR-2 the next hop is the PKS, and this must be
expanded before signaling can progress further. ASBR-2 uses the
information in the PKS to request PCE-2 for a path segment, and
PCE-2 will return the segment {ASBR-2, C, D, Egress} allowing
signaling to continue to set up the LSP.
Path Key Object-Type is to be assigned by IANA (recommended value=1) Bradford, Vasseur, and Farrel [Page 7]
----------------------------- ----------------------------
| ------- | | ------- |
| | PCE-1 |<---------------+--+-->| PCE-2 | |
| ------- | | ------- |
| ^ | | ^ |
| | | | | |
| v | | v |
| ------- ---- | | ---- |
| | PCC | - - |ASBR| | | |ASBR| - - ------ |
| |Ingress|--|A|--|B|--| 1 |-+--+-| 2 |--|C|--|D|--|Egress| |
| ------- - - ----- | | ---- - - ------ |
| | | |
----------------------------- ----------------------------
The PATH-KEY Object MUST contain at least one Path Key Subobject Figure 1 : A Simple network to demonstrate the use of the PKS
(see Section 4.2). The first PKS MUST be processed by the PCE.
Subsequent subobjects SHOULD be ignored.
4.2. PKS subobject 3. PCEP Protocol Extensions
The PKS is identical in format to that defined for RSVP-TE 3.1. Path Keys in PCRep Messages
signaling in [RSVP-PKS], but is redefined in the context of this
document since a PCEP codepoint is required. Path Keys are carried in PCReq and PCRep messages as part of the
various objects that carry path definitions. In particular, a Path
Key is carried in the Explicit Route Object (ERO) on PCRep
messages.
In all cases, the Path Key is carried in a Path Key Subobject
(PKS).
The PKS is a fixed-length subobject containing a Path-Key and a The PKS is a fixed-length subobject containing a Path-Key and a
PCE-ID. The Path Key is an identifier, or token used to represent PCE-ID. The Path Key is an identifier, or token used to represent
the CPS within the context of the PCE identified by the PCE-ID. the CPS within the context of the PCE identified by the PCE-ID.
The PCE-ID identifies the PCE that can decode the Path Key using The PCE-ID identifies the PCE that can decode the Path Key using
Bradford, Vasseur, and Farrel 7
an identifier that is unique within the domain that the PCE an identifier that is unique within the domain that the PCE
serves. The PCE-ID has to be mapped to a reachable IPv4 or IPv6 serves. The PCE-ID has to be mapped to a reachable IPv4 or IPv6
address of the PCE by the first node of the CPS (usually a domain address of the PCE by the first node of the CPS (usually a domain
border router) and a PCE MAY use one of its reachable IP addresses border router) and a PCE MAY use one of its reachable IP addresses
as its PCE-ID. Alternatively and to provide greater security (see as its PCE-ID. Alternatively and to provide greater security (see
Section 6), according to domain-local policy, the PCE MAY use some Section 5) or increased confidentiality, according to domain-local
other identifier that is scoped only within the domain. policy, the PCE MAY use some other identifier that is scoped only
within the domain.
To allow IPv4 and IPv6 addresses to be carried, two subobjects are To allow IPv4 and IPv6 addresses to be carried, two subobjects are
defined as follows. defined as follows.
The Path Key Subobject may be present in the PCEP ERO or the PCEP The Path Key Subobject may be present in the PCEP ERO or the PCEP
PATH-KEY object. PATH-KEY object (see Section 3.2).
PKS with 32-bit PCE ID Bradford, Vasseur, and Farrel [Page 8]
3.1.1. PKS with 32-bit PCE ID
The PKS with 32-bit PCE ID Type is to be assigned by IANA The Subobject Type for the PKS with 32-bit PCE ID is to be
(recommended value 64) assigned by IANA (recommended value 64). The format of this
subobject is as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Path Key | |L| Type | Length | Path Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCE ID (4 bytes) | | PCE ID (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L L
The L bit SHOULD NOT be set, so that the subobject The L bit SHOULD NOT be set, so that the subobject
represents a strict hop in the explicit route. represents a strict hop in the explicit route.
Type Type
TBD Path Key with 32-bit PCE ID Subobject Type for a Path Key with 32-bit PCE ID as
assigned by IANA.
Length Length
The Length contains the total length of the subobject in The Length contains the total length of the subobject in
bytes, including the Type and Length fields. The Length bytes, including the Type and Length fields. The Length
is always 8. is always 8.
PCE ID PCE ID
Bradford, Vasseur, and Farrel 8
A 32-bit identifier of the PCE that can decode this key. The A 32-bit identifier of the PCE that can decode this key. The
identifier MUST be unique within the scope of the domain identifier MUST be unique within the scope of the domain
that the CPS crosses, and MUST be understood by the LSR that that the CPS crosses, and MUST be understood by the LSR that
will act as PCC for the expansion of the PKS. The will act as PCC for the expansion of the PKS. The
interpretation of the PCE-ID is subject to domain-local interpretation of the PCE-ID is subject to domain-local
policy. It MAY be an IPv4 address of the PCE that is always policy. It MAY be an IPv4 address of the PCE that is always
reachable, and MAY be an address that is restricted to the reachable, and MAY be an address that is restricted to the
domain in which the LSR that is called upon to expand the domain in which the LSR that is called upon to expand the
CPS lies. Other values that have no meaning outside the CPS lies. Other values that have no meaning outside the
domain (for example, the Router ID) MAY be used to increase domain (for example, the Router ID of the PCE) MAY be used
security (see Section 6). to increase security or confidentiality (see Section 5).
PKS with 128-bit PCE ID Bradford, Vasseur, and Farrel [Page 9]
3.1.2. PKS with 128-bit PCE ID
The PKS with 128-bit PCE ID Type is to be assigned by IANA The Subobject Type for the PKS with 128-bit PCE ID is to be
(recommended value 65) assigned by IANA (recommended value 65). The format of the
subobject is as follows.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Path Key | |L| Type | Length | Path Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCE ID (16 bytes) | | PCE ID (16 bytes) |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L L
As above. As above.
Type Type
TBD Path Key with 128-bit PCE ID Subobject Type for a Path Key with 128-bit PCE ID as
assigned by IANA.
Length Length
The Length contains the total length of the subobject in The Length contains the total length of the subobject in
bytes, including the Type and Length fields. The Length bytes, including the Type and Length fields. The Length
is always 20. is always 20.
PCE ID PCE ID
Bradford, Vasseur, and Farrel 9
A 128-bit identifier of the PCE that can decode this key. A 128-bit identifier of the PCE that can decode this key.
The identifier MUST be unique within the scope of the The identifier MUST be unique within the scope of the
domain that the CPS crosses, and MUST be understood by the domain that the CPS crosses, and MUST be understood by the
LSR that will act as PCC for the expansion of the PKS. The LSR that will act as PCC for the expansion of the PKS. The
interpretation of the PCE-ID is subject to domain-local interpretation of the PCE-ID is subject to domain-local
policy. It MAY be an IPv6 address of the PCE that is policy. It MAY be an IPv6 address of the PCE that is
always reachable, but MAY be an address that is restricted always reachable, but MAY be an address that is restricted
to the domain in which the LSR that is called upon to to the domain in which the LSR that is called upon to
expand the CPS lies. Other values that have no meaning expand the CPS lies. Other values that have no meaning
outside the domain (for example, the IPv6 TE Router ID) outside the domain (for example, the IPv6 TE Router ID)
MAY be used to increase security (see Section 6). MAY be used to increase security (see Section 5).
4.3. Path Key Bit 3.2. Unlocking Path Keys
When a network node needs to decode a Path Key so that it can
continue signaling for an LSP, it must send a PCReq to the
designated PCE. The PCReq defined in [PCEP] needs to be modified
to support this usage which differs from the normal path
computation request. To that end, a new flag is defined to show
that the PCReq relates to the expansion of a PKS, and a new object
is defined to carry the PKS in the PCReq. These result in an
update to the BNF for the message.
3.2.1. Path Key Bit
[PCEP] defines the Request Parameters (RP) object that is used to [PCEP] defines the Request Parameters (RP) object that is used to
specify various characteristics of the path computation request. specify various characteristics of the path computation request
(PCReq).
In this document we define a new bit named the Path Key bit In this document we define a new bit named the Path Key bit as
defined as follow: follows. See Section 7.3 for the IANA assignment of the
appropriate bit number.
Path Key (P-bit - 1 bit - Value=0x80): When set, the requesting Path Key bit: When set, the requesting PCC requires the retrieval
PCC requires the retrieval of a strict path segment that of a Confidential Path Segment that corresponds to the PKS carried
corresponds to a PKS carried in a PATH_KEY object in the path in a PATH_KEY object in the path computation request. The Path Key
computation request. The Path Key bit MUST be cleared when the bit MUST be cleared when the path computation request is not
path computation request is not related to a CPS retrieval. related to a CPS retrieval.
5. PCEP Mode of Operation 3.2.2. PATH-KEY Object
When a PCC needs to expand a path-key in order to expand a CPS it
issues a path computation request (PCReq) to the PCE identified in
the PKS in the RSVP-TE ERO that it is processing. The PCC supplies
the PKS to be expanded in a PATH-KEY Object in the PCReq message.
The PATH-KEY Object is defined as follows.
PATH-KEY Object-Class is to be assigned by IANA (recommended
value=16)
Path Key Object-Type is to be assigned by IANA (recommended
value=1)
The PATH-KEY Object MUST contain at least one Path Key Subobject
(see Section 3.1). The first PKS MUST be processed by the PCE.
Subsequent subobjects SHOULD be ignored.
3.2.3. Path Computation Request (PCReq) message with Path Key
The format of a PCReq message including a PATH-KEY object is
unchanged as follows:
<PCReq Message>::= <Common Header>
[<SVEC-list>]
<request-list>
where:
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]
To support the use of the message to expand a PKS, the definition
of <request> is modified as follows :
<request>::= <RP>
<segment-computation> | <path-key-expansion>
where:
<segment-computation> ::= <END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>]
[<IRO>]
[<LOAD-BALANCING>]
<path-key-expansion> ::= <PATH-KEY>
Thus, the format of the message for use in normal path computation
is unmodified.
4. PCEP Mode of Operation for Path Key Expansion
The retrieval of the explicit path (the CPS) associated with a PKS The retrieval of the explicit path (the CPS) associated with a PKS
by a PCC is no different than any other path computation request by a PCC is no different than any other path computation request
with the exception that the PCReq message MUST contain a PATH_KEY with the exception that the PCReq message MUST contain a PATH_KEY
object and the Path Key bit of the RP object MUST the set. object and the Path Key bit of the RP object MUST the set.
If the receiving PCE does not recognize itself as identified by the If the receiving PCE does not recognize itself as identified by the
PCE ID carried in the PKS it MAY forward the PCReq message to PCE ID carried in the PKS it MAY forward the PCReq message to
another PCE according to local policy. If the PCE does not forward another PCE according to local policy. If the PCE does not forward
such a PCReq, it MUST respond with a PCRep message containing a NO- such a PCReq, it MUST respond with a PCRep message containing a NO-
PATH object. PATH object.
If the receiving PCE recognizes itself, but cannot find the If the receiving PCE recognizes itself, but cannot find the
related CPS, or if the retrieval of the CPS is not allowed by related CPS, or if the retrieval of the CPS is not allowed by
policy, the PCE MUST send a PCRep message that contains a NO-PATH policy, the PCE MUST send a PCRep message that contains a NO-PATH
object. object. The NO-PATH-VECTOR TLV SHOULD be used as described in
[PCEP] and a new bit-number (see Section 7.4) is assigned to
indicate "Cannot expand PKS".
Bradford, Vasseur, and Farrel 10
Upon receipt of a negative reply, the requesting LSR MUST fail the Upon receipt of a negative reply, the requesting LSR MUST fail the
LSP setup and SHOULD use the procedures associated with loose hop LSP setup and SHOULD use the procedures associated with loose hop
expansion failure [RFC3209]. expansion failure [RFC3209].
6. Security Considerations 5. Security Considerations
This document describes tunneling confidential path information This document describes tunneling confidential path information
across an untrusted domain (such as an AS). There are many across an untrusted domain (such as an AS). There are many
security considerations that apply to PCEP and RSVP-TE. security considerations that apply to PCEP and RSVP-TE.
Issues include: Issues include:
- Confidentiality of the CPS (can other network elements probe for - Confidentiality of the CPS (can other network elements probe for
expansion of path-keys, possibly at random?). expansion of path-keys, possibly at random?).
- Authenticity of the path-key (resilience to alteration by - Authenticity of the path-key (resilience to alteration by
intermediaries, resilience to fake expansion of path-keys). intermediaries, resilience to fake expansion of path-keys).
- Resilience from DNS attacks (insertion of spurious path-keys; - Resilience from DNS attacks (insertion of spurious path-keys;
flooding of bogus path-key expansion requests). flooding of bogus path-key expansion requests).
Most of the interactions required by this extension are point to Most of the interactions required by this extension are point to
skipping to change at line 468 skipping to change at page 13, line 31
- Confidentiality of the CPS (can other network elements probe for - Confidentiality of the CPS (can other network elements probe for
expansion of path-keys, possibly at random?). expansion of path-keys, possibly at random?).
- Authenticity of the path-key (resilience to alteration by - Authenticity of the path-key (resilience to alteration by
intermediaries, resilience to fake expansion of path-keys). intermediaries, resilience to fake expansion of path-keys).
- Resilience from DNS attacks (insertion of spurious path-keys; - Resilience from DNS attacks (insertion of spurious path-keys;
flooding of bogus path-key expansion requests). flooding of bogus path-key expansion requests).
Most of the interactions required by this extension are point to Most of the interactions required by this extension are point to
point, can be authenticated and made secure. These interactions point, can be authenticated and made secure as described in [PCEP]
include the: and [RFC3209]. These interactions include the:
- PCC->PCE request - PCC->PCE request
- PCE->PCE request(s) - PCE->PCE request(s)
- PCE->PCE response(s) - PCE->PCE response(s)
- PCE->PCC response - PCE->PCC response
- LSR->LSR request and response (Note that a rogue LSR could - LSR->LSR request and response (Note that a rogue LSR could
modify the ERO and insert or modify Path Keys. This would modify the ERO and insert or modify Path Keys. This would
result in an LSR (which is downstream in the ERO) sending result in an LSR (which is downstream in the ERO) sending
decode requests to a PCE. This is actually a larger problem decode requests to a PCE. This is actually a larger problem
with RSVP. The rogue LSR is an existing issue with RSVP and with RSVP. The rogue LSR is an existing issue with RSVP and
will not be addressed here. will not be addressed here.
skipping to change at line 485 skipping to change at page 14, line 4
modify the ERO and insert or modify Path Keys. This would modify the ERO and insert or modify Path Keys. This would
result in an LSR (which is downstream in the ERO) sending result in an LSR (which is downstream in the ERO) sending
decode requests to a PCE. This is actually a larger problem decode requests to a PCE. This is actually a larger problem
with RSVP. The rogue LSR is an existing issue with RSVP and with RSVP. The rogue LSR is an existing issue with RSVP and
will not be addressed here. will not be addressed here.
- LSR->PCE request. Note that the PCE can check that the LSR - LSR->PCE request. Note that the PCE can check that the LSR
requesting the decode is the LSR at the head of the Path Key. requesting the decode is the LSR at the head of the Path Key.
This largely contains the previous problem to DoS rather than This largely contains the previous problem to DoS rather than
a security issue. A rogue LSR can issue random decode a security issue. A rogue LSR can issue random decode
requests, but these will amount only to DoS. requests, but these will amount only to DoS.
- PCE->LSR response. - PCE->LSR response.
Bradford, Vasseur, and Farrel 11
Thus, the major security issues can be dealt with using standard Thus, the major security issues can be dealt with using standard
techniques for securing and authenticating point-to-point techniques for securing and authenticating point-to-point
communications. In addition, it is recommended that the PCE communications. In addition, it is recommended that the PCE
providing a decode response should check that the LSR that issued providing a decode response should check that the LSR that issued
the decode request is the head end of the decoded ERO segment. the decode request is the head end of the decoded ERO segment.
Further protection can be provided by using a PCE ID to identify the Further protection can be provided by using a PCE ID to identify
decoding PCE that is only meaningful within the domain that contains the decoding PCE that is only meaningful within the domain that
the LSR at the head of the CPS. This may be an IP address that is only contains the LSR at the head of the CPS. This may be an IP address
reachable from within the domain, or some not-address value. The former that is only reachable from within the domain, or some not-address
requires configuration of policy on the PCEs, the latter requires value. The former requires configuration of policy on the PCEs,
domain-wide policy. the latter requires domain-wide policy.
7. Manageability Considerations 6. Manageability Considerations
7.1. Control of Function Through Configuration and Policy 6.1. Control of Function Through Configuration and Policy
The treatment of a path segment as a CPS, and its substitution in The treatment of a path segment as a CPS, and its substitution in
a PCReq ERO with a PKS, is a function that MUST be under operator a PCReq ERO with a PKS, is a function that MUST be under operator
and policy control where a PCE supports the function. The operator and policy control where a PCE supports the function. The operator
MUST be given the ability to specify which path segments are to be MUST be given the ability to specify which path segments are to be
replaced and under what circumstances. For example, an operator replaced and under what circumstances. For example, an operator
might set a policy that states that every path segment for the might set a policy that states that every path segment for the
operator's domain will be replaced by a PKS when the PCReq has operator's domain will be replaced by a PKS when the PCReq has
been issued from outside the domain. been issued from outside the domain.
skipping to change at line 531 skipping to change at page 15, line 4
value to be over-ridden through operator configuration or policy. value to be over-ridden through operator configuration or policy.
After a PKS has been expanded in response to a retrieval request, After a PKS has been expanded in response to a retrieval request,
it may be valuable to retain the path-key and CPS for debug it may be valuable to retain the path-key and CPS for debug
purposes. Such retention SHOULD NOT be the default behavior of an purposes. Such retention SHOULD NOT be the default behavior of an
implementation, but MAY be available in response to operator implementation, but MAY be available in response to operator
request. request.
Once a path-key has been discarded, the path-key value SHOULD not Once a path-key has been discarded, the path-key value SHOULD not
be immediately available for re-use for a new CPS since this might be immediately available for re-use for a new CPS since this might
Bradford, Vasseur, and Farrel 12
lead to accidental misuse. A default timer value is suggested in lead to accidental misuse. A default timer value is suggested in
the body of this document. Implementations SHOULD provide the the body of this document. Implementations SHOULD provide the
ability for this value to be over-ridden through operator ability for this value to be over-ridden through operator
configuration or policy. configuration or policy.
A PCE must set a PCE-ID value in each PKS it creates so that PCCs A PCE must set a PCE-ID value in each PKS it creates so that PCCs
can correctly identify it and send PCReq messages to expand the can correctly identify it and send PCReq messages to expand the
PKS to a path segment. A PCE implementation SHOULD allow operator PKS to a path segment. A PCE implementation SHOULD allow operator
or policy control of the value to use as the PCE-ID. If the PCE or policy control of the value to use as the PCE-ID. If the PCE
allows PCE-ID values that are not routable addresses to be used, allows PCE-ID values that are not routable addresses to be used,
the PCCs MUST be configurable (by the operator or through policy) the PCCs MUST be configurable (by the operator or through policy)
to allow them to map from the PCE-ID to a routable address of the to allow them to map from the PCE-ID to a routable address of the
PCE. Such mapping may be algorithmic, procedural (for example, PCE. Such mapping may be algorithmic, procedural (for example,
mapping a PCE-ID equal to the IGP Router ID into a routable mapping a PCE-ID equal to the IGP Router ID into a routable
address), or configured through a local or remote mapping table. address), or configured through a local or remote mapping table.
7.2. Information and Data Models 6.2. Information and Data Models
A MIB module for PCEP is already defined in [PCEP-MIB]. The A MIB module for PCEP is already defined in [PCEP-MIB]. The
configurable items listed in Section 7.1 MUST be added as readable configurable items listed in Section 6.1 MUST be added as readable
objects in the module and SHOULD be added as writable objects. objects in the module and SHOULD be added as writable objects.
A new MIB module MUST be created to allow inspection of path-keys. A new MIB module MUST be created to allow inspection of path-keys.
For a given PCE, this MIB module MUST provide a mapping from path- For a given PCE, this MIB module MUST provide a mapping from path-
key to path segment (that is, a list of hops), and MUST supply key to path segment (that is, a list of hops), and MUST supply
other information including: other information including:
- The identity of the PCC that issued the original request that - The identity of the PCC that issued the original request that
led to the creation of the path-key. led to the creation of the path-key.
- The request ID of the original PCReq. - The request ID of the original PCReq.
- Whether the path-key has been retrieved yet, and if so, by which - Whether the path-key has been retrieved yet, and if so, by which
PCC. PCC.
- How long until the path segment associated with the path-key - How long until the path segment associated with the path-key
will be discarded. will be discarded.
- How long until the path-key will be available for re-use. - How long until the path-key will be available for re-use.
7.3. Liveness Detection and Monitoring 6.3. Liveness Detection and Monitoring
The procedures in this document extend PCEP, but do not introduce The procedures in this document extend PCEP, but do not introduce
new interactions between network entities. Thus, no new liveness new interactions between network entities. Thus, no new liveness
detection or monitoring is required. detection or monitoring is required.
It is possible that a head-end LSR that has be given a path It is possible that a head-end LSR that has be given a path
including PKSs replacing specific CPSs will want to know whether including PKSs replacing specific CPSs will want to know whether
the path-keys are still valid (or have timed out). However, rather the path-keys are still valid (or have timed out). However, rather
Bradford, Vasseur, and Farrel 13
than introduce a mechanism to poll the PCE that is responsible for than introduce a mechanism to poll the PCE that is responsible for
the PKS, it is considered pragmatic to simply signal the the PKS, it is considered pragmatic to simply signal the
associated LSP. associated LSP.
7.4. Verifying Correct Operation 6.4. Verifying Correct Operation
The procedures in this document extend PCEP, but do not introduce The procedures in this document extend PCEP, but do not introduce
new interactions between network entities. Thus, no new tools for new interactions between network entities. Thus, no new tools for
verifying correct operation are required. verifying correct operation are required.
A PCE SHOULD maintain counters and logs of the following events A PCE SHOULD maintain counters and logs of the following events
that might indicate incorrect operation (or might indicate that might indicate incorrect operation (or might indicate
security issues). security issues).
- Attempts to expand an unknown path-key. - Attempts to expand an unknown path-key.
- Attempts to expand an expired path-key. - Attempts to expand an expired path-key.
- Duplicate attempts to expand the same path-key. - Duplicate attempts to expand the same path-key.
- Expiry of path-key without attempt to expand it. - Expiry of path-key without attempt to expand it.
7.5. Requirements on Other Protocols and Functional Components 6.5. Requirements on Other Protocols and Functional Components
The procedures described in this document require that the LSRs The procedures described in this document require that the LSRs
signal PKSs as defined in [RSVP-PKS]. Note that the only changes signal PKSs as defined in [RSVP-PKS]. Note that the only changes
to LSRs are at the PCCs. Specifically, changes are only needed at to LSRs are at the PCCs. Specifically, changes are only needed at
the head-end LSRs that build RSVP-TE Path messages containing the head-end LSRs that build RSVP-TE Path messages containing
Path-Key Subobjects in their EROs, and the LSRs that discover such Path-Key Subobjects in their EROs, and the LSRs that discover such
subobjects as next hops and must expand them. Other LSRs in the subobjects as next hops and must expand them. Other LSRs in the
network, even if they are on the path of the LSP, will not be network, even if they are on the path of the LSP, will not be
called upon to process the PKS. called upon to process the PKS.
7.6. Impact on Network Operation 6.6. Impact on Network Operation
As well as the security and confidentiality aspects addressed by As well as the security and confidentiality aspects addressed by
the use of the PKS, there may be some scaling benefits associated the use of the PKS, there may be some scaling benefits associated
with the procedures described in this document. For example, a with the procedures described in this document. For example, a
single PKS in an explicit route may substitute for many subobjects single PKS in an explicit route may substitute for many subobjects
and can reduce the overall message size correspondingly. In some and can reduce the overall message size correspondingly. In some
circumstances, such as when the explicit route contains multiple circumstances, such as when the explicit route contains multiple
subobjects for each hop (including node IDs, TE link IDs, subobjects for each hop (including node IDs, TE link IDs,
component link IDs for each direction of a bidirectional LSP, and component link IDs for each direction of a bidirectional LSP, and
label IDs for each direction of a bidirectional LSP) or when the label IDs for each direction of a bidirectional LSP) or when the
LSP is a point-to-multipoint LSP, this scaling improvement may be LSP is a point-to-multipoint LSP, this scaling improvement may be
very significant. very significant.
Bradford, Vasseur, and Farrel 14
Note that a PCE will not supply a PKS unless it is knows that the Note that a PCE will not supply a PKS unless it is knows that the
LSR that will receive the PKS through signaling will be able to LSR that will receive the PKS through signaling will be able to
handle it. Furthermore, as noted in Section 7.5, only those LSRs handle it. Furthermore, as noted in Section 6.5, only those LSRs
specifically called upon to expand the PKS will be required to specifically called upon to expand the PKS will be required to
process the subobjects during signaling. Thus, the only backward process the subobjects during signaling. Thus, the only backward
compatibility issues associated with the procedures introduced in compatibility issues associated with the procedures introduced in
this document arise when a head-end LSR receives a PCRep with an this document arise when a head-end LSR receives a PCRep with an
ERO containing a PKS and does not know how to encode this into ERO containing a PKS and does not know how to encode this into
signaling. signaling.
Since the PCE that inserted the PKS requires to keep the CPS Since the PCE that inserted the PKS requires to keep the CPS
confidential, the legacy head-end LSR cannot be protected. It must confidential, the legacy head-end LSR cannot be protected. It must
either fail the LSP setup, or request a new path computation either fail the LSP setup, or request a new path computation
avoiding the domain that has supplied it with unknown subobjects. avoiding the domain that has supplied it with unknown subobjects.
8. IANA Considerations 7. IANA Considerations
IANA assigns value to PCEP parameters in registries defined in IANA assigns values to PCEP parameters in registries defined in
[PCEP]. IANA is requested to make the following additional [PCEP]. IANA is requested to make the following additional
assignments. assignments.
8.1. New Subobjects for the ERO Object 7.1. New Subobjects for the ERO Object
IANA has previously assigned an Object-Class and Object-Type to IANA has previously assigned an Object-Class and Object-Type to
the ERO carried in PCEP messages [PCEP]. IANA also maintains a the ERO carried in PCEP messages [PCEP]. IANA also maintains a
list of subobject types valid for inclusion in the ERO. list of subobject types valid for inclusion in the ERO.
IANA is requested to assign two new subobject types for inclusion IANA is requested to assign two new subobject types for inclusion
in the ERO as follows: in the ERO as follows:
7 ERO 1 Explicit route [PCEP]
Subobject Type Subobject Type
64 Path Key with 32-bit PCE ID [This.I-D] 64 Path Key with 32-bit PCE ID [This.I-D]
65 Path Key with 128-bit PCE ID [This.I-D] 65 Path Key with 128-bit PCE ID [This.I-D]
8.2. New PCEP Object 7.2. New PCEP Object
IANA is requested to assign a new object class in the registry of IANA is requested to assign a new object class in the registry of
PCEP Objects as follows. PCEP Objects as follows.
Bradford, Vasseur, and Farrel 15
Object Name Object Name Reference Object Name Object Name Reference
Class Type Class Type
16 PATH-KEY 1 Path Key [This.I-D] 16 PATH-KEY 1 Path Key [This.I-D]
Subobjects Subobjects
This object may carry the following subobjects as defined This object may carry the following subobjects as defined
for the ERO object. for the ERO object.
64 Path Key with 32-bit PCE ID [This.I-D] 64 Path Key with 32-bit PCE ID [This.I-D]
65 Path Key with 128-bit PCE ID [This.I-D] 65 Path Key with 128-bit PCE ID [This.I-D]
8.3. New RP Object Bit Flag 7.3. New RP Object Bit Flag
IANA maintains a registry of bit flags carried in the PCEP RP IANA maintains a registry of bit flags carried in the PCEP RP
object as defined in [PCEP]. IANA is requested to define a new bit object as defined in [PCEP]. IANA is requested to assign a new bit
flag as follows: flag as follows:
Bit Hex Name Reference Bit Hex Name Reference
Number Number
09 0x0080 Path Key (P-bit) [This.I-D] 15 0x000100 Path Key (P-bit) [This.I-D]
9. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention 7.4. New NO-PATH-VECTOR TLV Bit Flag
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Bradford, Vasseur, and Farrel 16 IANA maintains a registry of bit flags carried in the PCEP NO-
PATH-VECTOR TLV in the PCEP NO-PATH object as defined in [PCEP].
IANA is requested to assign a new bit flag as follows:
10. References Bits Number Name Flag Reference
1 PKS expansion failure [This.I-D]
10.1. Normative References 8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[PCEP] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E., [PCEP] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E.,
Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation Element Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation Element
(PCE) communication Protocol (PCEP)", draft-ietf-pce-pcep, (PCE) communication Protocol (PCEP)", draft-ietf-pce-pcep,
work in progress. work in progress.
10.2. Informational References 9. Informational References
[RFC3209] Awduche, Berger, Gan, Li, Srinivasan and Swallow, "RSVP-
TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC4655] Farrel, Vasseur & Ash, "A Path Computation Element
(PCE)-Based Architecture", RFC 4655, August 2006.
[RSVP-PKS] Bradford, R., Vasseur, J.P., Farrel, A., "RSVP [RSVP-PKS] Bradford, R., Vasseur, J.P., Farrel, A., "RSVP
Extensions for Path Key Support", draft-bradford-ccamp-path-key- Extensions for Path Key Support", draft-bradford-ccamp-path-key-
ero, work in progress. ero, work in progress.
[RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation
Element (PCE) Architecture", RFC4655, September 2006.
[PD-PATH-COMP] Vasseur, J., et al "A Per-domain path computation [PD-PATH-COMP] Vasseur, J., et al "A Per-domain path computation
method for establishing Inter-domain Traffic Engineering (TE) method for establishing Inter-domain Traffic Engineering (TE)
Label Label Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd-
Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd-path- path-comp, work in progress.
comp, work in progress.
[BRPC] Vasseur, J., et al "A Backward Recursive PCE-based [BRPC] Vasseur, J., et al "A Backward Recursive PCE-based
Computation Computation (BRPC) procedure to compute shortest inter-domain
(BRPC) procedure to compute shortest inter-domain Traffic Traffic Engineering Label Switched Path", draft-ietf-pce-brpc,
Engineering Label Switched Path", draft-ietf-pce-brpc, work in work in progress.
progress.
[RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements [RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements
for Support of Inter-Area and Inter-AS MPLS Traffic Engineering", for Support of Inter-Area and Inter-AS MPLS Traffic Engineering",
RFC 4105, June 2005. RFC 4105, June 2005.
[RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS [RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS
Traffic Engineering requirements", RFC 4216, November 2005. Traffic Engineering requirements", RFC 4216, November 2005.
Bradford, Vasseur, and Farrel 17
[INTER-DOM-REC] Takeda, T., et al, "Analysis of Inter-domain Label [INTER-DOM-REC] Takeda, T., et al, "Analysis of Inter-domain Label
Switched Path (LSP) Recovery", draft-ietf-ccamp-inter-domain- Switched Path (LSP) Recovery", draft-ietf-ccamp-inter-domain-
recovery-analysis, work in progress. recovery-analysis, work in progress.
[PCEP-MIB] Kiran Koushik, A., and Stephan, E., "PCE communication [PCEP-MIB] Kiran Koushik, A., and Stephan, E., "PCE communication
protocol (PCEP) Management Information Base", draft-kkoushik-pce- protocol (PCEP) Management Information Base", draft-kkoushik-pce-
pcep-mib, work in progress. pcep-mib, work in progress.
11. Authors' Addresses: 10. Acknowledgements
The authors would like to thank Eiji Oki for his comments on this
document.
11. Authors' Addresses
Rich Bradford (Editor) Rich Bradford (Editor)
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA - 01719 Boxborough, MA - 01719
USA USA
EMail: rbradfor@cisco.com EMail: rbradfor@cisco.com
J.-P Vasseur J.-P Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA - 01719 Boxborough, MA - 01719
USA USA
EMail: jpv@cisco.com EMail: jpv@cisco.com
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Bradford, Vasseur, and Farrel 18
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at line 828 skipping to change at line 912
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Bradford, Vasseur, and Farrel 19
 End of changes. 92 change blocks. 
231 lines changed or deleted 315 lines changed or added

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