Internet draft draft-vasseur-mpls-isis-pcsd-discovery-01.txt  June 2002 

Network Working Group                                        JP Vasseur 
Internet Draft                                       Cisco Systems, Inc 
                                                         
Document: draft-vasseur-mpls-isis-pcsd-discovery-     
01.txt                                              
 
IETF Internet Draft                                      
Expires: December, 2002                             
                                                              June 2002 
 
 
                                     
              IS-IS Path Computation Server discovery TLV 
    
    
                                     
               draft-vasseur-mpls-isis-pcsd-discovery-01.txt 
 
    
 
Status of this Memo 
    
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026. 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. 
 
    
Abstract 
    
   This draft proposes an IS-IS extension for a router to announce its 
   Path Computation Server capability used in the context of MPLS 
   Traffic Engineering. This draft defines a new TLV called PCSD sub-
   TLV (Path Computation Server Discovery) which is carried within the 
   IS-IS LSP. 
    
    
1. Where does this draft fit in the picture of the Sub-IP work 
    
   This document specifies IS-IS extensions in support of MPLS Traffic 
   Engineering. It relates to the work on the off-load computation of 
   Traffic Engineering Label Switch Path covered by CCAMP.  
    
  
Vasseur                                                              1 








Internet draft draft-vasseur-mpls-pcsd-discovery-01.txt       June 2002 
 
 
 
    
2. Terminology 
    
   Terminology used in this draft 
    
   LSR: Label Switch Router 
    
   PCS: Path Computation Server (may be an LSR (ABR, ASBR, ...) or a 
   dedicated path computation server (typically a UNIX machine) not 
   forwarding packet. 
    
   PCC: Path Computation Client (any head-end LSR) requesting a path 
   computation to the Path Computation Server. 
    
   TE LSP: Traffic Engineering Label Switched Path 
    
   Head-end TE LSP: head/source of the TE LSP 
    
   Tail-end TE LSP: tail/destination of the TE LSP 
    
   Intra-area TE LSP: TE LSP whose head-end and tail-end reside in the 
   same area 
    
   Inter-area TE LSP: TE LSP whose head-end and tail-end reside in 
   different areas (the TE LSP spans areas) 
    
   Inter-AS TE LSP: TE LSP whose head-end and tail-end reside in 
   different Autonomous Systems (the TE LSP spans AS) 
    
    
3. Introduction 
    
   This draft specifies an IS-IS PCSD TLV, carried within an IS-IS LSP 
   for the Auto-discovery of one or more Path Computation Server(s).  
    
   In various situations, an LSR may send a request to a Path 
   Computation Server (PCS) to compute one or more Traffic Engineering 
   LSP paths obeying a set of specified constraints.  
    
   [13] specifies RSVP extensions: 
        - for a PCC to send path computation requests to a PCS to 
        compute TE LSP(s) obeying a set of specified constraints, 
        - for the PCS to provide to the PCC one or more computed paths 
        obeying the set of constraints (or to return an indication 
        mentioning no path obeying the constraints could be found). 
    
   The scope of this document is to define an IS-IS TLV such that an 
   LSR/centralized path computation tool may announce its capability to 
   be a Path Computation Server within an area or an Autonomous System. 
    
   This allows every LSR in the network to automatically discover the 
   Path Computation Server(s), which substantially simplifies the head-
Vasseur                                                              2 
 








Internet draft draft-vasseur-mpls-pcsd-discovery-01.txt       June 2002 
 
 
 
   end LSR configuration. Moreover, this allows to detect dynamically 
   any new PCS or that a PCS is no longer active. 
    
    
4. PCSD (Path Computation Server Discovery) TLV format 
    
   This section defines the PCSD TLV carried within the IS-IS LSP 
   payload.  
    
    
       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 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-// 
       |      Type     |     length    |           Value  ...             
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-// 
    
                                PCSD TLV format 
    
   Type: identifies the TLV type - TBD by the IS-IS WG (see [22]) 
   Length: variable 
   Value: the PCSD TLV is itself made of various non ordered sub-TLVs 
   defined bellow:  
         
   Sub-TLV type  Length                Name 
      1            4          Path computation server scope sub-TLV 
      2           variable    Path computation server address sub-TLV 
      3            8          Path computation server capability sub-TLV 
      4            8          AS-domain sub-TLV 
         
         
   Any non recognized sub-TLV MUST be silently ignored. 
         
                 
4.1 Path computation server scope sub-TLV 
    
   The path computation server scope sub-TLV specifies the zone for 
   which the path computation server is capable of performing TE LSP 
   path computation. 
    
   The path computation server scope sub-TLV type is 1, its length is 4, 
   and the value is a set of flags: 
    
    
      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 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      1        |       4       |         Reserved              |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |           Reserved            |     Flags     |         |A|I|L| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                     
                   Path computation server scope sub-TLV format 
Vasseur                                                              3 
 








Internet draft draft-vasseur-mpls-pcsd-discovery-01.txt       June 2002 
 
 
 
    
    
   Flags: no flags are currently defined. 
    
   Scope 
    
   L (local scope). When set, this flag indicates that the PCS can 
   compute paths for the level the LSP is flooded into (i.e the PCS can 
   compute TE LSP path for intra-area TE LSPs). 
    
   I (inter-area scope). When set, the PCS can perform TE LSP path 
   computation for inter-area TE LSPs (i.e TE LSP whose destination IP 
   address belongs to another area of the head-end LSR) but within the 
   same AS.  
    
   A (multi-domain scope). When set, the PCS can perform path 
   computation for inter-domain TE LSP. In this case, the PCSD TLV MUST 
   contain one or more AS-domain sub-TLV(s) each describing the domain 
   for which the PCS can compute TE LSPs paths having their destination 
   address in this domain.  
    
   Note that a PCS MAY set one or more flags. 
    
   See section 4 for a detailed description of the elements of 
   procedure. 
    
    
4.2 Path Computation Server address sub-TLV 
    
   The PCS address sub-TLV specifies the IP address to be used to reach 
   the PCS described by this PCSD TLV. This address will typically be a 
   loop-back address, always reachable, provided the router is not 
   isolated. This sub-TLV is required. 
    
   The PCS address sub-TLV type is 2, length is 4 octets for an IPv4 
   address and 16 octets for an IPv6 address, and the value is the PCS 
   IPv4 or IPv6 address. 
    
       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 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |      2        |  variable (4  | address-type  |   Reserved    |  
       |               |  or 16        |               |               |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |                                                               | 
       //                       PCS IP address                        //          
       |                                                               | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                         
                   Path Computation Server address sub-TLV format 
    
   Address-type: 
Vasseur                                                              4 
 








Internet draft draft-vasseur-mpls-pcsd-discovery-01.txt       June 2002 
 
 
 
        1   IPv4 
        2   IPv6 
    
   The router address sub-TLV MUST appear exactly once in the PCSD sub-
   TLV originated by a router. 
    
    
4.3 Path Computation Server capability sub-TLV 
    
   The PCS capability sub-TLV is used by the PCS to signal its path 
   computation server capabilities. This sub-TLV is optional. 
    
   The PCS capability sub-TLV type is 3 and the length is 8 octets. 
    
      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 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      3        |       8       |         Reserved              |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |P|M|D|E|G|                Reserved                             |     
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
                        PCS capability sub-TLV format 
    
    
   P bit 
   The notion of request priority allows a PCC to specify how urgent is 
   the request setting a flag in the REQUEST_ID object of the Path 
   computation request message. See [13] for more details. 
    
   P=1: the PCS takes into account the "request priority" in its 
   scheduling of the various requests. 
   P=0: the PCS does not take the request priority into account 
    
   M bit 
   M=1: the PCS is capable of computing more than one paths obeying a 
   set of specified constraints, provided that they exist. 
   M=0: the PCS cannot compute more than one path obeying a set of 
   specified constraints. 
    
   D bit 
   The PCC MAY request the PCS to compute N diversely routed paths 
   obeying a set of specified constraints.  
   Such N paths may not exist of course depending on the current state 
   of the network. See [13] for more details. 
   D=1: the PCS is capable of computing diversely (link, node, SRLG) 
   routed paths.  
   D=0: the PCS is not capable of computing diversely routed paths. 
   The D bit is relevant if and only if the M bit has been set to 1. It 
   MUST be set to 0 if the M bit is set to 0. 
    
   E bit 
Vasseur                                                              5 
 








Internet draft draft-vasseur-mpls-pcsd-discovery-01.txt       June 2002 
 
 
 
   The PCC may request the PCS the computation of a path obeying a set 
   of constraints one of those constraints being that one or more 
   specified network element object must not be traversed by the LSP (a 
   network element may be a link, an LSR or an Autonomous System). See 
   [13] for more details. 
   E=1: the PCS is capable of computing TE LSP paths excluding some 
   network elements. 
   E=0: the PCS is not capable of computing paths excluding network 
   elements. 
    
   G bit 
   As defined in [13], the PCC may send a request specifying the metric 
   to be used by the PCS when computing the shortest path during the 
   CSPF. 
   G=1: the PCS supports the computation of CSPF with various metrics 
   G=0: the PCS just computes the CSPF based on the TE metric 
    
   Note that for future capability, it MAY be desirable to introduce 
   new flags or may be new sub-TLV to be carried in the PCSD TLV if the 
   capability needs more than just a single flag to be described. 
    
    
4.4 AS-domain sub-TLV 
    
   When the PCS can perform path computation for inter-domain Traffic 
   Engineering LSP, the A bit of the path computation server scope TLV 
   MUST be set. Moreover, one or more sub-TLVs MUST included within the 
   PCSD sub-TLV, each sub-TLV identifying an AS number. Each sub-TLV 
   will have the following form:     
    
       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 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |      4        |       4       |         Reserved              |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |                           AS Number                           | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
                           AS-domain sub-TLV format 
    
    
   The AS-domain sub-TLV type is 4, length is 4 octets, and the value is 
   the AS number identifying the AS for which the PCS can compute inter-
   domain TE LSP paths (TE LSP having their destination address in this 
   domain). The AS Number field MUST have its left two bytes set to 0. 
    
   The set of AS-domain sub-TLVs specifies a list of ASes (AS1, ... , 
   ASn). This means that the PCS can compute TE LSP path such that the 
   destination address of the TE LSP belong to this set of ASes. 
    
    
5. Elements of procedure 
Vasseur                                                              6 
 








Internet draft draft-vasseur-mpls-pcsd-discovery-01.txt       June 2002 
 
 
 
    
   The PCSD TLV is carried within the IS-IS LSP. 
    
   IS-IS is an intra domain routing protocol. In networks having 
   multiple IS-IS levels, the elements of procedures for the 
   announcements of the PCSD TLVs by L1, L2 and L1L2 routers are the 
   following: 
    
   - If the PCS can compute intra-area TE LSP the L bit of the path 
   computation server scope sub-TLV must be set, 
   - If the PCS can compute inter-area TE LSP the I bit of the path 
   computation server scope sub-TLV must be set, 
   - If the PCS can compute inter-AS TE LSP the A bit of the path 
   computation server scope sub-TLV must be set, 
    
   Note: if the PCS can both compute intra and inter-area TE LSP paths, 
   both the L and I bits of the path computation server scope TLV must 
   be set. The flags are not exclusive. 
    
   Mode of operation on L1L2 routers 
    
   Any L1L2 routers receiving an LSP containing a PCSD TLV MUST: 
        - determine the values of the L, I and A bits flag of the Path 
        computation server scope sub-TLV, 
        - if L=1, I=0, A=0: the PCSD TLV MUST not be included in any 
        generated LSP, 
        - if either I or A is not equal to 0, the PCSD TLV MUST be 
        included in any generated LSP into other levels with L=0, I and 
        A unchanged, 
         
         
   Example 
    
   <-----------------AS1-----------------> 
    
   R1(L1)------R3(L1L2)*-----R4(L1L2)*----|                ------------ 
    |           |                |        |                |          | 
    |     S1    |      S2        |     ASBR1*--eBGP--ASBR2-|    AS2   | 
    |           |                |        |                |          | 
   R2(L1)------R5(L1L2)*-----R6(L1L2)-----|                ------------ 
    
   The areas contents are not detailed. 
    
   Assumptions: 
   - the * indicates a Path computation server capability 
   - R3 is a PCS for level 1 only 
   - R5 is a PCS for intra and inter-area TE LSP path computation for 
   both levels 
   - R4 is a PCS for inter-area TE LSP path computation only for both 
   levels 
   - S1 is a PCS for level 1 only 
   - S2 is a PCS for the whole AS 
Vasseur                                                              7 
 








Internet draft draft-vasseur-mpls-pcsd-discovery-01.txt       June 2002 
 
 
 
   - ASBR1 is a PCS for inter-AS TE LSP whose destination resides in 
   AS2 (not for intra or inter-area area TE LSPs). 
    
   In the example above: 
   - S1 originates a level 1 LSP containing a PCSD TLV with: 
        o The L bit of the path computation server scope TLV set, 
        o The I and A bits of the path computation server scope TLV 
        cleared. 
    
   - S2 originates a level 2 LSP containing a PCSD TLV with: 
        o Both the L and I bit of the path computation server scope TLV 
        set, 
        o The A bit of the path computation server scope TLV cleared, 
    
   - ASBR1 originates a level1 LSP containing a PCSD TLV with: 
        o The L and I bits of the path computation server scope TLV 
        cleared, 
        o The A bit of the path computation server scope TLV set, 
        o One AS-domain sub-TLV within the PCSD sub-TLV with AS number 
        = AS2 
    
   - R3 originates: 
    
   * a level 1 LSP containing: 
        o a PCSD TLV describing its own PCS capability with:  
                - The L bit of the path computation server scope TLV 
                set, 
                - The I and A bits of the path computation server scope 
                TLV cleared, 
        o the S2's PCSD TLV (with L bit of the path computation server 
        scope TLV cleared - I and A bit unchanged) 
        o the ASBR1's PCSD TLV (unchanged) 
    
   * a level 2 LSP including no PCSD TLV 
    
   - R5 originates: 
    
   * a level1 LSP containing:  
        o a PCSD TLV describing its own PCS capability with: 
                - The L and I bits of the path computation server scope 
                TLV set, 
                - The A bit of the path computation server scope TLV 
                cleared, 
        o the S2's PCSD TLV (with L bit of the path computation server 
        scope TLV cleared - I and A bit unchanged) 
        o the ASBR1's PCSD TLV (unchanged) 
    
   * a level 2 LSP containing a PCSD TLV describing its own PCSD 
   capability with: 
        o Both the L and I bit of the path computation server scope TLV 
        set, 
        o The A bit of the path computation server scope TLV cleared. 
