draft-ietf-pce-path-key-02.txt   draft-ietf-pce-path-key-03.txt 
Networking Working Group Rich Bradford (Ed) Networking Working Group Rich Bradford (Ed)
Internet-Draft JP Vasseur Internet-Draft JP Vasseur
Cisco Systems, Inc. Intended Status: Standards Track Cisco Systems, Inc.
Adrian Farrel Created: May 12, 2008 Adrian Farrel
Old Dog Consulting Expires: November 12, 2008 Old Dog Consulting
Intended Status: Standards Track
Expires: Aug 23, 2008
Feb 23, 2008
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
draft-ietf-pce-path-key-03.txt
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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 10, line ? skipping to change at page 1, line 36
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 August 8, 2008.
Copyright Notice
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
skipping to change at page 10, line ? skipping to change at page 2, line 11
LSP setup as the signaling message enters the second domain, but LSP setup as the signaling message enters the second domain, but
this technique has several issues including the problem of this technique has several issues including the problem of
maintaining path diversity. 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
1. Introduction.................................................3
1.1. Terminology.................................................5
2. Path-Key Solution............................................5
2.1. Mode of Operation...........................................6
2.2. Example.....................................................7
3. PCEP Protocol Extensions.....................................8
3.1. Path Keys in PCRep Messages.................................8
3.1.1. PKS with 32-bit PCE ID....................................9
3.1.2. PKS with 128-bit PCE ID..................................10
3.2. Unlocking Path Keys........................................11
3.2.1. Path Key Bit.............................................11
3.2.2. PATH-KEY Object..........................................11
3.2.3. Path Computation Request (PCReq) message with Path Key...11
4. PCEP Mode of Operation for Path Key Expansion...............12
5. Security Considerations.....................................13
6. Manageability Considerations................................14
Bradford, Vasseur, and Farrel [Page 2]
6.1. Control of Function Through Configuration and Policy.......14
6.2. Information and Data Models................................15
6.3. Liveness Detection and Monitoring..........................15
6.4. Verifying Correct Operation................................16
6.5. Requirements on Other Protocols and Functional Components..16
6.6. Impact on Network Operation................................16
7. IANA Considerations.........................................17
7.1. New Subobjects for the ERO Object..........................17
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].
Table of contents
1. Introduction.................................................3
1.1. Terminology.................................................4
2. Path-Key Solution............................................5
2.1. Mode of Operation...........................................5
2.2. Example.....................................................6
3. PCEP Protocol Extensions.....................................7
3.1. Path Keys in PCRep Messages.................................7
3.1.1. PKS with 32-bit PCE ID....................................8
3.1.2. PKS with 128-bit PCE ID...................................9
3.2. Unlocking Path Keys.........................................9
3.2.1. Path Key Bit.............................................10
3.2.2. PATH-KEY Object..........................................10
3.2.3. Path Computation Request (PCReq) message with Path Key...10
4. PCEP Mode of Operation for Path Key Expansion...............11
5. Security Considerations.....................................12
6. Manageability Considerations................................13
6.1. Control of Function Through Configuration and Policy.......13
6.2. Information and Data Models................................14
6.3. Liveness Detection and Monitoring..........................14
6.4. Verifying Correct Operation................................14
6.5. Requirements on Other Protocols and Functional Components..15
6.6. Impact on Network Operation................................15
7. IANA Considerations.........................................15
7.1. New Subobjects for the ERO Object..........................15
7.2. New PCEP Object............................................16
7.3. New RP Object Bit Flag.....................................16
7.4. New NO-PATH-VECTOR TLV Bit Flag............................16
8. Normative References........................................17
9. Informational References....................................17
10. Acknowledgements...........................................18
11. Authors' Addresses.........................................18
1. Introduction 1. 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 [RFC5152]),
COMP]), and the other using a PCE-based path computation technique and the other using a PCE-based path computation technique with
with cooperation between PCEs (as described in [RFC4655]). In this cooperation between PCEs (as described in [RFC4655]). In this second
case, paths for inter-domain LSPs can be computed by cooperation
Bradford, Vasseur, and Farrel [Page 3] between PCEs each of which computes a segment of the path across one
second case, paths for inter-domain LSPs can be computed by domain. Such a path computation procedure is described in [BRPC].
cooperation between PCEs each of which computes a segment of the
path across one domain. Such a path computation procedure is
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 Autonomous Systems (ASes) belonging to likely be the case between Autonomous Systems (ASes) belonging to
different Service Providers) then cooperating PCEs cannot exchange different Service Providers) then cooperating PCEs cannot exchange
path segments or else the receiving PCE and the Path Computation path segments or else the receiving PCE and the Path Computation
Client (PCC) will be able to see the individual hops through Client (PCC) will be able to see the individual hops through
another domain thus breaking the confidentiality requirement another domain thus breaking the confidentiality requirement
stated in [RFC4105] and [RFC4216]. We define the part of the path stated in [RFC4105] and [RFC4216]. We define the part of the path
which we wish to keep confidential as the Confidential Path which we wish to keep confidential as the Confidential Path
Segment (CPS). Segment (CPS).
skipping to change at page 10, line ? skipping to change at page 4, line 6
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 Area Border Router (ABR) or an AS Border Router boundary (i.e., an Area Border Router (ABR) or an AS Border Router
(ASBR)) and the path is expanded as described in [PD-PATH-COMP]. (ASBR)) and the path is expanded as described in [RFC5152].
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.
skipping to change at page 10, line ? skipping to change at page 5, line 13
constraints. constraints.
TE LSP: Traffic Engineering Label Switched Path TE LSP: Traffic Engineering Label Switched Path
2. Path-Key Solution 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
Bradford, Vasseur, and Farrel [Page 5]
subobjects referred to as PKSes. The entry boundary LSR of each 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 CPS SHOULD be specified using its TE Router Id as a hop in the
returned path immediately preceding the CPS, and other sub-objects returned path immediately preceding the CPS, and other sub-objects
MAY be included in the path immediately before the hop identifying MAY be included in the path immediately before the hop identifying
the boundary LSR to indicate link and label choices. Where two the boundary LSR to indicate link and label choices. Where two
PKSes are supplied in sequence with no intervening nodes, the 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 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 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 node of a CPS MAY be present as a strict hop immediately following
the PKS. the PKS.
skipping to change at page 10, line ? skipping to change at page 6, line 9
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 .
Upon receiving the PCReq message, the PCE identifies the computed Upon receiving the PCReq message, the PCE identifies the computed
skipping to change at page 10, line ? skipping to change at page 7, line 6
supply the full path to the PCC as {Ingress, A, B, ASBR-1, ASBR- supply the full path to the PCC as {Ingress, A, B, ASBR-1, ASBR-
2, PKS, Egress}. 2, PKS, Egress}.
Signaling proceeds in the first AS as normal, but when the Path Signaling proceeds in the first AS as normal, but when the Path
message reaches ASBR-2 the next hop is the PKS, and this must be message reaches ASBR-2 the next hop is the PKS, and this must be
expanded before signaling can progress further. ASBR-2 uses the expanded before signaling can progress further. ASBR-2 uses the
information in the PKS to request PCE-2 for a path segment, and 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 PCE-2 will return the segment {ASBR-2, C, D, Egress} allowing
signaling to continue to set up the LSP. signaling to continue to set up the LSP.
Bradford, Vasseur, and Farrel [Page 7]
----------------------------- ---------------------------- ----------------------------- ----------------------------
| ------- | | ------- | | ------- | | ------- |
| | PCE-1 |<---------------+--+-->| PCE-2 | | | | PCE-1 |<---------------+--+-->| PCE-2 | |
| ------- | | ------- | | ------- | | ------- |
| ^ | | ^ | | ^ | | ^ |
| | | | | | | | | | | |
| v | | v | | v | | v |
| ------- ---- | | ---- | | ------- ---- | | ---- |
| | PCC | - - |ASBR| | | |ASBR| - - ------ | | | PCC | - - |ASBR| | | |ASBR| - - ------ |
| |Ingress|--|A|--|B|--| 1 |-+--+-| 2 |--|C|--|D|--|Egress| | | |Ingress|--|A|--|B|--| 1 |-+--+-| 2 |--|C|--|D|--|Egress| |
skipping to change at page 10, line ? skipping to change at page 8, line 5
Section 5) or increased confidentiality, according to domain-local Section 5) or increased confidentiality, according to domain-local
policy, the PCE MAY use some other identifier that is scoped only policy, the PCE MAY use some other identifier that is scoped only
within the domain. 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 (see Section 3.2). PATH-KEY object (see Section 3.2).
Bradford, Vasseur, and Farrel [Page 8]
3.1.1. PKS with 32-bit PCE ID 3.1.1. PKS with 32-bit PCE ID
The Subobject Type for the PKS with 32-bit PCE ID is to be The Subobject Type for the PKS with 32-bit PCE ID is to be
assigned by IANA (recommended value 64). The format of this assigned by IANA (recommended value 64). The format of this
subobject is as follows: 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
represents a strict hop in the explicit route. strict hop in the explicit route.
Type Type
Subobject Type for a Path Key with 32-bit PCE ID as Subobject Type for a Path Key with 32-bit PCE ID as assigned by
assigned by IANA. IANA.
Length Length
The Length contains the total length of the subobject in The Length contains the total length of the subobject in bytes,
bytes, including the Type and Length fields. The Length including the Type and Length fields. The Length is always 8.
is always 8.
PCE ID PCE ID
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
that the CPS crosses, and MUST be understood by the LSR that the CPS crosses, and MUST be understood by the LSR that will
will act as PCC for the expansion of the PKS. The act as PCC for the expansion of the PKS. The interpretation of
interpretation of the PCE-ID is subject to domain-local the PCE-ID is subject to domain-local policy. It MAY be an IPv4
policy. It MAY be an IPv4 address of the PCE that is always address of the PCE that is always reachable, and MAY be an
reachable, and MAY be an address that is restricted to the address that is restricted to the domain in which the LSR that
domain in which the LSR that is called upon to expand the is called upon to expand the CPS lies. Other values that have
CPS lies. Other values that have no meaning outside the no meaning outside the domain (for example, the Router ID of
domain (for example, the Router ID of the PCE) MAY be used the PCE) MAY be used to increase security or confidentiality
to increase security or confidentiality (see Section 5). (see Section 5).
Bradford, Vasseur, and Farrel [Page 9]
3.1.2. PKS with 128-bit PCE ID 3.1.2. PKS with 128-bit PCE ID
The Subobject Type for the PKS with 128-bit PCE ID is to be The Subobject Type for the PKS with 128-bit PCE ID is to be
assigned by IANA (recommended value 65). The format of the assigned by IANA (recommended value 65). The format of the
subobject is as follows. 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 |
skipping to change at page 10, line ? skipping to change at page 9, line 28
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L L
As above. As above.
Type Type
Subobject Type for a Path Key with 128-bit PCE ID as Subobject Type for a Path Key with 128-bit PCE ID as assigned
assigned by IANA. 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,
bytes, including the Type and Length fields. The Length including the Type and Length fields. The Length is always 20.
is always 20.
PCE ID PCE ID
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
The identifier MUST be unique within the scope of the identifier MUST be unique within the scope of the domain that
domain that the CPS crosses, and MUST be understood by the the CPS crosses, and MUST be understood by the LSR that will
LSR that will act as PCC for the expansion of the PKS. The act as PCC for the expansion of the PKS. The interpretation of
interpretation of the PCE-ID is subject to domain-local the PCE-ID is subject to domain-local policy. It MAY be an IPv6
policy. It MAY be an IPv6 address of the PCE that is address of the PCE that is always reachable, but MAY be an
always reachable, but MAY be an address that is restricted address that is restricted to the domain in which the LSR that
to the domain in which the LSR that is called upon to is called upon to expand the CPS lies. Other values that have
expand the CPS lies. Other values that have no meaning no meaning outside the domain (for example, the IPv6 TE Router
outside the domain (for example, the IPv6 TE Router ID) ID) MAY be used to increase security (see Section 5).
MAY be used to increase security (see Section 5).
3.2. Unlocking Path Keys 3.2. Unlocking Path Keys
When a network node needs to decode a Path Key so that it can 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 continue signaling for an LSP, it must send a PCReq to the
designated PCE. The PCReq defined in [PCEP] needs to be modified designated PCE. The PCReq defined in [PCEP] needs to be modified
to support this usage which differs from the normal path to support this usage which differs from the normal path
computation request. To that end, a new flag is defined to show 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 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 is defined to carry the PKS in the PCReq. These result in an
skipping to change at page 18, line 38 skipping to change at page 17, line 11
Bits Number Name Flag Reference Bits Number Name Flag Reference
1 PKS expansion failure [This.I-D] 1 PKS expansion failure [This.I-D]
8. 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.
[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
(PCE) communication Protocol (PCEP)", draft-ietf-pce-pcep, Element (PCE) communication Protocol (PCEP)", draft-ietf-
work in progress. pce-pcep, work in progress.
9. Informational References 9. Informative 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 [RFC3209] Awduche, Berger, Gan, Li, Srinivasan and Swallow, "RSVP-TE:
(PCE)-Based Architecture", RFC 4655, August 2006. Extensions to RSVP for LSP Tunnels", RFC 3209, December
2001.
[RSVP-PKS] Bradford, R., Vasseur, J.P., Farrel, A., "RSVP [RFC4655] Farrel, Vasseur & Ash, "A Path Computation Element (PCE)-
Extensions for Path Key Support", draft-bradford-ccamp-path-key- Based Architecture", RFC 4655, August 2006.
ero, work in progress.
[PD-PATH-COMP] Vasseur, J., et al "A Per-domain path computation [RSVP-PKS] Bradford, R., Vasseur, J.P., Farrel, A., "RSVP Extensions
method for establishing Inter-domain Traffic Engineering (TE) for Path Key Support", draft-bradford-ccamp-path-key-ero,
Label Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd- work in progress.
path-comp, work in progress.
[RFC5152] Vasseur, J., et al "A Per-Domain Path Computation Method
for Establishing Inter-Domain Traffic Engineering (TE)
Label Switched Paths (LSPs)", RFC 5152, Fenruary 2008.
[BRPC] Vasseur, J., et al "A Backward Recursive PCE-based [BRPC] Vasseur, J., et al "A Backward Recursive PCE-based
Computation (BRPC) procedure to compute shortest inter-domain Computation (BRPC) procedure to compute shortest inter-
Traffic Engineering Label Switched Path", draft-ietf-pce-brpc, domain Traffic Engineering Label Switched Path", draft-
work in progress. ietf-pce-brpc, work in progress.
[RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements [RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for
for Support of Inter-Area and Inter-AS MPLS Traffic Engineering", Support of Inter-Area and Inter-AS MPLS Traffic
RFC 4105, June 2005. Engineering", 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
Traffic Engineering requirements", RFC 4216, November 2005. Engineering requirements", RFC 4216, November 2005.
[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-
recovery-analysis, work in progress. domain-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-
pcep-mib, work in progress. kkoushik-pce-pcep-mib, work in progress.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Eiji Oki for his comments on this The authors would like to thank Eiji Oki for his comments on this
document. document.
11. Authors' Addresses 11. Authors' Addresses
Rich Bradford (Editor) Rich Bradford (Editor)
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 32 change blocks. 
130 lines changed or deleted 105 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/