--- 1/draft-ietf-ccamp-path-key-ero-00.txt 2008-05-14 10:12:13.000000000 +0200 +++ 2/draft-ietf-ccamp-path-key-ero-01.txt 2008-05-14 10:12:13.000000000 +0200 @@ -1,19 +1,19 @@ Networking Working Group R. Bradford Internet-Draft JP. Vasseur Intended Status: Standards Track Cisco Systems, Inc. -Created: March 27, 2008 A. Farrel -Expires: September 27, 2008 Old Dog Consulting +Created: May 14, 2008 A. Farrel +Expires: November 14, 2008 Old Dog Consulting RSVP Extensions for Path Key Support - draft-ietf-ccamp-path-key-ero-00.txt + draft-ietf-ccamp-path-key-ero-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering @@ -34,82 +34,131 @@ http://www.ietf.org/shadow.html. 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. To preserve - confidentiality of topology with each AS, the PCE supports a + confidentiality of topology within each AS, the PCE supports a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS), by encoding the contents as a - Path Key Subobject (PKS). This document describes the addition of - this information to Resource Reservation Protocol (RSVP) signaling - by inclusion in the Explicit Route Object (ERO) and Record Route - Object (RRO). + Path Key Subobject (PKS). + + This document describes how to carry Path Key Subobjects in the + Resource Reservation Protocol (RSVP) Explicit Route Objects (EROs) + and Record Route Object (RROs) so facilitate confiedntiality in the + signaling of inter-domain TE LSPs. Conventions used in this document 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]. 1. Introduction Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) are signaled using the TE extensions to the Resource Reservation Protocol (RSVP-TE) [RFC3209], [RFC3473]. The routes followed by MPLS and GMPLS TE LSPs may be computed by Path Computation Elements (PCEs) [RFC4655]. - 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 + Where the TE LSP crosses multiple domains [RFC4726], 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. To preserve confidentiality of topology with each AS, the PCE Communications Protocol (PCEP) [PCEP] supports a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS), by encoding the contents as a Path Key Subobject (PKS) [PCE-PKS]. This document defines RSVP-TE protocol extensions necessary to support the use of Path Key Segments in MPLS and GMPLS signaling. +1.1. Usage Scenario + + Figure 1 shows a simple network constructed of two ASes. An LSP is + desired from the Ingress in Domain-1 to the Egress in Domain-2. As + described in [RFC4655], the Ingress Label Switching Router (LSR) acts + as a Path Computation Client (PCC) and sends a request to its PCE + (PCE-1). PCE-1 can compute the path within Domain-1, but has no + visiblity into Domain-2. So PCE-1 cooperates with PCE-2 to complete + the path computation. + + However, PCE-2 does not want to share the information about the + path across Domain-2 with nodes outside the domain. So, as described + in [PCE-PKS], PCE-2 reports the Domain-2 path segment using a Path + Key Subobject rather than the details of the path. + + PCE-1 can now return the path to be signaled to the Ingress LSR in a + path computation response with the Domain-2 segment still hidden as a + Path Key Segment. + + In order to set up the LSP, the Ingress LSR signals using RSVP-TE and + encodes the path reported by PCE-1 in the Explicit Route Object + (ERO). This process is as normal for RSVP-TE, but requires that the + PKS is also included in the ERO using the mechanisms defined in this + document. + + When the signaling message (the RSVP-TE Path message) reaches ASBR-2 + it consults PCE-2 to 'decode' the PKS. (The information about which + PCE to use to decode the PKS is encoded within the PKS.) The PKS is + replaced in the ERO with the expanded information about the path. + + ----------------------------- ---------------------------- + | Domain-1 | | Domain-2 | + | | | | + | ------- | | ------- | + | | 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 + 2. Terminology 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. 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. PKS: Path Key Subobject. A subobject of an Explicit Route Object which encodes a CPS, so as to preserve confidentiality. 3. RSVP-TE Path Key Subobject The Path Key Subobject (PKS) may be carried in the Explicit Route - Object (ERO) of a RSVP-TE Path message [RFC3209]. 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 a reachable - IPv4 or IPv6 address of the PCE. In most cases, the decoding PCE - is also the PCE that computed the Path Key and the associated - path. Because of the IPv4 and IPv6 variants, two subobjects are - defined as follows. + Object (ERO) of a RSVP-TE Path message [RFC3209]. 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 a reachable IPv4 or IPv6 address + of the PCE. In most cases, the decoding PCE is also the PCE that + computed the Path Key and the associated path. Because of the IPv4 + and IPv6 variants, two subobjects are defined 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 @@ -242,42 +290,46 @@ messages as defined in [PCE-PKS]. Ideally, IANA assignment of the subobject types will be identical. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [PCEP] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E., - Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation - Element (PCE) communication Protocol (PCEP)", - draft-ietf-pce-pcep, work in progress. - -7.2. Informational References - [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3473] Berger, L., et al. "GMPLS Singlaling RSVP-TE extensions", RFC3473, January 2003. +7.2. Informational References + + [PCEP] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E., + Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation + Element (PCE) communication Protocol (PCEP)", + draft-ietf-pce-pcep, work in progress. + [PCE-PKS] Bradford, R., Vasseur, J.P., and Farrel, A., "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Key-Based Mechanism", draft-ietf-pce-path-key, work in progress. [RFC4655] Farrel, A., Vasseur, J.P., and Ash, J., "Path Computation Element (PCE) Architecture", RFC 4655, August 2006. + [RFC4726] Farrel, A., Vasseur, J.P., and Ayyangar, A., "A Framework + for Inter-Domain Multiprotocol Label Switching Traffic + Engineering", RFC 4726, November 2006. + 8. Authors' Addresses: Rich Bradford Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA - 01719 USA Email: rbradfor@cisco.com J.-P Vasseur