[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

   ISIS WG
   Internet Draft                             Jean-Philippe Vasseur(Ed)
                                                    Cisco Systems, Inc.
                                                     Rahul Aggarwal(Ed)
                                                       Juniper Networks
                                                       Naiming Shen(Ed)
                                                       Redback Networks

   Document: draft-vasseur-isis-caps-02.txt
   Expires: January 2005                                      July 2004


            IS-IS extensions for advertising router information

                      draft-vasseur-isis-caps-02.txt


Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or IPR claims of which I am aware have been disclosed, and any
   of which I become aware will be disclosed, in accordance with RFC
   3668.

   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.




Vasseur et al.                                                [Page 1]

draft-vasseur-isis-caps-02.txt                               July 2004

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

Table of Contents

   1. Introduction...................................................2
   2. IS-IS Router CAPABILITY TLV....................................3
   3. Element of procedure...........................................4
   4. Interoperability with routers not supporting the capability TLV.4
   5. Security considerations........................................5
   6. Acknowledgment.................................................5
   7. Intellectual Property Considerations...........................5
   8. References.....................................................6
   Normative references..............................................6
   Informative references............................................6
   9. Author's Addresses.............................................6


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]. For the sake of illustration, three examples related to MPLS
   Traffic Engineering are described here:

     1. Path Computation Element (PCE) discovery ([INTER-DOMAIN-PATH-
     COMP]): in several situations, the Traffic Engineering Label
     Switched (TE LSP) path is computed by a Label Switch Router (LSR)
     which is not the head-end for that LSP (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 a 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 and so on.

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

     3. Point to Multi-point TE LSP (P2MP LSP). A specific sub-TLV ([IS-
     IS-TE]) allows an LSR to advertise its Point To Multipoint
     capabilities ([P2MP] and [P2MP-REQS]).

   The capabilities mentioned above require the specification of new
   sub-TLVs carried within the CAPABILITY TLV defined in this document.


Vasseur et al.                                                [Page 2]

draft-vasseur-isis-caps-02.txt                               July 2004


   Note that the examples above are provided for the sake of
   illustration. This document proposes a generic capability advertising
   mechanism not limited to MPLS Traffic Engineering.

   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. The
   applications mentioned above require the specification of new sub-
   TLVs carried within the CAPABILITY TLV defined in this document.

   Definition of these sub-TLVs is outside the scope of this document.


2. IS-IS Router CAPABILITY TLV

   The IS-IS Router 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,
   indicating the source of the TLV, and followed by 1 octet of flags. A
   set of optional sub-TLVs may follow the flag field.

   TYPE: 242 (To be assigned by IANA)
   LENGTH: from 5 to 255
   VALUE:
     Router ID (4 octets)
     Flags (1 octet)
     Set of optional sub-TLVs (0-250 octets)

   Flags

             0 1 2 3 4 5 6 7
             +-+-+-+-+-+-+-+-+
             | Reserved  |D|S|
             +-+-+-+-+-+-+-+-+

   Currently two bit flags are defined.

   S bit (0x01): If the S bit is set(1), the IS-IS Router CAPABILITY TLV
   MUST be flooded across the entire routing domain. If the S bit is not
   set(0), the TLV MUST NOT be leaked between levels. This bit MUST NOT
   be altered during the TLV leaking.

   D bit (0x02): When the IS-IS Router CAPABILITY TLV is leaked from
   level-2 to level-1, the D bit MUST be set. Otherwise this bit MUST be
   clear. IS-IS Router capability TLVs with the D bit set MUST NOT be
   leaked from level-1 to level-2. This is to prevent TLV looping.




Vasseur et al.                                                [Page 3]

draft-vasseur-isis-caps-02.txt                               July 2004

   The Router CAPABILITY TLV is OPTIONAL. As specified in section 3,
   more than one Router CAPABILITY TLVs from the same source MAY be
   present.

   This document does not specify how an application may use the Router
   Capability TLV and such specification is outside the scope of this
   document.

3. Element of procedure

   In case of advertising capabilities with different flooding scopes, a
   router MUST originate a minimum of two Router CAPABILITY TLVs, each
   TLV carrying the set of sub-TLVs with the same flooding scope. For
   instance, if a router advertises two sets of capabilities C1 and C2
   with an area/level scope and routing domain scope respectively, C1
   and C2 being specified by their respective sub-TLV(s), the router
   MUST originate two Router CAPABILITY TLVs:

      - One Router CAPABILITY TLV with the S flag cleared carrying the
     sub-TLV(s) relative to C1. This Router CAPABILITY TLV MUST NOT be
     leaked into another level.

      - One Router CAPABILITY TLV with the S flag set carrying the sub-
     TLV(s) relative to C2. This Router CAPABILITY TLV MUST be leaked
     into other IS-IS levels. When the TLV is leaked from level-2 to
     level-1, the D bit MUST be set in the level-1 LSP advertisement.

   When leaking Capability TLVs downward from Level-2 into Level-1, if
   the originator of the TLV is a Level-1 router in another area, it is
   possible that multiple copies of the same TLV may be received from
   multiple L2 routers in the originating area. To prevent a router from
   leaking multiple copies of the same TLV, the router performing the
   downward leaking MUST check for such duplication by comparing the
   contents of the TLVs.

   When leaking Capability TLVs received from other systems, the router
   performing the leaking MUST only leak a TLV if the system advertising
   the TLV (which may or may not be the system which originated the TLV)
   is reachable via Level-x paths, where "x" is the level (1 or 2) in
   which the sending system advertised the TLV.

4. Interoperability with routers not supporting the capability TLV.

   Routers which do not support the Router CAPABILITY TLV MUST silently
   ignore the TLV(s) and continue processing other TLVs in the same LSP.
   Routers which do not support specific sub-TLVs carried within a
   Router CAPABILITY TLV MUST silently ignore the unsupported sub-TLVs
   and continue processing those sub-TLVs in the Router CAPABILITY TLV
   which are supported. How partial support may impact the operation of



Vasseur et al.                                                [Page 4]

draft-vasseur-isis-caps-02.txt                               July 2004

   the capabilities advertised within the Router CAPABILITY TLV is
   outside the scope of this document.

   In order for Router CAPABILITY TLVs with domain-wide scope originated
   by L1 Routers to be flooded across the entire domain at least one
   L1/L2 Router in every area of the domain SHOULD support the Router
   CAPABILITY TLV.

   If leaking of the CAP TLV is required, the entire CAP TLV MUST be
   leaked into another level even though it may contain some of the
   unsupported sub-TLVs.

5. Security considerations

   No new security issues are raised in this document.

6. Acknowledgment

   The authors would like to thank Dave Ward, Jean-Louis Le Roux,
   Paul Mabey and Andrew Partan for their useful comments.

7. Intellectual Property Considerations

   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.

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.



Vasseur et al.                                                [Page 5]

draft-vasseur-isis-caps-02.txt                               July 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., "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", RFC 3784, June 2004.

Informative references

   [TE-CAP], JP Vasseur, JL. Le Roux et al. ææRouting extensions for
   discovery of TE router informationÆÆ, draft-vasseur-ccamp-te-router-
   info-00.txt, work in progress.

   [IS-IS-TE-CAP] JP Vasseur, S. Previdi, Paul Mabey and JL. Le Roux,
   ææIS-IS MPLS Traffic Engineering capabilitiesÆÆ, draft-vasseur-isis-te-
   caps-00.txt, work in progress.

   [P2MP] R. Aggarwal,D. Papadimitriou,S. Yasukawa, et. al. "Extensions
   to RSVP-TE for point-to-multipoint TE LSPs", draft-raggarwa-mpls-
   rsvp-te-p2mp-00.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.

   [INT-DOMAIN-FRWK] Farrel, A., Vasseur, J.P., Ayyangar, A., "A
   Framework for Inter-Domain MPLS Traffic Engineering", draft-farrel-
   ccamp-inter-domain-framework-01.txt, work in progress.

   [INTER-DOMAIN-PATH-COMP] Vasseur and Ayyangar, ææInter-domain Traffic
   Engineering LSP path computation methodsÆÆ, draft-vasseur-inter-
   domain-path-comp-00.txt, work in progress.


9. Author's Addresses

   Jean-Philippe Vasseur


Vasseur et al.                                                [Page 6]

draft-vasseur-isis-caps-02.txt                               July 2004

   CISCO Systems, Inc.
   300 Beaver Brook
   Boxborough, MA 01719
   USA
   Email: jpv@cisco.com

   Stefano Previdi
   CISCO Systems, Inc.
   Via Del Serafico 200
   00142 - Roma
   ITALY
   Email: sprevidi@cisco.com

   Mike Shand
   Cisco Systems
   250 Longwater Avenue,
   Reading,
   Berkshire,
   RG2 6GB
   UK
   Email: mshand@cisco.com

   Les Ginsberg
   Cisco Systems
   510 McCarthy Blvd.
   Milpitas, Ca. 95035 USA
   Email: ginsberg@cisco.com

   Acee Lindem
   Redback Networks
   350 Holger Way
   San Jose, CA 95134
   e-mail: acee@redback.com

   Naiming Shen
   Redback Networks
   350 Holger Way
   San Jose, CA 95134
   e-mail: naiming@redback.com

   Rahul Aggarwal
   Juniper Networks
   1194 N. Mathilda Avenue
   San Jose, CA 94089
   e-mail: rahul@juniper.net

   Scott Shaffer
   e-mail: sshaffer@bridgeport-networks.com




Vasseur et al.                                                [Page 7]

draft-vasseur-isis-caps-02.txt                               July 2004

   Full Copyright Statement

   Copyright (C) The Internet Society (2004).  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.







































Vasseur et al.                                                [Page 8]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/