Internet DRAFT - draft-zhang-ccamp-pathkey
draft-zhang-ccamp-pathkey
CCAMP Working Group Xian Zhang
Internet Draft Fatai Zhang
Category: Standards track Huawei
O. Gonzalez de Dios
Telefonica I+D
Igor Bryskin
ADVA Optical Networking
Expires: March 31, 2014 September 29, 2013
Extensions to Resource ReSerVation Protocol-Traffic Engineering (RSVP-
TE) to Support Route Exclusion Using Path Key Subobject
draft-zhang-ccamp-pathkey-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and 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.
This Internet-Draft will expire on March 31, 2014.
Abstract
Zhang Expires March 2014 [Page 1]
draft-zhang-ccamp-pathkey-00.txt September 2013
This document extends the Resource ReSerVation Protocol-Traffic
Engineering (RSVP-TE) eXclude Route Object (XRO) and Explicit Route
Object (ERO) to support specifying route exclusion requirement using
Path Key Subobject (PKS).
Table of Contents
1. Introduction ......................................... 2
1.1. Example Use ...................................... 3
2. RSVP-TE Extensions..................................... 4
2.1. Path Key Subobject (PKS) ......................... 4
2.2. PKS Processing Rules ............................. 4
3. Security Considerations................................ 5
4. IANA Considerations.................................... 5
4.1. New Subobject Type................................ 5
4.2. New Error Code.................................... 6
5. Acknowledgments ....................................... 6
6. References ............................................ 6
6.1. Normative References ............................. 6
6.2. Informative References............................ 6
7. Authors' Addresses..................................... 7
1. Introduction
[RFC5520] defines the concept of a Path Key. This object can be
used by a Path Computation Element (PCE) in place of a segment of a
path that it wishes to keep confidential. The Path Key can be
signaled in Resource ReSerVation Protocol-Traffic Engineering (RSVP-
TE) protocol by placing it in an Explicit Route Object (ERO) as
described in [RFC5553].
When establishing a set of LSPs to provide protection services
[RFC4427], it is often desirable that the LSPs should take different
paths through the network. This can be achieved by path computation
entities that have full end-to-end visibility, but it is more
complicated in multi-domain environments when segments of the path
may be hidden so that they are not visible outside the domain they
traverse.
This document describes how the Path Key object can be used in the
RSVP-TE eXclude Route Object (XRO), and the Explicit eXclusion Route
subobject (EXRS) of the ERO in order to facilitate path hiding, but
allow diverse end-to-end paths to be established in multi-domain
environments.
Zhang et al Expires March 2014 [Page 2]
draft-zhang-ccamp-pathkey-00.txt September 2013
1.1. Example Use
Figure 1 shows a simple network with two domains. It is desired to
set up a pair of path-disjoint LSPs from the source in Domain 1 to
the destination in Domain 2, but the domains keep strict
confidentiality about all path and topology information.
The first LSP will be signaled by the source with ERO {A, B, loose
Dst} and will be set up with the path {Src, A, B, U, V, W, Dst}. But
when sending the RRO out of Domain 2, node U would normally strip
the path and replace it with a loose hop to the destination. With
this limited information, the source is unable to include enough
detail in the ERO of the second LSP to avoid it taking, for example,
the path {Src, C, D, X, V, W, Dst} which is not path-disjoint.
In order to improve the outcome, node U can replace the path segment
{U, V, W} in the RRO with a Path Key. The Path Key Object assigns an
identifier to the key and also indicates that it was node U that
made the replacement.
With this additional information, the source is able to signal the
second LSP with ERO set to {C, D, exclude Path Key, loose Dst}. When
the signaling message reaches node X, it can consult node U to
expand the Path Key and so know to avoid the path of the first LSP.
Alternatively, the source could use an ERO of {C, D, loose Dst} and
include an XRO containing the Path Key.
--------------------- -----------------------------
| Domain 1 | | Domain 2 |
| | | |
| --- --- | | --- --- --- |
| | A |--| B |--+--+--| U |--| V |---| W | |
| / --- --- | | --- --- --- \ |
| ---/ | | / / \--- |
| |Src| | | / / |Dst| |
| ---\ | | / / /--- |
| \ --- --- | | --- / --- / --- / |
| | C |--| D |--+--+--| X |---| Y |--| Z | |
| --- --- | | --- --- --- |
| | | |
--------------------- -----------------------------
Figure 1: A Simple Multi-Domain Network
Zhang et al Expires March 2014 [Page 3]
draft-zhang-ccamp-pathkey-00.txt September 2013
2. RSVP-TE Extensions
This section defines the subobject that can be either in the XRO
object or Explicit eXclusion Route subobject (EXRS) as defined in
[RFC4874].
2.1. Path Key Subobject (PKS)
The IPv4 PKS has the following format:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PK-owner-ID (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meaning of the field L bit, Length, Path Key is defined in
[RFC4874].
Type: sub-object type for XRO Path Key; TBD.
PK-owner-ID: The IPv4 address of a node that assigned the Path Key
identifier and that can return an expansion of the Path Key or use
the Path Key as an exclusion in a path computation.
Similarly, the format of IPv6 PKS 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PK-owner-ID (16 bytes) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2. PKS Processing Rules
The exclude route list is encoded as a series of subobjects
contained in an EXCLUDE_ROUTE object or an EXRS of the ERO. The
procedure defined in [RFC4874] for processing XRO and EXRS is not
changed by this document.
Zhang et al Expires March 2014 [Page 4]
draft-zhang-ccamp-pathkey-00.txt September 2013
Irrespective of the L flag, if the node, receiving the PKS, cannot
recognize the subobject, it will react according to [RFC4874] and
SHOULD ignore the constraint.
Otherwise, if it cannot find a route/route segment meeting the
constraint:
-if L flag is set to 0, it will react according to [RFC4874] and
SHOULD send a PathErr message with the error code/value
combination ''Routing Problem'' / ''Route Blocked by Exclude Route''.
-if L flag is set to 1, which means the node SHOULD try to be as
much diversified as possible with the specified resource. If it
cannot fully support the constraint, it SHOULD send a PathErr
message with the error code/value combination "Notify Error" /
"Fail to find diversified path" (TBD).
This mechanism can work together with the presence of a Path
Computation Element (PCE) or if the local node generates the PK
itself. Note that other mechanisms to use or expand the PK are out
of scope of this document.
3. Security Considerations
The use of path keys proposed in this draft allows nodes to hide
parts of the path as it is signaled. This can be used to improve the
confidentially of the LSP setup. Moreover, it may serve to improve
security of the control plane for the LSP as well as data plane
traffic carried on this LSP. However, the benefits of using path key
are lost unless there is an appropriate access control of any tool
that allows expansion of the path key.
4. IANA Considerations
4.1. New Subobject Type
IANA registry: RSVP PARAMETERS
Subsection: Class Names, Class Numbers, and Class Types
This document introduces two new subobjects for the EXCLUDE_ROUTE
object [RFC4874], C-Type 1.
Subobject Type Subobject Description
-------------- ---------------------
Zhang et al Expires March 2014 [Page 5]
draft-zhang-ccamp-pathkey-00.txt September 2013
64(TBD by IANA) IPv4 Path Key Subobject
65(TBD By IANA) IPv6 Path Key Subobject
Note well: [RFC5520] defines the PKS for use in PCEP. The above
number suggestions for use in RSVP-TE follow that assigned for the
PKS in PCEP [RFC5520].
4.2. New Error Code
IANA registry: RSVP PARAMETERS
Subsection: Error Codes and Globally-Defined Error Value Sub-Codes
New Error Values sub-codes have been registered for the Error Code
'Notify Error' (25).
TBD = "Fail to find diversified path"
5. Acknowledgments
TBD.
6. References
6.1. Normative References
[RFC3209] D. Awduche et al, ''RSVP-TE: Extensions to RSVP for LSP
Tunnels'', RFC3209, December 2001.
[RFC4874] CY. Lee, A. Farrel, S. De Cnodder, ''Exclude Routes -
Extension to Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE), RFC4874, April 2007.
[RFC5553] A. Farrel, Ed., ''Resource Reservation Protocol (RSVP)
Extensions for Path Key Support'', RFC5553, May 2009.
6.2. Informative References
[RFC5520] R. Bradford, Ed., ''Preserving Topology Confidentiality
in Inter-Domain Path Computation Using a Path-Key-Based
Mechanism'', RFC5520, April 2009.
[RFC4427] E. Mannie, Ed., ''Recovery (Protection and Restoration)
Terminology for Generalized Multi-Protocol Label
Switching (GMPLS)'', RFC4427, March 2006.
Zhang et al Expires March 2014 [Page 6]
draft-zhang-ccamp-pathkey-00.txt September 2013
7. Authors' Addresses
Xian Zhang
Huawei Technologies
Email: zhang.xian@huawei.com
Fatai Zhang
Huawei Technologies
Email: zhangfatai@huawei.com
Oscar Gonzalez de Dios
Telefonica I+D
Don Ramon de la Cruz
Madrid, 28006
Spain
Phone: +34 913328832
Email: ogondio@tid.es
Igor Bryskin
ADVA Optical Networking
Email: ibryskin@advaoptical.com
Intellectual Property
The IETF Trust 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 any IETF 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.
Copies of Intellectual Property 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
Zhang et al Expires March 2014 [Page 7]
draft-zhang-ccamp-pathkey-00.txt September 2013
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
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions
of these Legal Provisions that are published by third parties,
including those that are translated into other languages, should
not be considered to be definitive versions of these Legal
Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect
and shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
Disclaimer of Validity
All IETF Documents and the information contained therein are
provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET
SOCIETY, THE IETF TRUST 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 THEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Notice
Zhang et al Expires March 2014 [Page 8]
draft-zhang-ccamp-pathkey-00.txt September 2013
Copyright (c) 2013 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Zhang et al Expires March 2014 [Page 9]
