INTERNET DRAFT                                         Vijayanand 
Expiration Date: April 2007                       HCL Technologies
                                                Somen Bhattacharya
                                                    Prasanna Kumar
                                                     Avici Systems

 
       BGP Protocol extensions for PCE Discovery across
           Autonomous systems  
          draft-vijay-somen-pce-disco-proto-bgp-03.txt 
  
      
Status of this Memo 
    
   By submitting this Internet-Draft, each author 
   represents that any applicable patent or other IPR 
   claims of which he or she is aware have been or will 
   be disclosed, and any of which he or she becomes 
   aware will be disclosed, in accordance with Section 6 
   of 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 April, 2007. 
 
  Copyright Notice 
    Copyright (C) The Internet Society (2006). 

     
Abstract 
    
    It is desirable for a PCC to dynamically discover a PCE and 
    its capabilities for computing paths which span multiple 
    areas and autonomous systems. When the path to be computed 
    spans across multiple IGP domains or autonomous systems, it 


Vijayanand, et al.                                        [Page 1] 
 
 INTERNET DRAFT  BGP extensions for PCE discovery    October 2006 
 
   is advantageous to use BGP to distribute information about  
   PCEs. This document describes means to carry PCE discovery 
   information using Multi-protocol extensions of BGP(MP-BGP). 
        
   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 RFC 2119 [RFC2119]. 
    
    
1. Introduction 
    
       The motivation for using PCE-based model for path 
   computation in MPLS networks is clearly detailed in [PCE-
   ARCH]. This model supports separation of PCC and PCE.  
    
       A network may consists of a number of PCEs, spread 
   across multiple areas and domains, each with different 
   capabilities and scope. In such a scenario, it is highly 
   desirable to have a dynamic and automatic means for PCE 
   discovery. This would enable the PCC to be aware of PCE in 
   its own domain and the PCE in a domain be aware of PCEs in 
   other domains for computing paths spanning multiple 
   domains, eg. as in inter-domain TE LSPs. The mechanism 
   would also facilitate automatic detection of modification 
   of PCE information.This discovery information would be used
   in selecting appropriate PCE for setting up PCEP session
   bwtween PCEs.Detailed requirements on PCE discovery are
   described in [PCE-DISC-REQ].  
        
       The means to discover PCE in the same IGP domain are 
   described in [PCE-DISCO-IGP], wherein the IGP is used to 
   flood information on the PCE capabilities. In order to 
   discover PCEs across IGP domains and autonomous systems a 
   more scalable model than IGP flooding is required. This is 
   also relevant since operators have policies governing the 
   import and export of routing information across their 
   domains.  
    
       An efficient way for discovering PCEs across IGP 
   domains and Autonomous systems would be to use BGP for 
   carrying PCE discovery information.  
    
       This document describes how PCE information can be 
   carried in MP-REACH-NLRI of BGP update messages. The PCE 
   Discovery TLV and PCE Status TLV defined in [PCE-DISCO-
   IGP], which represent the state and status of PCE, will be 
   carried in the NLRI information of the MP-REACH NLRI.  


Vijayanand, et al.           October 2006                [page 2 ] 
 
 INTERNET DRAFT   BGP extensions for PCE discovery   October 2006 
 
 
    
    
       The path-computation-capabilities TLV which is a sub-
   TLV of PCE discovery TLV as defined in [PCE-DISCO-IGP] has 
   been extended to support additional capabilities.Additional
   sub-TLVs have also been added to the PCE discovery TLV
   to support alternate PCE discovery. 
    
       The PCE information is described in section 3 and BGP 
   specific procedures and interactions with IGP are described 
   in section 4. 
    
    