Vasseur                                                              8 
 








Internet draft draft-vasseur-mpls-pcsd-discovery-01.txt       June 2002 
 
 
 
         
   The receipt of an LSP containing a new PCSD TLV never triggers an 
   SPF calculation. 
    
   When an LSR or a dedicated path computation server is newly 
   configured as a PCS, the corresponding PCSD TLV MUST be immediately 
   flooded. 
    
   When an LSR or a dedicated path computation server is loosing its 
   path computation server capability or when one of its PCSD 
   capabilities changes, the IS-IS LSP MUST be immediately flooded. 
    
    
6. Interoperability with routers non supporting this capability 
    
   There should not be any interoperability issue with routers non 
   supporting the PCSD TLV. A router non supporting this extension will 
   silently ignore the PCSD TLV. 
    
    
7. Security Considerations 
 
   No new security issues are raised in this document. 
    
    
8. Acknowledgments 
    
   The authors would like to thank Stefano Previdi and Mike Shand for 
   their valuable comments. 
    
    
9. References 
    
   [1] ISO 10589, "Intermediate System to Intermediate System Intra- 
      Domain Routeing Exchange Protocol for use in Conjunction with the 
      Protocol for Providing the Connectionless-mode Network Service  
      (ISO 8473)" [Also republished as RFC 1142] 
    
   [2] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual 
       environments", R.W. Callon, December 1990 
    
   [3] RFC 2966, "Domain-wide Prefix Distribution with Two-Level IS-   
       IS", T. Li, T. Przygienda, H. Smit, October 2000. 
    
   [4] RFC 2702, "Requirements for Traffic Engineering Over MPLS," D. 
       Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus,   
       September 1999. 
    
   [5] Smit, H., Li, T., "IS-IS Extensions for Traffic Engineering", 
       draft-ietf-isis-traffic-04.txt (work in progress) 
 
   [6] Generalized MPLS Group, "Generalized MPLS - Signaling 
