One document matched: draft-vasseur-isis-caps-01.txt

Differences from draft-vasseur-isis-caps-00.txt


 
  ISIS                                                        
  Internet Draft                             Jean-Philippe Vasseur 
                                                 Stefano Previdi 
                                                     Mike Shand 
                                                   Les Ginsberg 
                                                  Cisco Systems 
                                                              
  Document: draft-vasseur-isis-caps-01.txt                         
  Expires: August 2004                              February 2004 
   
   
          IS-IS extensions for advertising router information 
                                 
                   draft-vasseur-isis-caps-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 [i].  
   
  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 document defines a new optional IS-IS TLVs named CAPABILITY, 
  formed of multiple sub-TLVs, which allows a router to announce its 
  capabilities within an IS-IS level or the entire routing domain. 
   
   
Conventions used in this document 
   
  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 [ii]. 
 
 
Vasseur et al.         Expires û August 2004              [Page 1] 

                 draft-vasseur-isis-caps-01.txt      February 2004 
 
 
   
Table of Contents 
   
  1. Introduction...................................................2     Field Code
  2. IS-IS CAPABILITY TLV...........................................2     Field Code
  3. Element of procedure...........................................3     Field Code
  4. Interoperability with routers not supporting the capability TLV.4     Field Code
  5. Security considerations........................................4 
  6. Acknowledgment.................................................4     Field Code
  7. Intellectual Property Considerations...........................4     Field Code
  8. References.....................................................5     Field Code
  Normative references..............................................5 
                                                                  Field Code
  Informative references............................................5 
  9. Author's Addresses.............................................5     Field Code
                                                                 Field Code
                                                                  Field Code