2. Terminology 
       
   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 [RFC-WORDS]. 
    
   The reader is assumed to be familiar with the terminology 
   in [PCE-ARCH] and [PCE-DISCO-IGP] 
    
        AS               : Autonomous system 
    
        ASBR             : Autonomous System Border Router 
    
        Inter-AS TE LSP  : A TE LSP whose path crosses one or 
                           more ASes or sub ASes 
    
        NLRI             : Network Layer Reachability 
                           Information 
 
        PCC              : Path Computation Client. An entity 
                           or application requesting path
                           computation from a Path 
                           computation element 
     
        PCE              : Path Computation Element. An entity 
                           or application capable of computing
                           paths over a network topology 
                           subject to constraints. 
    
        TE LSPs          : Traffic Engineered Label Switched 
                           Path 
    

3. PCE Information 
    
      The PCE information advertised includes PCE discovery 
   information and PCE status information.  


Vijayanand, et al.            October 2006               [page 3 ] 
 
 INTERNET DRAFT   BGP extensions for PCE discovery   October 2006 
 
 
      This document describes extensions to the PCE discovery 
   information that is defined in [PCE-DISCO-IGP} that is to 
   be carried in BGP.  
    
    
3.1 PCE Discovery Information 
    
       The PCE discovery information consists of PCE location, 
   PCE inter-domain functions, PCE domain visibility, PCE 
   destination domains and a set of general  PCECP 
   capabilities. These are described in [PCE-DISCO-IGP} and 
   the same TLVs as used for OSPF can be used for BGP. In 
   addition to the definitions in [PCE-DISCO-IGP] we define 
   new capability flags for PCE in the path computation 
   capabilities TLV. We also define additional sub-TLVs to the 
   PCE discovery sub-TLVs for redundant PCE discovery.  
     
       The PCE discovery TLV carries the path computation 
   capabilities sub-TLV which is described and extended below. 
    
    
3.1.1 Path Computation Capabilities Sub-TLV 
 
 
      The path computation capability PATH-COMP-CAP sub-TLV is 
   carried in the PCE discovery TLV. This is used to advertise 
   path computation specific capabilities of the PCE. It MAY 
   include optional sub-TLVs to encode more complex capabilities.
   We define additional capabilities in the path computation
   capabilities flag of the path computation capabilities
   sub-TLV. 
    
   Two more additional capabilities flag are defined to extend 
   the definitions of diverse path computation capabilities to 
   consider inter-AS paths. 
    
   In general the path diversity level can be categorized as: 
     . Intra-area diversity : the path segments are link, node 
        or SRLG disjoint inside an IGP area. 
     . Inter-area diversity : the end-to-end paths are link, 
        node and SRLG disjoint across area borders. 
     . Intra-AS diversity : the path segments are link, node, 
        SRLG or area disjoint inside an AS. 
     . Inter-AS diversity : the end-to-end paths are link, 
        node, SRLG or area disjoint across AS borders.  
 
 
   The format of the PATH-COMP-CAP sub-TLV is as follows:  
 
    
Vijayanand, et al.            October 2006                [page 4 ] 
 
 INTERNET DRAFT  BGP extensions for PCE discovery   October2006 
 
 
      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            |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |             Path Computation Capabilities  Flag               |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   //                    Optional sub-TLVs                        //  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 
 
       Type     To be assigned by IANA (suggested value =1)  
 
       Length   Variable.  
 
       Value    This comprises a 32 bit flag. Bits are indexed from   
                 the most significant to the least significant, where   
                 each bit represents one path computation capability.   
            
     Optional TLVs may be defined to specify more 
     complex capabilities. Three optional sub-TLVs are 
     currently defined.  
     
     IANA is requested to manage the space of the Path Computation  
     Capabilities 32-bit flag.  
     
     The following bits are to be assigned by IANA:  
     
     
        Bit       Capabilities  
     
         0      G bit: Capability to handle GMPLS link contraints  
         1      B bit: Capability to compute bidirectional paths  
         2      D bit: Capability to compute link/node/SRLG diverse 


