[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-zhang-ccamp-pathkey) 00 01

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/