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]