Internet DRAFT - draft-zhang-ccamp-route-exclusion-pathkey

draft-zhang-ccamp-route-exclusion-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 
                                                            Dhruv Dhody 
                                                                 Huawei 
 
 
Expires: August 13, 2014                             February 14,  2014 
                                    
                                    
                                    
 Extensions to Resource ReSerVation Protocol-Traffic Engineering (RSVP-
         TE) to Support Route Exclusion Using Path Key Subobject 
                                    
                                    
              draft-zhang-ccamp-route-exclusion-pathkey-01.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 August 13, 2014. 




 
 
 
Zhang et al              Expires August 2014                   [Page 1] 

draft-zhang-ccamp-route-exclusion-pathkey-01.txt          February 2014 


 Copyright Notice 

   Copyright (c) 2014 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. 

Requirements Language 

   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 [RFC2119]. 

Abstract 
 
   This document extends the Resource ReSerVation Protocol-Traffic 
   Engineering (RSVP-TE) eXclude Route Object (XRO) and Explicit 
   eXclusion Route Subobject (EXRS) within Explicit Route Object (ERO) 
   to support specifying route exclusion requirement using Path Key 
   Subobject (PKS).  

    

Table of Contents 

   1. Introduction ................................................ 3 
      1.1. Example Use ............................................ 3 
   2. RSVP-TE Extensions .......................................... 4 
      2.1. Path Key Subobject (PKS)................................ 4 
      2.2. PKS Processing Rules.................................... 5 
   3. Other considerations......................................... 6 
      3.1. Path-Key Retention and Reuse............................ 6 
      3.2. Path-Key Uniqueness..................................... 7 
      3.3. PKS Update ............................................. 7 
   4. Manageability Considerations .................................7 
      4.1. Control of Function through Configuration and Policy.....7 
   5. Security Considerations...................................... 8 
   6. IANA Considerations ......................................... 8 
 
 
Zhang et al              Expires August 2014                  [Page 2] 

draft-zhang-ccamp-route-exclusion-pathkey-01.txt          February 2014 


      6.1. New Subobject Type...................................... 8 
      6.2. New Error Code ......................................... 8 
   7. Acknowledgments ............................................. 9 
   8. References .................................................. 9 
      8.1. Normative References.................................... 9 
      8.2. Informative References.................................. 9 
   9. Contributors ................................................ 9 
   10. Authors' Addresses ......................................... 9 
 
 1. Introduction 

   [RFC5520] defines the concept of a Path Key for confidentiality in a 
   multi-domain environment.  This 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. 
    
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. 

 
 
Zhang et al              Expires August 2014                  [Page 3] 

draft-zhang-ccamp-route-exclusion-pathkey-01.txt          February 2014 


       ---------------------    ----------------------------- 
      | Domain 1            |  |                    Domain 2 | 
      |                     |  |                             | 
      |        ---    ---   |  |   ---    ---     ---        | 
      |       | A |--| B |--+--+--| U |--| V |---| W |       | 
      |      / ---    ---   |  |   ---    ---     --- \      | 
      |  ---/               |  |          /       /    \---  | 
      | |Src|               |  |         /       /     |Dst| | 
      |  ---\               |  |        /       /      /---  | 
      |      \ ---    ---   |  |   --- /   --- /  --- /      | 
      |       | C |--| D |--+--+--| X |---| Y |--| Z |       | 
      |        ---    ---   |  |   ---     ---    ---        | 
      |                     |  |                             | 
       ---------------------    ----------------------------- 
    
             Figure 1: A Simple Multi-Domain Network 
    
   In order to improve the outcome, node U can replace the path segment 
   {U, V, W} in the RRO with a Path Key Suboject. The Path Key 
   Subobject 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(EXRS), 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. 
    
   This example uses a PCE deployed in each border router, having at 
   least the capability to expand PKS. Other deployment scenarios 
   (Domain PCE, PCE being part of the Management system) may be used. 
    
    
2. RSVP-TE Extensions 

   This section defines the Path Key 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 same format as defined in [RFC5553] and is 
   detailed as below: 

    

 
 
Zhang et al              Expires August 2014                  [Page 4] 

draft-zhang-ccamp-route-exclusion-pathkey-01.txt          February 2014 


   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            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                     PCE-ID (4 bytes)                          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   The meaning of the field Length and Path Key is defined in [RFC5553].  

   L: 0 indicates that the path or path segment hidden with the Path 
   Key specified MUST be excluded. 1 indicates that the path or path 
   segment hidden with the Path Key specified SHOULD be avoided. 

   Type: sub-object type for XRO Path Key; TBD. 

   PCE-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. Note this draft 
   does not confine whether it is the network element or a dedicated 
   server for path key generation and decoding. 

   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            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                    PCE-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. Multiple 
   Path-Keys may be included in XRO or EXRO of ERO if more than segment 
   of a path are kept hidden during diverse path establishment. The 
   procedure defined in [RFC4874] for processing XRO and EXRS is not 
   changed by this document. 

   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.  
 
 
Zhang et al              Expires August 2014                  [Page 5] 