1. 
  Introduction 
   
  There are several situations where it is useful for the IS-IS routers 
  to learn the capabilities of the other routers of their IS-IS level, 
  area or routing domain. Some applications are described in [IS-IS-TE-
  CAP] but for the sake of illustration, one can briefly describes 
  three of them related to MPLS Traffic Engineering. 
   
     - Path Computation Element (PCE) discovery: in several situations, 
    the Traffic Engineering Label Switched (TE LSP) path is computed by 
    a Label Switch Router (LSR) it is not the head-end for (e.g an ABR 
    or an ASBR respectively in the context of inter-area and inter-AS 
    MPLS TE ([INTER-AREA-AS]). In such a case, having the ability to 
    discover the capability of an router to act as a PCE is extremely 
    useful in term of ease of operation, capacity to react to PCE 
    failure, load sharing between a set of PCEs, etc 
    - Mesh-group: the setting up of a mesh of TE LSPs requires some 
    significant configuration effort. [IS-IS-TE-CAP] proposes an auto-
    discovery mechanism whereby every LSR of a mesh advertises its 
    mesh-group membership by means of IS-IS extensions. 
    - Point to Multi-point TE LSP (P2MP LSP). A specific sub-TLV ([IS-
    IS-TE]) allows an LSR to advertise its capabilities to be a ôbranch 
    nodeö of a P2MP TE LSP (see [P2MP] and [P2MP-reqs]). 
     
  The capability mentioned above lead to the specification of specific 
  TLVs carried within the CAPABILITY TLV defined in this document. 
   
  Note that the examples above are provided for the sake of 
  illustration. This document proposes a generic capability 
  advertisement mechanism not limited to MPLS Traffic Engineering. 
   
2. 
  IS-IS CAPABILITY TLV 
   
 
 
Vasseur et al.         Expires û August 2004              [Page 2] 

                 draft-vasseur-isis-caps-01.txt      February 2004 
 
 
  The IS-IS CAPABILITY TLV is composed of 1 octet for the type, 1 octet 
  specifying the TLV length, 1 octet of bit flags and a variable length 
  value field, starting with 4 octets of Router ID. 
   
  CODE: To be assigned by IANA 
  LENGTH: Variable (1 octet) 
  VALUE: 
    Router ID (4 octets) 
    Flags (1 octet) 
    Set of optional sub-TLVs (0-249 octets) 
   
  Flags 
   
    +-+-+-+-+-+-+-+-+ 
    |S|U|           | 
    +-+-+-+-+-+-+-+-+ 
   
  Currently two bit flags are defined. 
   
  S bit: when set, the IS-IS CAPABILITY TLV MUST be flooded across the 
  entire routing domain; hence, according to the element of procedure 
  defined in section 3, the CAPABILITY TLV MUST be leaked between IS-IS 
  levels or multiple areas of the same IS-IS level by L1L2 routers that 
  support the CAPABILITY TLV. 
   
  U bit: the U bit MUST be set each time the CAPABILITY TLV is leaked 
  into another IS-IS level or another area of the same IS-IS level. 
  When set, the U bit MUST not be changed by any other router. 
   
  The CAPABILITY TLV is OPTIONAL. As specified in section 3, more than 
  one CAPABILITY TLVs may be present. 
   
3. 
  Element of procedure 
   
  In case of capabilities with different scopes, a router MUST include 
  two CAPABILITY TLVs, each TLV carrying the set of sub-TLVs with the  
  same flooding scope. For instance, if a router advertises two 
  capabilities C1 and C2 respectively with an area/level scope and 
  routing domain scope, C1 and C2 being specified by their respective 
  sub-TLV(s), the router MUST include two CAPABILITY TLVs: 
   
     - One CAPABILITY TLV with the S flag cleared carrying the sub-
    TLV(s) relative to C1. The CAPABILITY TLV MUST NOT be leaked into 
    other level or areas of the same level. 
   
     - One CAPABILITY TLV with the S flag set carrying the sub-TLV(s) 
    relative to C2. This CAPABILITY TLV MUST be leaked into other IS-IS 
    levels or areas or the same level after having set the U bit. Other 
    sub-TLVs MUST be unchanged during the leaking procedure. 
 
 
Vasseur et al.         Expires û August 2004              [Page 3] 

                 draft-vasseur-isis-caps-01.txt      February 2004 
 
 
     
  A router receiving a CAPABILITY TLV with the U flag set MUST NOT leak 
  the CAPABILITY TLV into another ISIS level or areas. This prevents 
  TLV looping. 
 
4. 
  Interoperability with routers not supporting the capability TLV. 
 
  There is no interoperability issue as a router not supporting the 
  CAPABILITY TLV MUST just silently ignore the TLV(s) and continue the 
  LSP processing. If just a subset of the sub-TLVs carried within the 
  CAPABILITY TLV are supported, then the not supported sub-TLV MUST be 
  silently ignored.  
   
5. 
  Security considerations 
 
  No new security issues are raised in this document. 
   
6. 
  Acknowledgment 
   
  The authors would like to thank Jean-Louis Le Roux and Paul Mabey for 
  their useful comments. 
   
7. 
  Intellectual Property Considerations 
   
  The IETF takes no position regarding the validity or scope of any 
  intellectual property 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; neither does it represent that it 
  has made any effort to identify any such rights. Information on the 
  IETF's procedures with respect to rights in standards-track and 
  standards-related documentation can be found in BCP-11. Copies of 
  claims of rights made available for publication 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 implementors or users of this specification can 
  be obtained from the IETF Secretariat. 
   
  The IETF invites any interested party to bring to its attention any 
  copyrights, patents or patent applications, or other proprietary 
  rights which may cover technology that may be required to practice 
  this standard. Please address the information to the IETF Executive 
  Director. 
   
  The IETF has been notified of intellectual property rights claimed in 
  regard to some or all of the specification contained in this 
  document.  For more information consult the online list of claimed 
  rights. 
 
 
Vasseur et al.         Expires û August 2004              [Page 4] 

                 draft-vasseur-isis-caps-01.txt      February 2004 
 
 
 
 
8. 
  References 
 
Normative references 
 
  [RFC] Bradner, S., "Key words for use in RFCs to Indicate Requirement 
  Levels," RFC 2119. 
   
  [IS-IS] "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)",       
  ISO 10589. 
   
  [IS-IS-IP] Callon, R., RFC 1195, "Use of OSI IS-IS for routing in 
  TCP/IP and dual environments", RFC 1195, December 1990. 
   
  [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 
  Engineering", draft-ietf-isis-traffic-04.txt (work in progress) 
   
Informative references 
 
  [IS-IS-TE-CAP] JP Vasseur, S. Previdi, JL. Le Roux, ôIS-IS MPLS 
  Traffic Engineering capabilitiesö, draft-vasseur-ccamp-isis-te-caps-
  00.txt, work in progress. 
   
  [P2MP] S. Yasukawa et al. ½ Extended RSVP TE for point-to-multipoint 
  LSP tunnelsö, draft-yasukawa-mpls-rsvp-p2mp-03.txt, work in progress. 
   
  [P2MP-reqs] S. Yasukawa et al. ½ Requirements for point to multipoint 
  extension to RSVP ©, draft-ietf-mpls-p2mp-requirement-01.txt, work in 
  progress. 
   
  [INTER-AREA-AS] Vasseur and Ayyangar, ôInter-area and Inter-AS MPLS 
  Traffic Engineeringö, draft-vasseur-ayyangar-inter-area-AS-TE-00.txt, 
  work in progress. 
   
 
9. 
  Author's Addresses 
   
     Jean-Philippe Vasseur 
     CISCO Systems, Inc. 
     300 Beaver Brook 
     Boxborough, MA 01719 
     USA 
     Email: jpv@cisco.com                                           Field Code
   
     Stefano Previdi 
     CISCO Systems, Inc. 
 
 
Vasseur et al.         Expires û August 2004              [Page 5] 

                 draft-vasseur-isis-caps-01.txt      February 2004 
 
 
     Via Del Serafico 200 
     00142 - Roma 
     ITALY 
     Email: sprevidi@cisco.com                                       Field Code
   
     Mike Shand  
     Cisco Systems  
     250 Longwater Avenue,  
     Reading,  
     Berkshire,  
     RG2 6GB  
     UK  
     Phone: +44 208 824 8690  
     Email: mshand@cisco.com                                         Field Code
   
     Les Ginsberg  
     Cisco Systems  
     510 McCarthy Blvd.  
     Milpitas, Ca. 95035 USA  
     Email: ginsberg@cisco.com                                       Field Code
    
       
  Full Copyright Statement 
   
     Copyright (C) The Internet Society (2004). All Rights 
     Reserved. 
   
     This document and translations of it may be copied and 
     furnished to others, and derivative works that comment on 
     or otherwise explain it or assist in its implementation may 
     be prepared, copied, published and distributed, in whole or 
     in part, without restriction of any kind, provided that the 
     above copyright notice and this paragraph are included on 
     all such copies and derivative works.  However, this 
     document itself may not be modified in any way, such as by 
     removing the copyright notice or references to the Internet 
     Society or other Internet organizations, except as needed 
     for the purpose of developing Internet standards in which 
     case the procedures for copyrights defined in the Internet 
     Standards process must be followed, or as required to 
     translate it into languages other than English. 
   
     The limited permissions granted above are perpetual and 
     will not be revoked by the Internet Society or its 
     successors or assigns. This document and the information 
     contained herein is provided on an "AS IS" basis and THE 
     INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 
     DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 
     NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
 
 
Vasseur et al.         Expires û August 2004              [Page 6] 

                 draft-vasseur-isis-caps-01.txt      February 2004 
 
 
     HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
     WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 
     PURPOSE. 
                  
                    
 
 





































 
 
Vasseur et al.         Expires û August 2004              [Page 7] 


PAFTECH AB 2003-20262026-04-22 14:47:47