draft-ietf-ccamp-path-key-ero-00.txt   draft-ietf-ccamp-path-key-ero-01.txt 
Networking Working Group R. Bradford Networking Working Group R. Bradford
Internet-Draft JP. Vasseur Internet-Draft JP. Vasseur
Intended Status: Standards Track Cisco Systems, Inc. Intended Status: Standards Track Cisco Systems, Inc.
Created: March 27, 2008 A. Farrel Created: May 14, 2008 A. Farrel
Expires: September 27, 2008 Old Dog Consulting Expires: November 14, 2008 Old Dog Consulting
RSVP Extensions for Path Key Support 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 Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is 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 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 becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 45 skipping to change at page 1, line 45
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
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. To preserve 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 mechanism to hide the contents of a segment of a path, called the
Confidential Path Segment (CPS), by encoding the contents as a Confidential Path Segment (CPS), by encoding the contents as a
Path Key Subobject (PKS). This document describes the addition of Path Key Subobject (PKS).
this information to Resource Reservation Protocol (RSVP) signaling
by inclusion in the Explicit Route Object (ERO) and Record Route This document describes how to carry Path Key Subobjects in the
Object (RRO). 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 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. Introduction 1. Introduction
Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
Traffic Engineering (TE) Label Switched Paths (LSPs) are signaled Traffic Engineering (TE) Label Switched Paths (LSPs) are signaled
using the TE extensions to the Resource Reservation Protocol using the TE extensions to the Resource Reservation Protocol
(RSVP-TE) [RFC3209], [RFC3473]. The routes followed by MPLS and (RSVP-TE) [RFC3209], [RFC3473]. The routes followed by MPLS and
GMPLS TE LSPs may be computed by Path Computation Elements (PCEs) GMPLS TE LSPs may be computed by Path Computation Elements (PCEs)
[RFC4655]. [RFC4655].
Where the TE LSP crosses multiple domains, such as Autonomous Where the TE LSP crosses multiple domains [RFC4726], such as
Systems (ASes), the path may be computed by multiple PCEs that Autonomous Systems (ASes), the path may be computed by multiple PCEs
cooperate, with each responsible for computing a segment of the that cooperate, with each responsible for computing a segment of the
path. To preserve confidentiality of topology with each AS, the path. To preserve confidentiality of topology with each AS, the
PCE Communications Protocol (PCEP) [PCEP] supports a mechanism to PCE Communications Protocol (PCEP) [PCEP] supports a mechanism to
hide the contents of a segment of a path, called the Confidential hide the contents of a segment of a path, called the Confidential
Path Segment (CPS), by encoding the contents as a Path Key Path Segment (CPS), by encoding the contents as a Path Key
Subobject (PKS) [PCE-PKS]. Subobject (PKS) [PCE-PKS].
This document defines RSVP-TE protocol extensions necessary to This document defines RSVP-TE protocol extensions necessary to
support the use of Path Key Segments in MPLS and GMPLS signaling. 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 2. Terminology
CPS: Confidential Path Segment. A segment of a path that contains CPS: Confidential Path Segment. A segment of a path that contains
nodes and links that the AS policy requires to not be disclosed nodes and links that the AS policy requires to not be disclosed
outside the AS. outside the AS.
PCE: Path Computation Element: an entity (component, application PCE: Path Computation Element: an entity (component, application
or network node) that is capable of computing a network path or or network node) that is capable of computing a network path or
route based on a network graph and applying computational route based on a network graph and applying computational
constraints. constraints.
PKS: Path Key Subobject. A subobject of an Explicit Route Object PKS: Path Key Subobject. A subobject of an Explicit Route Object
which encodes a CPS, so as to preserve confidentiality. which encodes a CPS, so as to preserve confidentiality.
3. RSVP-TE Path Key Subobject 3. RSVP-TE Path Key Subobject
The Path Key Subobject (PKS) may be carried in the Explicit Route 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 Object (ERO) of a RSVP-TE Path message [RFC3209]. The PKS is a fixed-
fixed-length subobject containing a Path-Key and a PCE-ID. The length subobject containing a Path-Key and a PCE-ID. The Path Key is
Path Key is an identifier, or token used to represent the CPS an identifier, or token used to represent the CPS within the context
within the context of the PCE identified by the PCE-ID. The PCE-ID of the PCE identified by the PCE-ID. The PCE-ID identifies the PCE
identifies the PCE that can decode the Path Key using a reachable that can decode the Path Key using a reachable IPv4 or IPv6 address
IPv4 or IPv6 address of the PCE. In most cases, the decoding PCE of the PCE. In most cases, the decoding PCE is also the PCE that
is also the PCE that computed the Path Key and the associated computed the Path Key and the associated path. Because of the IPv4
path. Because of the IPv4 and IPv6 variants, two subobjects are and IPv6 variants, two subobjects are defined as follows.
defined 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
skipping to change at page 6, line 24 skipping to change at page 7, line 5
messages as defined in [PCE-PKS]. Ideally, IANA assignment of the messages as defined in [PCE-PKS]. Ideally, IANA assignment of the
subobject types will be identical. subobject types will be identical.
7. References 7. References
7.1. Normative References 7.1. 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.,
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. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., et al. "GMPLS Singlaling RSVP-TE extensions", [RFC3473] Berger, L., et al. "GMPLS Singlaling RSVP-TE extensions",
RFC3473, January 2003. 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 [PCE-PKS] Bradford, R., Vasseur, J.P., and Farrel, A., "Preserving
Topology Confidentiality in Inter-Domain Path Computation Topology Confidentiality in Inter-Domain Path Computation
Using a Key-Based Mechanism", draft-ietf-pce-path-key, Using a Key-Based Mechanism", draft-ietf-pce-path-key,
work in progress. work in progress.
[RFC4655] Farrel, A., Vasseur, J.P., and Ash, J., "Path Computation [RFC4655] Farrel, A., Vasseur, J.P., and Ash, J., "Path Computation
Element (PCE) Architecture", RFC 4655, August 2006. 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: 8. Authors' Addresses:
Rich Bradford Rich Bradford
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
 End of changes. 10 change blocks. 
27 lines changed or deleted 80 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/