Vijayanand, et al.            October 2006                   [page 5 ] 
 
 INTERNET DRAFT     BGP extensions for PCE discovery    October 2006 
 
 
                       paths  
         3      L bit: Capability to compute load-balanced paths  
         4      S bit: Capability to compute a set of paths in 
                       a synchronized Manner  
         5      O bit: Support for multiple objective functions  
         6      P bit: Capability to handle path constraints 
                       (e.g. hop count, metric bound) 
         7      DRA bit: Capability to compute inter-area diverse 
                        paths 
         8      DAS bit: Capability to compute intra-AS 
                         diverse paths 
         9      DRS bit: Capability to compute inter-AS 
                         diverse paths 
         10     C bit: Capability to handle inter-AS policy 
                        constraints  
         11     T bit: Capabilty to handle diff-serv aware TE 
                        requests                              
    
         9-31   Reserved for future use. 
 
        
   In addition to the capabilities defined in [PCE-DISCO-IGP] 
   the following new capability bits are defined in this document. 
 
   The DRA bit indicates the capability of the PCE to compute 
   inter-area diverse paths that are end-to-end node-disjoint 
   across area borders. 
 
   The DAS bit indicates the capability of the PCE to compute 
   intra-ASdiverse paths in which path segments within an AS
   are node-disjoint but end-to-end paths across AS borders
   are not node-disjoint. 
 
   The DRS bit indicates the capability of the PCE to compute 
   inter-ASdiverse paths in which path segments are end-to-end
   link, node, SRLG or area disjoint across the AS borders. 
 
   The C bit indicates the capability of the PCE to handle inter-AS    

Vijayanand, et al.         October 2006                   [page 6 ] 
 
 INTERNET DRAFT  BGP extensions for PCE discovery    October 2006 
 
 
   policy constraints in the PCC computation request. This MAY 
   be requests containing constraints to avoid certain AS or 
   sub-AS or certain inter-AS links or certain ASBRs. 

   The T bit indicates the capability of the PCE to handle 
   computation requests for diff-serv aware TE LSPs. These 
   requests would contain information on the diff serv class 
   type of the requested LSP in addition to the other TE 
   constraints. 
          
3.1.2 PCE Redundancy Discovery 
 
      When multiple PCEs participate in the computation of an 
   inter-domain path each PCE MAY be responsible to compute 
   one or more path segments that span through specific 
   domains. In such scenarios it MAY be desirable to have 
   redundant backup PCEs that can be used in the event of 
   failure of one or more primary PCEs. Thus the PCE discovery 
   mechanism should allow a PCE to indicate a set of one or 
   more alternate backup PCEs that can be chosen in case the 
   given PCE fails.Two new sub-TLVs have been defined that 
   can be optionally present in the PCE discovery TLV. These 
   two sub-TLVs can be used for the discovery of such 
   redundancy information satisfying dynamic PCE discovery 
   requirements set forth in [PCE-DISC-REQ]. 
 
3.1.2.1 ALTERNATE-PCES sub-TLV 
 
   The ALTERNATE-PCES sub-TLV specifies the set of PCEs as an 
   alternate to a given primary PCE for path computation 
   purposes. One or more alternate PCE can be selected when 
   the given primary PCE fails. It contains a set of one or 
   more PCE-ADDRESS sub-TLVs where each sub-TLV is used to 
   identify an alternate PCE. This is an optional sub-TLV and 
   one or more such instances MAY be included in the PCED TLV. 
 
 
   The ALTERNATE-PCES sub-TLV 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  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |              Type             |             Length            |
 

Vijayanand, et al.          October 2006                   [page 7 ] 
 
 INTERNET DRAFT    BGP extensions for PCE discovery   October 2006 
 
 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   //                     PCE-ADDRESS sub-TLVs                    // 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 
 

        Type     To be assigned by IANA (suggested value=5)  
        Length   Variable. 
        Value    This comprises a set of one or more PCE-
                 ADDRESS sub-TLVs where each sub-TLV identifies an 
                 alternate PCE that can perform the same path
                 computational functions as a given primary PCE
                 when the given PCEfails.  
               
   The ALTERNATE-PCES sub-TLV if present MUST include at least 
   one PCE-ADDRESS sub-TLV. 
    

