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-route-exclusion-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-route-exclusion-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-route-exclusion-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-route-exclusion-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-route-exclusion-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-route-exclusion-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-route-exclusion-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-route-exclusion-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-route-exclusion-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]