draft-ietf-pce-path-key-04.txt   draft-ietf-pce-path-key-05.txt 
Networking Working Group Rich Bradford (Ed) Networking Working Group Rich Bradford (Ed)
Internet-Draft JP Vasseur Internet-Draft JP Vasseur
Intended Status: Standards Track Cisco Systems, Inc. Intended Status: Standards Track Cisco Systems, Inc.
Created: November 17, 2008 Adrian Farrel Created: November 17, 2008 Adrian Farrel
Expires: May 17, 2009 Old Dog Consulting Expires: May 17, 2009 Old Dog Consulting
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-04.txt draft-ietf-pce-path-key-05.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and 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 4, line 27 skipping to change at page 4, line 27
extensions, path segment confidentiality and path diversity are extensions, path segment confidentiality and path diversity are
mutually incompatible requirements. 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.
The BNF in this document follows the format described in [RBNF].
1.1. Terminology 1.1. Terminology
This document makes use of the following terminology and acronyms. This document makes use of the following terminology and acronyms.
AS: Autonomous System. AS: Autonomous System.
ASBR: Autonomous System Border Routers used to connect to another ASBR: Autonomous System Border Routers used to connect to another
AS of a different or the same Service Provider via one or more AS of a different or the same Service Provider via one or more
links inter-connecting between ASes. links inter-connecting between ASes.
skipping to change at page 7, line 50 skipping to change at page 8, line 6
an identifier that is unique within the domain that the PCE an identifier that is unique within the domain that the PCE
serves. The PCE-ID has to be mapped to a reachable IPv4 or IPv6 serves. The PCE-ID has to be mapped to a reachable IPv4 or IPv6
address of the PCE by the first node of the CPS (usually a domain address of the PCE by the first node of the CPS (usually a domain
border router) and a PCE MAY use one of its reachable IP addresses border router) and a PCE MAY use one of its reachable IP addresses
as its PCE-ID. Alternatively and to provide greater security (see as its PCE-ID. Alternatively and to provide greater security (see
Section 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 in the following subsections.
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).
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:
skipping to change at page 10, line 7 skipping to change at page 10, line 7
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
update to the BNF for the message. update to the BNF for the message. The BNF used in this document is
as described in [RBNF].
3.2.1. Path Key Bit 3.2.1. Path Key Bit
[PCEP] defines the Request Parameters (RP) object that is used to [PCEP] defines the Request Parameters (RP) object that is used to
specify various characteristics of the path computation request specify various characteristics of the path computation request
(PCReq). (PCReq).
In this document we define a new bit named the Path Key bit as 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 follows. See Section 7.3 for the IANA assignment of the
appropriate bit number. appropriate bit number.
skipping to change at page 18, line 5 skipping to change at page 17, line 51
[RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic [RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic
Engineering requirements", RFC 4216, November 2005. Engineering requirements", RFC 4216, November 2005.
[RFC5298] Takeda, T., et al, "Analysis of Inter-domain Label [RFC5298] Takeda, T., et al, "Analysis of Inter-domain Label
Switched Path (LSP) Recovery", RFC 5298, August 2008. Switched Path (LSP) Recovery", RFC 5298, August 2008.
[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- protocol (PCEP) Management Information Base", draft-
kkoushik-pce-pcep-mib, work in progress. kkoushik-pce-pcep-mib, work in progress.
[RBNF] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used
in Various Protocol Specifications", draft-farrel-rtg-
common-bnf, 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, Ben Campbell, and Ross
document. Callon for their comments on this document.
11. Authors' Addresses 11. Authors' Addresses
Rich Bradford (Editor) Rich Bradford (Editor)
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA - 01719 Boxborough, MA - 01719
USA USA
EMail: rbradfor@cisco.com EMail: rbradfor@cisco.com
 End of changes. 6 change blocks. 
5 lines changed or deleted 12 lines changed or added

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