3.1.2.2 PRIMARY-PCES sub-TLV 
 
   The PRIMARY-PCES sub-TLV specifies the set of primary PCEs 
   for which the given PCE acts as an alternate PCE for path 
   computation purposes. When any of the primary PCEs in the 
   set fails the alternate PCE can be chosen for the same kind 
   of path computation functions as the primaries do. It 
   contains a set of one or more PCE-ADDRESS sub-TLVs where 
   each sub-TLV is used to identify a primary PCE. This is an 
   optional sub-TLV and one or more such instances MAY be 
   included in the PCED TLV. 
 
 
   The PRIMARY-PCES sub-TLV 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  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |              Type             |             Length            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   //                     PCE-ADDRESS sub-TLVs                    //
 

Vijayanand, et al.          October 2006                   [page 8 ] 
 
 INTERNET DRAFT  BGP extensions for PCE discovery     October 2006 
 
 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 
 
        Type     To be assigned by IANA (suggested value=6)  
        Length   Variable. 
        Value    This comprises a set of one or more PCE-
                 ADDRESS sub-TLVs where each sub-TLV identifies a 
                 primary PCE for which the given PCE represents an 
                 alternate PCE with the same kind of path computational 
                 capabilities as the primary.  
                  
   The PRIMARY-PCES sub-TLV if present MUST include at least 
   one PCE-ADDRESS sub-TLV. 
 
    
    
4. BGP Specific Procedures 
    
      The PCE discovery TLV and PCE Status TLV will be carried 
   in the MP-Reach NLRI of BGP update messages. BGP speakers 
   shall encode this in a new <AFI,SAFI> value <TBD,TBD> . The 
   new <AFI,SAFI> value shall be advertised in the list of 
   address families supported by the speaker in its open 
   message. When the PCE is first advertised or when its 
   capabilities, scope changes the PCE Discovery TLV and its 
   relevant sub TLVs will be carried in the MP-REACH-NLRI. 
   When the PCE experiences congestion or when its congestion 
   status changes it can originate only the PCE status TLV, 
   containing the Address sub-TLV and congestion status sub-
   TLV in the MP-REACH-NLRI. Since the congestion status 
   changes more frequently than the PCE capabilities, the PCE 
   status TLV is likely to be sent more frequently in the MP-
   REACH-NLRI. 
    
       Multiple PCE discovery TLV and PCE status TLV may be 
   carried in the same MP-REACH NLRI if they share the same 
   next-hop in the Multi-protocol extensions attribute. 
   Multiple MP-REACH-NLRI may be sent in the same update 
   message when they share the same AS-path attributes.  
         
       The PCE information can be directly injected into BGP 
   by configuration or the PCE information carried by the IGP( 
   OSPF or ISIS) as in [PCE-DISCO-IGP] can be redistributed 
   into BGP through suitable configuration.  Since BGP may not 


Vijayanand, et al.        October 2006                   [page 9 ] 
 
 INTERNET DRAFT   BGP extensions for PCE discovery   October 2006 
 
 
   be used in all the routers the PCE information carried in 
   BGP can be redistributed selectively into the IGP so that 
   all the potential PCCs can discover the PCEs.  
    
      When an administrator or operator deactivates the PCE 
   the corresponding PCE information has to be withdrawn. This 
   can be accomplished by sending the PCE discovery TLV in the 
   MP-UNREACH-NLRI attribute of the BGP Update message.   
    
       The PCE information can be distributed across AS 
   boundaries using E-BGP sessions. BGP policy can be used to 
   control the import and export of PCE information similar to 
   existing controls over the distribution of normal BGP 
   routes.The discovery information corresponding to a PCE 
   typically needs to be distributed only to a few neighbouring
   ASes.

       The discovery information about a PCE can be uniquely
   identified from the Address sub-TLV which is carried in both 
   the PCE Discovery TLV and PCE Status TLV. When the same PCE 
   discovery information is received from multiple BGP peers
   the local BGP speaker shall select one of them using its
   local BGP decision process applied on the AS-Path attributes.
   This would result in consistently selecting the PCE discovery
   information from one of the peers for a given policy
   configuration, thereby any stale information would not be
   injected into the PCE. The BGP speaker shall store only the
   selected PCE discovery information and propagate it to its
   peers.

       The Nexthop carried in the MP-REACH-NLRI of the PCE 
   discovery information MAY be used to reach the PCE if the
   PCE address is not advertised as a route in the BGP IPv4
   update messages.

     
        