Vasseur                                                              9 
 








Internet draft draft-vasseur-mpls-pcsd-discovery-01.txt       June 2002 
 
 
 
       Functional Description", draft-ietf-mpls-generalized-signaling-  
       04.txt (work in progress) 
    
   [7] "Routing Extensions in Support of Generalized MPLS", 
       draft-many-ccamp-gmpls-routing-01.txt (work in progress) 
    
   [8] "Three-Way Handshake for IS-IS Point-to-Point 
       Adjacencies", draft-ietf-isis-3way-05.txt (work in progress) 
    
   [9] "Restart signaling for ISIS", draft-ietf-isis- 
       restart-00.txt (work in progress) 
    
   [10] "Generalized MPLS Signaling - RSVP-TE Extensions", 
        draft-ietf-mpls-generalized-rsvp-te-06.txt (work in progress) 
    
   [11] Bradner, S., "Key words for use in RFCs to Indicate 
        Requirement Levels", BCP 14, RFC 2119, March 1997. 
    
   [12] Vasseur et al, "RSVP Path computation request and reply 
   messages ", draft-vasseur-mpls-computation-rsvp-te-03.txt, work in 
   progress. 
    
   [13] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS TE", 
   Internet Draft, draft-ietf-mpls-lsp-hierarchy-06.txt, work in 
   progress. 
    
   [14]  Kompella, K., Rekhter, Y., "Signalling Unnumbered Links in 
   RSVP-TE", Internet Draft, draft-ietf-mpls-rsvp-unnum-01.txt, February 
   2001 
    
   [15] Ashwood-Smith, P. et al, "Generalized MPLS - Signaling 
   Functional Description", Internet Draft, draft-ietf-mpls-generalized-
   signaling-02.txt, 
   February 2001. 
    
   [16] "IS-IS Extensions in Support of Generalized MPLS", draft-ietf-
   isis-gmpls-extensions-12.txt, work in progress. 
    
   [17] Braden, R. Ed. et al, "Resource ReserVation Protocol-- Version 1 
   Functional Specification", RFC 2205, September 1997. 
    
   [18] Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", 
   RFC 3209, December 2001. 
    
   [19] Berger L., Gan D., Swallow G., Pan P., Tommasi F., Molendini S., 
   "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001. 
    
   [20] Le faucheur, "Use of IGP Metric as a second TE Metric", 
   Internet draft, draft-lefaucheur-te-metric-igp-00.txt. 
    


Vasseur                                                             10 
 








Internet draft draft-vasseur-mpls-pcsd-discovery-01.txt       June 2002 
 
 
 
   [21] Fedyk D., Ghanwani A., Ash J., Vedrenne A. "Multiple Metrics 
   for Traffic Engineering with IS-IS and OSPF", Internet draft,  
   draft-fedyk-isis-ospf-te-metrics-01.txt 
    
   [22] T. Przygienda, "Reserved TLV Codepoints in ISIS", draft-ietf-
   isis-wg-tlv-codepoints-01.txt 
    
    
8. Author's Addresses 
    
      JP Vasseur 
      CISCO Systems, Inc. 
      11, rue Camille Desmoulins 
      92782  Issy les Moulineaux Cedex 9 
      FRANCE 
      Email: jpv@cisco.com 
    
    


































Vasseur                                                             11