draft-zhang-ccamp-route-exclusion-pathkey-01.txt          February 2014 


   Otherwise, if it decodes the PKS but 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). 

   If it cannot decode the PKS, the error handling procedure defined in 
   Section 3.1 of [RFC5553] is not changed by this document. 

   This mechanism can work with all the PKS resolution mechanism, as 
   detailed in [RFC5553] section 3.1. A PCE, co-located or not, may be 
   used to resolve the PKS, but the node (i.e., a Label Switcher 
   Router(LSR)) can also use the PKS information to index a Path 
   Segment previously supplied to it by the entity that originated the 
   PKS, for example the LSR that inserted the PKS in the RRO or a 
   management system. 

3. Other considerations 

3.1. Path-Key Retention and Reuse 

   The use of the path key relies on the availability of a PCE function 
   supporting [RFC5520] functionality. 

   Following [RFC4655] a simple deployment option is when the PCE 
   function is collocated with each border domain node generating the 
   RRO. This collocated PCE functionality can be restricted to only 
   serve the PKS resolution. This PCE function is only required to be 
   accessible to the nodes excluding this PKS, so this can be 
   restricted to one domain. This option can very easily tie the 
   lifetime of the PKS to the lifetime of the LSP. 

   Alternatively, if a dedicated server, such as a PCE, is in charge of 
   this, it may need to be explicitly informed of the LSP tear-down in 
   order to recycle the path key allocated already. This can be easily 
   supported by a stateful PCE [Stateful-PCE]. Note this draft does not 
   confine the methods for path key generation and decoding.  

   Last, options including allowing a LSR can use the PKS information 
   to index a Path Segment previously supplied to it by the entity that 
 
 
Zhang et al              Expires August 2014                  [Page 6] 

draft-zhang-ccamp-route-exclusion-pathkey-01.txt          February 2014 


   originated the PKS, for example the LSR that inserted the PKS in the 
   RRO or a management system, can also be used. 

3.2. Path-Key Uniqueness 

   In the CCAMP mailing list, there is concern about whether 16-bit 
   Path key is still enough and future proof. This can be easily solved 
   by confining the scope of a path key. If an ingress node is 
   responsible for managing the Path Key, it should not be an issue 
   since the LSP across domains do not expected to be larger than 65535. 
   On the other hand, if a dedicated entity, such as a PCE server, is 
   used to allocate and recycle the Path Key, it is advised to allocate 
   the Path Key per ingress node basis to avoid the limitation of Path 
   Key numbers facing a domain-based allocation space. These are only 
   illustrative examples and other methods that can guarantee the 
   uniqueness of Path-Key are not precluded. 

3.3. PKS Update 

   When the information of a path is changed, the LSPs using that path 
   and corresponding PKS should be aware of the changes.  The 
   procedures defined in Section 4.4.3 of RFC 3209 [RFC3209] MUST be 
   used to refresh the PKS information if the PKS change is to be 
   communicated to other nodes according to the local node's policy.  
   If local policy is that the PKS change should be suppressed or would 
   result in no change to the PKS expansion, the node does not need to 
   send an update. This procedure allows for ingress node to react on 
   path change. 

4. Manageability Considerations  

4.1. Control of Function through Configuration and Policy 

   In addition to the set of policies described in [RFC5553] the 
   following policies (are local and domain-wide) SHOULD be available 
   for configuration in an implementation: 

    - Handling a XRO or EXRS containing a PKS. As described in Section 
   2.2, an LSR that receives a Path message containing a PKS exclusion 
   can be configured to reject the Path message according to policy. 

    - Hiding of reason codes. The policy described in [RFC5553] section 
   5.1 is also applicable to policies for PKS in XRO or EXRS.  

   This document makes no other new management consideration to RSVP 
   and PCE, the existing consideration applies. 

 
 
Zhang et al              Expires August 2014                  [Page 7] 

draft-zhang-ccamp-route-exclusion-pathkey-01.txt          February 2014 


5. 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. 

6. IANA Considerations 

6.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 

   --------------                        --------------------- 

     64(TBD by IANA)                     IPv4 Path Key Subobject 

     65(TBD By IANA)                     IPv6 Path Key Subobject 

   Note: [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].  

6.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"  




 
 
Zhang et al              Expires August 2014                  [Page 8] 

draft-zhang-ccamp-route-exclusion-pathkey-01.txt          February 2014 


7. Acknowledgments 

   The authors would like to thank John Drake, Daniele Ceccarelli and 
   Zafar Ali for their comments and dicussions. 

8. References 

8.1. Normative References 

   [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 
               requirements levels", RFC 2119, March 1997. 

   [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. 

8.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. 

   [Stateful-PCE] Crabbe, E., Medved, J., Minei, I., and R. Varga, 
               "PCEP Extensions for Stateful PCE", draft-ietf-pce-
               stateful-pce-06 (work in progress), August 2013. 

 9. Contributors 

   Cyril 
   cyril.margaria@gmail.com 
    
 10. Authors' Addresses 

    



 
 
Zhang et al              Expires August 2014                  [Page 9] 

draft-zhang-ccamp-route-exclusion-pathkey-01.txt          February 2014 


   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
    
   Dhruv Dhody 
   Huawei Technologies 
   Leela Palace 
   Bangalore, Karnataka  560008 
   INDIA 
    
   EMail: dhruv.ietf@gmail.com
    











 
 
Zhang et al              Expires August 2014                 [Page 10]