4.1 Encoding PCE TLVs in MP-REACH-NLRI 
    
       The PCE information is carried in the NLRI of the 
   Multiprotocol extensions attribute described in [MP-BGP]. 
   The Address Family Identifier (AFI) and Subsequent Address 
   Identifier(SAFI) will be set to <TBD,TBD>. The next hop 
   field will be filled in as per usual BGP processing rules 
   to enable reachability to the PCE. The next hop address 
   will belong to the same family( IPv4 or IPv6) as the 
   address family in the PCE Discovery TLV. 
    
       The Network Layer Reachability Information will be 
   encoded as < Length, List of TLV >. 
    
        
        
Vijayanand, et al.          October 2006                  [page 10 ] 
 
 INTERNET DRAFT   BGP extensions for PCE discovery   October 2006 
 


         +---------------------------+ 
         |   Length (2 octets)       | 
         +---------------------------+ 
         |   List of TLVs(variable)  | 
         +---------------------------+   
    
    
   The meaning of the fields is described as follows: 

   a) Length : 
       
         The length in bytes of the list of TLVs carried in 
      the NLRI 
    
   b) List of TLVs : 
 
               This contains a list of TLVs each of which can 
      be a PCE Discovery TLV or PCE Status TLV. The encoding 
      of the PCE discovery TLV and its sub-TLVs and the 
      encoding of the PCE status TLV will be same as that of 
      the corresponding OSPF PCE TLVs described in [PCE-DISCO-
      IGP] with the extensions proposed in this document 
 

 
4.2 Encoding PCE Discovery TLVs in MP-UNREACH-NLRI 
    
       The PCE information is carried in the NLRI of the 
   Multiprotocol extensions attribute. The Address Family 
   Identifier (AFI) and Subsequent Address Identifier(SAFI) 
   will be set to <TBD,TBD>.  
    
       The Network Layer Reachability Information will be 
   encoded as < Length, List of TLV >. 
    
         +---------------------------+ 
         |   Length (2 octets)       | 
         +---------------------------+ 
         |   List of TLVs(variable)  | 
         +---------------------------+   
    
    
    
   The meaning of the fields is described as follows: 
        
   c) Length : 
       
         The length in bytes of the list of TLVs carried in 
      the NLRI 
    
    
Vijayanand, et al.        October 2006                  [page 11 ] 
 
 INTERNET DRAFT    BGP extensions for PCE discovery   October 2006 
 

   d) List of TLVs : 
    
               This contains a list of PCE Discovery TLVs. The 
      PCE discovery TLV will contain the PCE-address-sub-TLV 
      defined in [PCE-DISCO-IGP] corresponding to the PCE 
      whose information is withdrawn. 
     


5. Interoperability Considerations 
    
       BGP speakers which support this feature shall advertise 
   the <AFI,SAFI> corresponding to the PCE Information in the 
   list of address families supported by the speaker. This can  
   be advertised in the Capabilities Optional parameter[BGP-
   CAP] of the open message sent to the peer. A BGP speaker 
   shall not advertise PCE information to a speaker which does 
   not support the <AFI,SAFI> as advertised in its 
   capabilities. 
    
    
6. Acknowledgements 
    
      The authors wish to place on record their sincere 
   gratitude for the support extended by Balaji Radhakrishnan 
   during this work. 
    
    
7. IANA Considerations 
    
        IANA is requested to assign a separate SAFI number to 
     be used in the MP-REACH-NLRI attribute for PCE discovery. 
    
    
