One document matched: draft-bradford-ccamp-path-key-ero-00.txt
Networking Working Group Rich Bradford (Ed)
IETF Internet Draft JP Vasseur
Cisco Systems, Inc.
Adrian Farrel
Old Dog Consulting
Proposed Status: Standard
Expires: April 2007
October 2006
draft-bradford-ccamp-path-key-ero-00.txt
RSVP Extensions for Path Key Support
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
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Bradford, Vasseur and Farrel 1
draft-bradford-ccamp-path-key-ero-00.txt September 2006
Abstract
Multiprotocol Label Switching (MPLS) 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 (ASs), 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 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 Sub-object (PKS). This draft describes
the addition of this object to the Explicit Route Object.
Table of contents
To be Added
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
This document proposes RSVP-TE protocol extensions necessary to
support the protocol extensions called out in [PCE-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 Sub-object. A sub-object of an Explicit Route Object
which encodes a CPS, so as to preserve confidentiality.
3. RSVP-TE Path Key Sub-object
The Path Key sub-object (PKS) may be carried in the Explicit Route
Object (ERO) of a RSVP-TE Path message [RFC3209]. The PKS is a
Bradford, Vasseur, and Farrel 2
draft-bradford-ccamp-path-key-ero-00.txt September 2006
fixed-length sub-object 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. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
The L bit SHOULD NOT be set, so that the sub-object
represents a strict hop in the explicit route.
Type
TBD Path Key with IPv4 address
Length
The Length contains the total length of the subobject in
bytes, including the Type and Length fields. The Length is always
8.
IPv4 address
An IPv4 address of the PCE that can decode this key. The
address used SHOULD be an 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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (16 bytes) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
Bradford, Vasseur, and Farrel 3
draft-bradford-ccamp-path-key-ero-00.txt September 2006
As above.
Type
TBD Path Key with IPv6 address
Length
The Length contains the total length of the subobject in
bytes, including the Type and Length fields. The Length is always
20.
IPv6 address
An IPv6 address of the PCE that can decode this key. The
address used SHOULD be an 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.
Note: The twins of these sub-objects will be carried in a PCEP
PCRep message as defined in [PCE-PKS]. Ideally, IANA assignment of
the sub-object types will be identical.
4. Security Considerations
This document proposes tunneling secure topology information
across an untrusted AS, so the security considerations are many
and apply to PCEP and RSVP-TE.
Issues include:
- Security 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 DNS attacks (insertion of spurious path-keys;
flooding of bogus path-key expansion requests).
5. Manageability Considerations
TBD
6. IANA considerations
The IANA section will be detailed in further revision of this
document.
For RSVP, it will include code point requests for the three new
ERO sub-objects, and a new ErrorSpec Error Code.
Bradford, Vasseur, and Farrel 4
draft-bradford-ccamp-path-key-ero-00.txt September 2006
For PCEP, it will include code point requests for the three new
computed path sub-objects.
7. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
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.
[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.
[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-vasseur-pce-pcep,
work in progress.
[PCE-PKS] Bradford, R., Vasseur, J.P., Farrel, A., "Preserving
Topology Confidentiality in Inter-Domain Path Computation and
Signaling", draft-bradford-pce-path-key,
work in progress.
Bradford, Vasseur, and Farrel 5
draft-bradford-ccamp-path-key-ero-00.txt September 2006
8.2. Informational References
[PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation
Element (PCE) Architecture", draft-ietf-pce-architecture, work in
progress.
[PD-PATH-COMP] Vasseur, J., et al "A Per-domain path computation
method for establishing Inter-domain Traffic Engineering (TE)
Label Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd-
path-comp, work in progress.
[BRPC] Vasseur, J., et al "A Backward Recursive PCE-based
Computation (BRPC) procedure to compute shortest inter-domain
Traffic Engineering Label Switched Path", draft-vasseur-pce-brpc,
work in progress.
[RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for
Support of Inter-Area and Inter-AS MPLS Traffic Engineering", RFC
4105, June 2005.
[RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic
Engineering requirements", RFC 4216, November 2005.
9. Authors' Addresses:
Rich Bradford (Editor)
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough , MA - 01719
USA
Email: rbradfor@cisco.com
J.-P 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, Vasseur, and Farrel 6
draft-bradford-ccamp-path-key-ero-00.txt September 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Bradford, Vasseur, and Farrel 7
| PAFTECH AB 2003-2026 | 2026-04-23 16:01:53 |