doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc5520.txt b/doc/rfc/rfc5520.txt
new file mode 100644
index 0000000..041e690
--- /dev/null
+++ b/doc/rfc/rfc5520.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                                   R. Bradford, Ed.
+Request for Comments: 5520                                   JP. Vasseur
+Category: Standards Track                            Cisco Systems, Inc.
+                                                               A. Farrel
+                                                      Old Dog Consulting
+                                                              April 2009
+
+
+                Preserving Topology Confidentiality in
+     Inter-Domain Path Computation Using a Path-Key-Based Mechanism
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Abstract
+
+   Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
+   Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed
+   by Path Computation Elements (PCEs).  Where the TE LSP crosses
+   multiple domains, such as Autonomous Systems (ASes), the path may be
+   computed by multiple PCEs that cooperate, with each responsible for
+   computing a segment of the path.  However, in some cases (e.g., when
+   ASes are administered by separate Service Providers), it would break
+   confidentiality rules for a PCE to supply a path segment to a PCE in
+   another domain, thus disclosing AS-internal topology information.
+   This issue may be circumvented by returning a loose hop and by
+   invoking a new path computation from the domain boundary Label
+   Switching Router (LSR) during TE LSP setup as the signaling message
+   enters the second domain, but this technique has several issues
+   including the problem of maintaining path diversity.
+
+
+
+
+
+Bradford, et al.            Standards Track                     [Page 1]
+
+RFC 5520          Preserving Topology Confidentiality         April 2009
+
+
+   This document defines a mechanism to hide the contents of a 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
+   Communication Protocol (PCEP) and signaled within in a Resource
+   Reservation Protocol TE (RSVP-TE) explicit route object.
+
+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 .......................................10
+           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 ......................................11
+   4. PCEP Mode of Operation for Path-Key Expansion ..................12
+   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 .........................15
+      6.4. Verifying Correct Operation ...............................15
+      6.5. Requirements on Other Protocols and Functional
+           Components ................................................15
+      6.6. Impact on Network Operation ...............................16
+   7. IANA Considerations ............................................16
+      7.1. New Subobjects for the ERO Object .........................16
+      7.2. New PCEP Object ...........................................17
+      7.3. New RP Object Bit Flag ....................................17
+      7.4. New NO-PATH-VECTOR TLV Bit Flag ...........................17
+   8. References .....................................................17
+      8.1. Normative References ......................................17
+      8.2. Informative References ....................................18
+   Acknowledgements ..................................................19
+
+
+
+
+
+
+
+
+
+
+Bradford, et al.            Standards Track                     [Page 2]
+
+RFC 5520          Preserving Topology Confidentiality         April 2009
+
+
+1.  Introduction
+
+   Path computation techniques using the Path Computation Element (PCE)
+   are described in [RFC4655] and allow for path computation of inter-
+   domain Multiprotocol Label Switching (MPLS) Traffic Engineering (TE)
+   and Generalized MPLS (GMPLS) Label Switched Paths (LSPs).
+
+   An important element of inter-domain TE is that TE information is not
+   shared between domains for scalability and confidentiality reasons
+   ([RFC4105] and [RFC4216]).  Therefore, a single PCE is unlikely to be
+   able to compute a full inter-domain path.
+
+   Two path computation scenarios can be used for inter-domain TE LSPs:
+   one using per-domain path computation (defined in [RFC5152]), and the
+   other using a PCE-based path computation technique with cooperation
+   between PCEs (as described in [RFC4655]).  In this second case, paths
+   for inter-domain LSPs can be computed by cooperation between PCEs
+   each of which computes a segment of the path across one domain.  Such
+   a path computation procedure is described in [RFC5441].
+
+   If confidentiality is required between domains (such as would very
+   likely be the case between Autonomous Systems (ASes) belonging to
+   different Service Providers), then cooperating PCEs cannot exchange
+   path segments or else the receiving PCE and the Path Computation
+   Client (PCC) will be able to see the individual hops through another
+   domain thus breaking the confidentiality requirement stated in
+   [RFC4105] and [RFC4216].  We define the part of the path that we wish
+   to keep confidential as the Confidential Path Segment (CPS).
+
+   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
+   segment that must be kept confidential.  The concept of loose and
+   strict hops for the route of a TE LSP is described in [RFC3209].  The
+   Path Computation Element Communication Protocol (PCEP) defined in
+   [RFC5440] supports the use of paths with loose hops, and it is a
+   local policy decision at a PCE whether it returns a full explicit
+   path with strict hops or uses loose hops.  Note that a path
+   computation request may request an explicit path with strict hops or
+   may allow loose hops as detailed in [RFC5440].
+
+   The option of returning a loose hop in place of the CPS can be
+   achieved without further extensions to PCEP or the signaling
+   protocol.  If loose hops are used, the TE LSPs are signaled as normal
+   ([RFC3209]), and when a loose hop is encountered in the explicit
+   route, it is resolved by performing a secondary path computation to
+   reach the resource or set of resources identified by the loose hop.
+   Given the nature of the cooperation between PCEs in computing the
+   original path, this secondary computation occurs at or on behalf of a
+
+
+
+Bradford, et al.            Standards Track                     [Page 3]
+
+RFC 5520          Preserving Topology Confidentiality         April 2009
+
+
+   Label Switching Router (LSR) at a domain boundary (i.e., an Area
+   Border Router (ABR) or an AS Border Router (ASBR)) and the path is
+   expanded as described in [RFC5152].
+
+   The PCE-based computation model is particularly useful for
+   determining mutually disjoint inter-domain paths such as might be
+   required for service protection [RFC5298].  A single path computation
+   request is used.  However, if loose hops are returned, the path of
+   each TE LSP must be recomputed at the domain boundaries as the TE
+   LSPs are signaled, and since the TE LSP signaling proceeds
+   independently for each TE LSP, disjoint paths cannot be guaranteed
+   since the LSRs in charge of expanding the explicit route objects
+   (EROs) are not synchronized.  Therefore, if the loose hop technique
+   is used without further extensions, path segment confidentiality and
+   path diversity are mutually incompatible requirements.
+
+   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
+   encoded as a Path-Key Subobject (PKS) returned in the PCEP Path
+   Computation Reply message (PCRep) ([RFC5440]).  Upon receiving the
+   computed path, the PKS will be carried in an RSVP-TE Path message
+   (RSVP-TE [RFC3209] and [RSVP-PKS]) during signaling.
+
+   The BNF in this document follows the format described in [RBNF].
+
+   Please note that the term "path-key" used in this document refers to
+   an identifier allocated by a PCE to represent a segment of a computed
+   path.  This term has no relation to the term "cryptographic key" used
+   in some documents that describe security mechanisms.
+
+1.1.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+   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.
+
+
+
+
+Bradford, et al.            Standards Track                     [Page 4]
+
+RFC 5520          Preserving Topology Confidentiality         April 2009
+
+
+   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
+   computation context as follows.  A PCE computes a path segment
+   related to a particular domain and replaces any CPS in the path
+   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 using its TE Router Id as a hop in the returned
+   path immediately preceding the CPS, and other subobjects 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.
+
+2.1.  Mode of Operation
+
+   During path computation, when local policy dictates that
+   confidentiality must be preserved for all or part of the path segment
+   being computed or if explicitly requested by the path computation
+   request, the PCE associates a path-key with the computed path for the
+   CPS, places its own identifier (its PCE ID 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 or PCE immediately after the
+   subobject that identifies (using the TE Router Id) the LSR that will
+   expand the PKS into explicit path hops.  This will usually be the LSR
+   that is the starting point of the CPS.  The PCE that generates a PKS
+   SHOULD store the computed path segment and the path-key for later
+   retrieval.  A local policy SHOULD be used to determine for how long
+   to retain such stored
+
+
+
+
+
+Bradford, et al.            Standards Track                     [Page 5]
+
+RFC 5520          Preserving Topology Confidentiality         April 2009
+
+
+   information, and whether to discard the information after it has been
+   queried using the procedures described below.  It is RECOMMENDED for
+   a PCE to store the PKS for a period of 10 minutes.
+
+   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 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 is unable to
+   retain information about previously used path-key values over a
+   restart SHOULD use some other mechanism to guarantee uniqueness of
+   path-key values such as embedding a timestamp or version number in
+   the path-key.
+
+   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 Resource
+   Reservation Protocol (RSVP) Path message.  If the path returned by
+   the PCE contains a PKS, this is included in the ERO.  Like any other
+   subobjects, the PKS is passed transparently from 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 domain boundary.  The PKS MUST
+   be preceded by an ERO subobject that identifies the LSR that must
+   expand the PKS.  This means that (following the rules for ERO
+   processing set out in [RFC3209]) the PKS will not be encountered in
+   ERO processing until the ERO is being processed by the LSR that is
+   capable of correctly handling the PKS.
+
+   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
+   Request (PCReq) message as defined in [RFC5440] to the PCE identified
+   by the PCE-ID that contains the path-key object .
+
+   Upon receiving the PCReq message, the PCE identifies the computed
+   path segment using the supplied path-key, and returns the previously
+   computed path segment in the form of explicit hops using an ERO
+   object contained in the Path Computation Reply (PCRep) to the
+   requesting node as defined in [RFC5440].  The requesting node inserts
+   the explicit hops into the ERO and continues to process the TE LSP
+   setup as per [RFC3209].
+
+2.2.  Example
+
+   Figure 1 shows a simple two-AS topology with a PCE responsible for
+   the path computations in each AS.  An LSP is requested from the
+   ingress LSR in one AS to the egress LSR in the other AS.  The
+   ingress, acting as the PCC, sends a path computation request to
+   PCE-1.  PCE-1 is unable to compute an end-to-end path and invokes
+   PCE-2 (possibly using the techniques described in [RFC5441]).  PCE-2
+   computes a path segment from ASBR-2 to the egress as {ASBR-2, C, D,
+
+
+
+Bradford, et al.            Standards Track                     [Page 6]
+
+RFC 5520          Preserving Topology Confidentiality         April 2009
+
+
+   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.
+
+   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}.
+
+   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
+   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.
+
+       -----------------------------    ----------------------------
+      |     -------                 |  |    -------                 |
+      |    | PCE-1 |<---------------+--+-->| PCE-2 |                |
+      |     -------                 |  |    -------                 |
+      |      ^                      |  |    ^                       |
+      |      |                      |  |    |                       |
+      |      v                      |  |    v                       |
+      |  -------              ----  |  |  ----                      |
+      | |  PCC  |   -    -   |ASBR| |  | |ASBR|   -    -    ------  |
+      | |Ingress|--|A|--|B|--|  1 |-+--+-|  2 |--|C|--|D|--|Egress| |
+      |  -------    -    -    ----- |  |  ----    -    -    ------  |
+      |                             |  |                            |
+       -----------------------------    ----------------------------
+
+        Figure 1 : A Simple network to demonstrate the use of the PKS
+
+3.  PCEP Protocol Extensions
+
+3.1.  Path-Keys in PCRep Messages
+
+   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).
+
+
+
+
+
+
+Bradford, et al.            Standards Track                     [Page 7]
+
+RFC 5520          Preserving Topology Confidentiality         April 2009
+
+
+   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
+   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 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 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 as its PCE-ID.
+   Alternatively and to provide greater security (see Section 5) or
+   increased confidentiality, according to domain-local 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
+   defined in the following subsections.
+
+   The Path-Key Subobject may be present in the PCEP ERO or the PCEP
+   PATH-KEY object (see Section 3.2).
+
+3.1.1.  PKS with 32-Bit PCE ID
+
+   The Subobject Type for the PKS with 32-bit PCE ID is 64.  The format
+   of this subobject is as follows:
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |L|    Type     |     Length    |           Path-Key            |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                         PCE ID (4 bytes)                      |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      L
+
+         The L bit SHOULD NOT be set, so that the subobject represents a
+         strict hop in the explicit route.
+
+      Type
+
+         Subobject Type for a Path-Key with 32-bit PCE ID (64).
+
+      Length
+
+         The Length contains the total length of the subobject in bytes,
+         including the Type and Length fields.  The Length is always 8.
+
+
+
+
+
+
+
+Bradford, et al.            Standards Track                     [Page 8]
+
+RFC 5520          Preserving Topology Confidentiality         April 2009
+
+
+      PCE ID
+
+         A 32-bit identifier of the PCE that can decode this path-key.
+         The identifier MUST be unique within the scope of 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
+         interpretation of the PCE-ID is subject to domain-local policy.
+         It MAY be an IPv4 address of the PCE that is always reachable,
+         and MAY be an address that is restricted to the domain in which
+         the LSR that is called upon to expand the CPS lies.  Other
+         values that have no meaning outside the domain (for example,
+         the Router ID of the PCE) MAY be used to increase security or
+         confidentiality (see Section 5).
+
+3.1.2.  PKS with 128-Bit PCE ID
+
+   The Subobject Type for the PKS with 128-bit PCE ID is 65.  The format
+   of the subobject is as follows.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |L|    Type     |     Length    |           Path-Key            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        PCE ID (16 bytes)                      |
+   |                                                               |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      L
+
+         As above.
+
+      Type
+
+         Subobject Type for a Path-Key with 128-bit PCE ID (65).
+
+      Length
+
+         The Length contains the total length of the subobject in bytes,
+         including the Type and Length fields.  The Length is always 20.
+
+      PCE ID
+
+         A 128-bit identifier of the PCE that can decode this path-key.
+         The identifier MUST be unique within the scope of the domain
+         that the CPS crosses, and MUST be understood by the LSR that
+
+
+
+Bradford, et al.            Standards Track                     [Page 9]
+
+RFC 5520          Preserving Topology Confidentiality         April 2009
+
+
+         will act as PCC for the expansion of the PKS.  The
+         interpretation of the PCE-ID is subject to domain-local policy.
+         It MAY be an IPv6 address of the PCE that is always reachable,
+         but MAY be an address that is restricted to the domain in which
+         the LSR that is called upon to expand the CPS lies.  Other
+         values that have no meaning outside the domain (for example,
+         the IPv6 TE Router ID) MAY be used to increase security (see
+         Section 5).
+
+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 [RFC5440] 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.
+   The BNF used in this document is as described in [RBNF].
+
+3.2.1.  Path-Key Bit
+
+   [RFC5440] defines the Request Parameters (RP) object that is used to
+   specify various characteristics of the Path Computation Request
+   (PCReq).
+
+   In this document, we define a new bit named the Path-Key bit as
+   follows.  See Section 7.3 for the IANA assignment of the appropriate
+   bit number.
+
+   Path-Key bit: When set, the requesting PCC requires the retrieval of
+   a Confidential Path Segment that corresponds to the PKS carried in a
+   PATH-KEY object in the path computation request.  The Path-Key bit
+   MUST be cleared when the path computation request is not related to a
+   CPS retrieval.
+
+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.
+
+
+
+
+
+
+
+
+
+Bradford, et al.            Standards Track                    [Page 10]
+
+RFC 5520          Preserving Topology Confidentiality         April 2009
+
+
+   The PATH-KEY Object is defined as follows:
+
+   PATH-KEY Object-Class is 16.
+
+   Path-Key Object-Type is 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.
+
+
+
+
+
+
+
+
+
+Bradford, et al.            Standards Track                    [Page 11]
+
+RFC 5520          Preserving Topology Confidentiality         April 2009
+
+
+4.  PCEP Mode of Operation for Path-Key Expansion
+
+   The retrieval of the explicit path (the CPS) associated with a PKS by
+   a PCC is no different than any other path computation request with
+   the exception that the PCReq message MUST contain a PATH-KEY object
+   and the Path-Key bit of the RP object MUST be set.  On receipt of a
+   PCRep containing a CPS, the requesting PCC SHOULD insert the CPS into
+   the ERO that it will signal, in accordance with local policy.
+
+   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
+   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-PATH object.
+
+   If the receiving PCE recognizes itself, but cannot find the 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 object.  The
+   NO-PATH-VECTOR TLV SHOULD be used as described in [RFC5440] and a new
+   bit number (see Section 7.4) is assigned to indicate "Cannot expand
+   PKS".
+
+   Upon receipt of a negative reply, the requesting LSR MUST fail the
+   LSP setup and SHOULD use the procedures associated with loose hop
+   expansion failure [RFC3209].
+
+5.  Security Considerations
+
+   This document describes tunneling confidential path information
+   across an untrusted domain (such as an AS).  There are many security
+   considerations that apply to PCEP and RSVP-TE.
+
+   Issues include:
+
+   - Confidentiality of the CPS (can other network elements probe for
+     expansion of path-keys, possibly at random?).
+
+   - Authenticity of the path-key (resilience to alteration by
+     intermediaries, resilience to fake expansion of path-keys).
+
+   - Resilience from Denial-of-Service (DoS) attacks (insertion of
+     spurious path-keys; flooding of bogus path-key expansion requests).
+
+   Most of the interactions required by this extension are point to
+   point, can be authenticated and made secure as described in [RFC5440]
+   and [RFC3209].  These interactions include the:
+
+
+
+
+
+Bradford, et al.            Standards Track                    [Page 12]
+
+RFC 5520          Preserving Topology Confidentiality         April 2009
+
+
+       - PCC->PCE request
+
+       - PCE->PCE request(s)
+
+       - PCE->PCE response(s)
+
+       - PCE->PCC response
+
+       - LSR->LSR request and response.  Note that a rogue LSR could
+         modify the ERO and insert or modify Path-Keys.  This would
+         result in an LSR (which is downstream in the ERO) sending
+         decode requests to a PCE.  This is actually a larger problem
+         with RSVP.  The rogue LSR is an existing issue with RSVP and
+         will not be addressed here.
+
+       - 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.
+         This largely contains the previous problem of DoS rather than a
+         security issue.  A rogue LSR can issue random decode requests,
+         but these will amount only to DoS.
+
+       - PCE->LSR response
+
+   Thus, the major security issues can be dealt with using standard
+   techniques for securing and authenticating point-to-point
+   communications.  In addition, it is recommended that the PCE
+   providing a decode response should check that the LSR that issued 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
+   decoding PCE that is only meaningful within the domain that contains
+   the LSR at the head of the CPS.  This may be an IP address that is
+   only reachable from within the domain, or some not-address value.
+   The former requires configuration of policy on the PCEs, the latter
+   requires domain-wide policy.
+
+6.  Manageability Considerations
+
+6.1.  Control of Function through Configuration and Policy
+
+   The treatment of a path segment as a CPS, and its substitution in a
+   PCRep ERO with a PKS, is a function that MUST be under 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
+   replaced and under what circumstances.  For example, an operator
+   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 been
+   issued from outside the domain.
+
+
+
+Bradford, et al.            Standards Track                    [Page 13]
+
+RFC 5520          Preserving Topology Confidentiality         April 2009
+
+
+   The operation of the PKS extensions require that path-keys are
+   retained by the issuing PCE to be available for retrieval by an LSR
+   (acting as a PCC) at a later date.  But it is possible that the
+   retrieval request will never be made, so good housekeeping requires
+   that a timer is run to discard unwanted path-keys.  A default value
+   for this timer is suggested in Section 2.1.  Implementations SHOULD
+   provide the ability for this value to be overridden through operator
+   configuration or policy.
+
+   After a PKS has been expanded in response to a retrieval request, it
+   may be valuable to retain the path-key and CPS for debugging
+   purposes.  Such retention SHOULD NOT be the default behavior of an
+   implementation, but MAY be available in response to operator request.
+
+   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 lead
+   to accidental misuse.  A default timer value is suggested in Section
+   2.1.  Implementations SHOULD provide the ability for this value to be
+   overridden through operator configuration or policy.
+
+   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 PKS to a
+   path segment.  A PCE implementation SHOULD allow operator or policy
+   control of the value to be used as the PCE-ID.  If the PCE allows
+   PCE-ID values that are not routable addresses to be used, the PCCs
+   MUST be configurable (by the operator or through policy) to allow the
+   PCCs to map from the PCE-ID to a routable address of the PCE.  Such
+   mapping may be algorithmic, procedural (for example, mapping a PCE-ID
+   equal to the IGP Router ID into a routable address), or configured
+   through a local or remote mapping table.
+
+6.2.  Information and Data Models
+
+   A MIB module for PCEP is already defined in [PCEP-MIB].  The
+   configurable items listed in Section 6.1 MUST be added as readable
+   objects in the module and SHOULD be added as writable objects.
+
+   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-
+   key to path segment (that is, a list of hops), and MUST supply other
+   information including:
+
+   - The identity of the PCC that issued the original request that led
+     to the creation of the path-key.
+
+   - The request ID of the original PCReq.
+
+
+
+
+
+Bradford, et al.            Standards Track                    [Page 14]
+
+RFC 5520          Preserving Topology Confidentiality         April 2009
+
+
+   - Whether the path-key has been retrieved yet, and if so, by which
+     PCC.
+
+   - How long until the path segment associated with the path-key will
+     be discarded.
+
+   - How long until the path-key will be available for re-use.
+
+6.3.  Liveness Detection and Monitoring
+
+   The procedures in this document extend PCEP, but do not introduce new
+   interactions between network entities.  Thus, no new liveness
+   detection or monitoring is required.
+
+   It is possible that a head-end LSR that has be given a path including
+   PKSs replacing specific CPSs will want to know whether the path-keys
+   are still valid (or have timed out).  However, rather than introduce
+   a mechanism to poll the PCE that is responsible for the PKS, it is
+   considered pragmatic to simply signal the associated LSP.
+
+6.4.  Verifying Correct Operation
+
+   The procedures in this document extend PCEP, but do not introduce new
+   interactions between network entities.  Thus, no new tools for
+   verifying correct operation are required.
+
+   A PCE SHOULD maintain counters and logs of the following events that
+   might indicate incorrect operation (or might indicate security
+   issues).
+
+   - Attempts to expand an unknown path-key.
+
+   - Attempts to expand an expired path-key.
+
+   - Duplicate attempts to expand the same path-key.
+
+   - Expiry of path-key without attempt to expand it.
+
+6.5.  Requirements on Other Protocols and Functional Components
+
+   The procedures described in this document require that the LSRs
+   signal PKSs as defined in [RSVP-PKS].  Note that the only changes to
+   LSRs are at the PCCs.  Specifically, changes are only needed at the
+   head-end LSRs that build RSVP-TE Path messages containing Path-Key
+   Subobjects in their EROs, and the LSRs that discover such 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 called upon to
+   process the PKS.
+
+
+
+Bradford, et al.            Standards Track                    [Page 15]
+
+RFC 5520          Preserving Topology Confidentiality         April 2009
+
+
+6.6.  Impact on Network Operation
+
+   As well as the security and confidentiality aspects addressed by the
+   use of the PKS, there may be some scaling benefits associated with
+   the procedures described in this document.  For example, a single PKS
+   in an explicit route may substitute for many subobjects and can
+   reduce the overall message size correspondingly.  In some
+   circumstances, such as when the explicit route contains multiple
+   subobjects for each hop (including node IDs, TE link IDs, component
+   link IDs for each direction of a bidirectional LSP, and label IDs for
+   each direction of a bidirectional LSP) or when the LSP is a point-
+   to-multipoint LSP, this scaling improvement may be very significant.
+
+   Note that a PCE will not supply a PKS unless it knows that the LSR
+   that will receive the PKS through signaling will be able to handle
+   it.  Furthermore, as noted in Section 6.5, only those LSRs
+   specifically called upon to expand the PKS will be required to
+   process the subobjects during signaling.  Thus, the only backward
+   compatibility issues associated with the procedures introduced in
+   this document arise when a head-end LSR receives a PCRep with an ERO
+   containing a PKS, and it does not know how to encode this into
+   signaling.
+
+   Since the PCE that inserted the PKS is required to keep the CPS
+   confidential, the legacy head-end LSR cannot be protected.  It must
+   either fail the LSP setup, or request a new path computation avoiding
+   the domain that has supplied it with unknown subobjects.
+
+7.  IANA Considerations
+
+   IANA assigns values to PCEP parameters in registries defined in
+   [RFC5440].  IANA has made the following additional assignments.
+
+7.1.  New Subobjects for the ERO Object
+
+   IANA has previously assigned an Object-Class and Object-Type to the
+   ERO carried in PCEP messages [RFC5440].  IANA also maintains a list
+   of subobject types valid for inclusion in the ERO.
+
+   IANA assigned two new subobject types for inclusion in the ERO as
+   follows:
+
+   Subobject Type                                         Reference
+             64   Path-Key with 32-bit PCE ID             [RFC5520]
+             65   Path-Key with 128-bit PCE ID            [RFC5520]
+
+
+
+
+
+
+Bradford, et al.            Standards Track                    [Page 16]
+
+RFC 5520          Preserving Topology Confidentiality         April 2009
+
+
+7.2.  New PCEP Object
+
+   IANA assigned a new object class in the registry of PCEP Objects as
+   follows.
+
+   Object  Name          Object  Name                     Reference
+   Class                 Type
+
+   16    PATH-KEY        1       Path-Key                 [RFC5520]
+
+       Subobjects
+          This object may carry the following subobjects as defined
+          for the ERO object.
+
+                  64   Path-Key with 32-bit PCE ID        [RFC5520]
+                  65   Path-Key with 128-bit PCE ID       [RFC5520]
+
+7.3.  New RP Object Bit Flag
+
+   IANA maintains a registry of bit flags carried in the PCEP RP object
+   as defined in [RFC5440].  IANA assigned a new bit flag as follows:
+
+   Bit Number  Hex       Name                             Reference
+   23          0x000017  Path-Key (P-bit)                 [RFC5520]
+
+7.4.  New NO-PATH-VECTOR TLV Bit Flag
+
+   IANA maintains a registry of bit flags carried in the PCEP NO-PATH-
+   VECTOR TLV in the PCEP NO-PATH object as defined in [RFC5440].  IANA
+   assigned a new bit flag as follows:
+
+   Bit Number      Name Flag                    Reference
+   27              PKS expansion failure        [RFC5520]
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC5440]  Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation
+              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
+              March 2009.
+
+
+
+
+
+
+
+Bradford, et al.            Standards Track                    [Page 17]
+
+RFC 5520          Preserving Topology Confidentiality         April 2009
+
+
+8.2.  Informative References
+
+   [PCEP-MIB] Koushik, K., and E. Stephan, "PCE Communication Protocol
+              (PCEP) Management Information Base", Work in Progress,
+              November 2008.
+
+   [RBNF]     Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used
+              in Various Protocol Specifications", Work in Progress,
+              November 2008.
+
+   [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.
+
+   [RFC4105]  Le Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J. Boyle,
+              Ed., "Requirements for Inter-Area MPLS Traffic
+              Engineering", RFC 4105, June 2005.
+
+   [RFC4216]  Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-
+              Autonomous System (AS) Traffic Engineering (TE)
+              Requirements", RFC 4216, November 2005.
+
+   [RFC4655]  Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
+              Computation Element (PCE)-Based Architecture", RFC 4655,
+              August 2006.
+
+   [RFC5152]  Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
+              Per-Domain Path Computation Method for Establishing
+              Inter-Domain Traffic Engineering (TE) Label Switched Paths
+              (LSPs)", RFC 5152, February 2008.
+
+   [RFC5298]  Takeda, T., Ed., Farrel, A., Ed., Ikejiri, Y., and JP.
+              Vasseur, "Analysis of Inter-Domain Label Switched Path
+              (LSP) Recovery", RFC 5298, August 2008.
+
+   [RFC5441]  Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
+              "A Backward-Recursive PCE-Based Computation (BRPC)
+              Procedure to Compute Shortest Constrained Inter-Domain
+              Traffic Engineering Label Switched Paths", RFC 5441, April
+              2009.
+
+   [RSVP-PKS] Bradford, R., Vasseur, JP., and A. Farrel, "RSVP
+              Extensions for Path Key Support", Work in Progress,
+              February 2008.
+
+
+
+
+
+
+
+Bradford, et al.            Standards Track                    [Page 18]
+
+RFC 5520          Preserving Topology Confidentiality         April 2009
+
+
+Acknowledgements
+
+   The authors would like to thank Eiji Oki, Ben Campbell, and Ross
+   Callon for their comments on this document.
+
+Authors' Addresses
+
+   Rich Bradford (Editor)
+   Cisco Systems, Inc.
+   1414 Massachusetts Avenue
+   Boxborough, MA 01719
+   USA
+   EMail: rbradfor@cisco.com
+
+   JP. Vasseur
+   Cisco Systems, Inc.
+   1414 Massachusetts Avenue
+   Boxborough, MA 01719
+   USA
+   EMail: jpv@cisco.com
+
+   Adrian Farrel
+   Old Dog Consulting
+   EMail: adrian@olddog.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bradford, et al.            Standards Track                    [Page 19]
+