8. Security Considerations 
    
      This extension to BGP does not change the underlying 
   security issues inherent in the existing BGP [Heffernan]. 
    
9. Authors' Addresses 
    
    
     Vijayanand C 
     HCL Technologies Ltd. 
     No.184, NSK Salai, 
     Vadapalani,Chennai -26 
     India. 
     Phone : 91 44 23728366 ext:1357 
     Email : vijayc@hcl.in 
    
    
Vijayanand, et al.          October 2006                  [page 12 ] 
 
 INTERNET DRAFT    BGP extensions for PCE discovery   October 2006 



     Somen Bhattacharya, 
     Avici Systems. 
     101 Billerica Avenue 
     N. Billerica, MA 01862 
     USA 
     Phone: 1 978 964 2606 
     Email: somen@avici.com  
    

     Prasanna Kumar, 
     Avici Systems. 
     101 Billerica Avenue 
     N. Billerica, MA 01862 
     USA 
     Phone: 1 978 964 2297 
     Email: pkumar@avici.com  



10. References

10.1 Normative References 
        

 
    [RFC-WORDS]  Bradner, S.,"Key words for use in RFCs to Indicate 
                 Requirement Levels", RFC 2119, March 1997.  
 
    [RFC2119]  Bradner, S., "Key words for use in RFCs to 
               Indicate Requirement Levels", BCP 14,
               RFC 2119, March 1997.  
         
    [PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path 
               Computation Element (PCE) Architecture",
               draft-ietf-pce-architecture, work in progress. 
    
    [PCE-DISC-REQ]
               J.L. Le Roux,"Requirements for Path 
               Computation   Element (PCE) Discovery",
               draft-ietf-pce-discovery-reqs-05.txt,
               work in progress. 
    
    [PCE-DISCO-IGP]
               J.L. Le Roux, J.P. Vasseur, Yuichi 
               Ikejir,  Raymond Zhang,
               " IGP Protocol extensions for Path 
               computation Element Discovery",
               draft-ietf-pce-disco-proto-igp,
               workin progress,JUne 2006.
    
 
Vijayanand, et al.         October 2006                  [page 13 ] 
 
 INTERNET DRAFT    BGP extensions for PCE discovery    October 2006 



    [BGP-CAP]  R. Chandra, J. Scudder, "Capabilities 
               advertisement with BGP-4", RFC3392,November 2002.
    
    [MP-BGP]   T.Bates,Y.Rekhter,R.Chandra,D.Katz," 
               Multiprotocol Extensions for BGP-4",RFC2858,
               June 2000. 
    
    [Heffernan]  Heffernan, A., "Protection of BGP Sessions 
                 via the TCP MD5 Signature Option", RFC 2385,
                 August 1998. 
        


   Intellectual Property Statement  
     
   The IETF 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 this 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. Information on the procedures with respect to rights
   in RFC documents can be found in BCP 78 and BCP 79.  
      
   Copies of IPR 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 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 this standard.  Please address the
   information to the IETF at ietf-ipr@ietf.org.  
     
   Disclaimer of Validity  
     
   This document and the information contained herein are 
   provided on an "AS IS" basis and THE CONTRIBUTOR, THE
   ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY),
   THE INTERNET SOCIETY 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 
   IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
   PARTICULAR PURPOSE.  
     
Vijayanand, et al.        October 2006                  [page 14 ] 


 INTERNET DRAFT  BGP extensions for PCE discovery  October 2006 
 
 
   Full Copyright Statement 
 
   Copyright (C) The Internet Society (2006). 
 
   This document is subject to the rights, licenses and 
   restrictions contained in BCP 78, and except as set
   forth therein, the authors retain all their rights. 
 
   This document and the information contained herein are 
   provided on an "AS IS" basis and THE CONTRIBUTOR, THE
   ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY),
   THE INTERNET SOCIETY 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 
   IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
   PARTICULAR PURPOSE. 
 
 
    




















Vijayanand, et al.           October 2006                  [page 15 ]