IS-IS Working Group JP Vasseur (Ed.) Cisco System Inc. Internet Draft JL Le Roux (Ed.) France Telecom Stefano Previdi Cisco Systems Paul Mabey Qwest Category: Standard Track Expires: January 2005 July 2004 IS-IS MPLS Traffic Engineering capabilities draft-vasseur-isis-te-caps-00.txt Status of this Memo 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. 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 document specifies IS-IS traffic engineering capability sub-TLVs related to various router MPLS Traffic Engineering capabilities. These sub-TLVs are carried within the IS-IS CAPABILITY TLV. Vasseur, Le Roux et al. [Page 1] Internet Draft draft-vasseur-isis-te-caps-00.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. Table of Contents 1. Terminology.....................................................2 2. Introduction....................................................3 3. TE Node Capability Descriptor sub-TLV format....................3 3.1. The DATA-PLANE-CAPABILITY sub-TLV.............................4 3.2. The CONTROL-PLANE-CAPABILITY sub-TLV..........................4 4. PCED sub-TLV format.............................................5 4.1. PCE-ADDRESS sub-TLV...........................................5 4.2. PCE-CAPABILITY sub-TLV........................................6 4.3. AS-DOMAIN sub-TLV.............................................7 5. TE-Mesh-Group sub-TLV format....................................8 6. Element of procedure............................................8 6.1. TE-NODE-CAP sub-TLV...........................................9 6.2. PCED sub-TLV..................................................9 6.3. TE-MESH-GROUP sub-TLV........................................11 7. Interoperability with routers not supporting the IS-IS MPLS TE capabilities......................................................12 8. Security considerations........................................12 9. Intellectual Property Statement................................12 10. References....................................................12 11. Authors' Address:.............................................13 1. Terminology Terminology used in this document LSR: Label Switch Router. PCE: Path Computation Element whose function is to compute the path of a TE LSP it is not the head-end for. The PCE may be an LSR or an offline tool not forwarding packet. PCC: Path Computation Client (any head-end LSR) requesting a TE LSP path computation to the Path Computation Element. TE LSP: Traffic Engineering Label Switched Path. TE LSP head-end: head/source of the TE LSP. TE LSP tail-end: tail/destination of the TE LSP. Intra-area TE LSP: TE LSP whose path does not transit across areas. Vasseur, Le Roux et al. [Page 2] Internet Draft draft-vasseur-isis-te-caps-00.txt July 2004 Inter-area TE LSP: A TE LSP whose path transits across at least two different IGP areas. Inter-AS MPLS TE LSP: A TE LSP whose path transits across at least two different ASes or sub-ASes (BGP confederations). 2. Introduction This document defines IS-IS protocol extensions and procedures for the advertisement TE node capabilities. The functional description of these extensions is defined in [TE-INFO], and is not repeated here. This document describes the usage of several IS-IS TE capabilities sub-TLVs: the PCED (PCE Discovery), the TE-MESH-GROUP and the TE- NODE-CAP sub-TLVs. These IS-IS TE capability sub-TLVs are carried within the IS-IS CAPABILITY TLV specified in [IS-IS-CAP]. Each sub-TLV defined in this document is composed of 1 octet for the type, 1 octet specifying the TLV length and a value field. The format of each sub-TLV is identical to the TLV format used by the Traffic Engineering Extensions to IS-IS [IS-IS-TE]. The TE-NODE-CAP sub-TLV is used for the advertisement of both control plane and data plane TE node capabilities. The TE-NODE-CAP sub-TLV is made of a set of non-ordered sub-TLVs each having the format as described above. The PCED sub-TLV is used for the advertisement of Path Computation Element capabilities. The PCED sub-TLV is made of a set of non-ordered sub-TLVs each having the format as described above. The TE-MESH-GROUP sub-TLV is used to advertise the desire to join/leave a given MPLS-TE mesh group. The TE-MESH-GROUP sub-TLV does not have any sub-TLV currently defined. 3. TE Node Capability Descriptor sub-TLV format This section specifies the sub-TLVs carried within the TE-NODE-CAP sub-TLV payload which define the TE node capabilities. The TE-NODE-CAP sub-TLV type is 1. The TE-NODE-CAP sub-TLV is made of various non ordered sub-TLVs. Currently two sub-TLVs are defined. TLV type Length Name 1 variable DATA-PLANE-CAPABILITY sub-TLV 2 variable CONTROL-PLANE-CAPABILITY sub-TLV Any non recognized sub-TLV MUST be silently ignored. Vasseur, Le Roux et al. [Page 3] Internet Draft draft-vasseur-isis-te-caps-00.txt July 2004 More sub-TLV could be added in the future to handle new capabilities. 3.1. The DATA-PLANE-CAPABILITY sub-TLV The DATA-PLANE-CAPABILITY is a series of bit flags and has a variable length. CODE: 1 LENGTH: Variable (N*8) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B|E| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TE-NODE-CAP sub-TLV format Two bits are currently defined: -B bit: When set this indicates that the LSR can act as a branch node on a P2MP LSP. -E bit: When set, this indicates that the LSR can act as a bud LSR on a P2MP LSP, i.e. and LSR that is both transit and egress. See [P2MP-REQ]) and [RSVP-P2MP] for more details on the usage of these bits. Note that more flags may be defined in the future. 3.2. The CONTROL-PLANE-CAPABILITY sub-TLV The CONTROL-PLANE-CAPABILITY is a series of bit flags and has a variable length. CODE: 2 LENGTH: Variable (N*8) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|G|P| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TE-NODE-CAP sub-TLV format Vasseur, Le Roux et al. [Page 4] Internet Draft draft-vasseur-isis-te-caps-00.txt July 2004 Currently three flags are defined: -M bit: If set this indicates that the LSR supports MPLS-TE signalling ([RSVP-TE]). -G bit: If set this indicates that the LSR supports GMPLS signalling ([RSVP-G]). -P bit: If set this indicates that the LSR supports P2MP MPLS-TE signalling ([RSVP-P2MP]). Note that more flags may be defined in the future. 4. PCED sub-TLV format This section specifies the sub-TLVs carried within the PCED sub-TLV payload which describes the PCE capabilities. The PCED sub-TLV type is 2. The PCED sub-TLV is made of various non ordered sub-TLVs defined below: TLV type Length Name 1 variable PCE-ADDRESS sub-TLV 2 8 PCE-CAPABILITY sub-TLV 3 8 AS-DOMAIN sub-TLV Any non recognized sub-TLV MUST be silently ignored and unchanged. 4.1. PCE-ADDRESS sub-TLV The PCE-ADDRESS sub-TLV specifies the IP address to be used to reach the PCE described by this PCED sub-TLV. This address will typically be a loop-back address that is always reachable, provided the router is not isolated. The PCE-ADDRESS sub-TLV is mandatory. PCE-ADDRESS sub-TLV type is 1, length is 4 octets for an IPv4 address and 20 octets for an IPv6 address, and the value is the PCE IPv4 or IPv6 address. CODE: 1 LENGTH: Variable (4 or 20) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | address-type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // PCE IP address // | | Vasseur, Le Roux et al. [Page 5] Internet Draft draft-vasseur-isis-te-caps-00.txt July 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PCE-ADDRESS sub-TLV format Address-type: 1 IPv4 2 IPv6 The PCE-ADDRESS sub-TLV MUST appear exactly once in the PCED sub-TLV originated by a router. The only exception is when the PCE has both an IPv4 and IPv6 address; in this case, two Path Computation Element address sub-TLVs might be inserted: one for the IPv4 address, one for the IPv6 address, in this order. 4.2. PCE-CAPABILITY sub-TLV The PCE-CAPABILITY sub-TLV is used by the PCE to signal its Path Computation Element capabilities. This could then be used by an LSR to select the appropriate PCE among a list of PCE candidates. This sub-TLV is optional. The PCE-CAPABILITY sub-TLV type is 2 and the length is 8 octets. CODE: 2 LENGTH: 4 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |D|M|P|A|I|L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PCE-CAPABILITY sub-TLV format The first 3 bits L, I and A defines the PCE scope for which the Path Computation Element is capable of performing the TE LSP path computation. L bit: Local scope. When set, this flag indicates that the PCE can compute paths for the IS-IS level the ISIS CAPABILITY TLV is flooded into (the PCE can compute TE LSP paths for intra-area TE LSPs). I bit: Inter-area scope. When set, the PCE can perform TE LSP path computation for inter-area TE LSPs but within the same AS. A bit: Multi-domain scope. When set, the PCE can perform path computation for inter-AS TE LSPs. In this case, the PCED sub-TLV MUST contain one or more AS-DOMAIN sub-TLV(s), each describing the domain for which the PCE can compute TE LSPs paths having their destination address in Vasseur, Le Roux et al. [Page 6] Internet Draft draft-vasseur-isis-te-caps-00.txt July 2004 the respective AS. Note that those flags are not exclusive (a PCE may set one or more flags). P bit: The notion of request priority allows a PCC to specify how urgent the request is, by setting a flag in the REQUEST_ID object of the Path computation request message. See [PATH-COMP] for more details. P=1: the PCE takes into account the ¬¬request priority¬¬ in its scheduling of the various requests. P=0: the PCE does not take the request priority into account. M bit M=1: the PCE is capable of computing more than one path obeying a set of specified constraints (in a single pass), provided that they exist. M=0: the PCE cannot compute more than one path in a single pass obeying a set of specified constraints. D bit The PCC may request the PCE 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. S D=1: the PCE is capable of computing diversely (link, node, SRLG) routed paths. D=0: the PCE 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. Note that for future capabilities, it may be desirable to introduce new flags or may be new sub-TLV to be carried in the PCED capability sub-TLV if the capability needs more than just a single flag to be described. 4.3. AS-DOMAIN sub-TLV When the PCE can perform path computation for an inter-AS TE LSP, the A bit of the PCE-CAPABILITY sub-TLV MUST be set. Moreover, one or more sub-TLVs MUST be included within the PCED sub-TLV, each sub-TLV identifying an AS number. Each AS-DOMAIN sub-TLV has the following form: CODE: 3 LENGTH: 4 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vasseur, Le Roux et al. [Page 7] Internet Draft draft-vasseur-isis-te-caps-00.txt July 2004 AS-DOMAIN sub-TLV format The AS-DOMAIN sub-TLV type is 3, length is 4 octets, and the value is the AS number identifying the AS for which the PCE can compute inter- AS TE LSP paths (TE LSP having their destination address in this AS). When coded on four bytes, 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 PCE can compute TE LSP path such that the destination address of the TE LSP belongs to this set of ASes. 5. TE-Mesh-Group sub-TLV format The TE-MESH-GROUP sub-TLV has the following format: CODE: 2 LENGTH: Variable (N*8 octets) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mesh-group-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tail-end address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tail-end name | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TE-MESH-GROUP sub-TLV format N is the number of mesh-groups. For each Mesh-group announced by an LSR, the TLV contains: - A mesh-group-number: identifies the mesh-group number, - A Tail-end address: user configurable IP address to be used as a tail-end address by other LSRs belonging to the same mesh-group. - A Tail-end name: 32-bits string which facilitates the TE LSP identification which can be very useful in inter-area/AS MPLS TE environments. 6. Element of procedure The sub-TLVs defined in this document are carried within the IS-IS CAPABILITY TLV defined in [IS-IS-CAP]. An IS-IS router MUST originate a new IS-IS LSP whenever the content of the any of the carried sub-TLV changes or whenever required by the regular IS-IS procedure (LSP refresh). Vasseur, Le Roux et al. [Page 8] Internet Draft draft-vasseur-isis-te-caps-00.txt July 2004 If the flooding scope of an MPLS Traffic Engineering capability is limited to an IS-IS level/area, the S flag of the CAPABILITY TLV MUST be cleared. Conversely,if the flooding scope of an MPLS Traffic Engineering capability is the entire routing domain, the S flag of the CAPABILITY TLV MUST be set. In both cases the flooding rules as specified in [IS-IS-CAP] apply. As specified in [IS-IS-CAP], a router may generate multiple IS-IS CAPABILITY TLVs within an IS-IS LSP with different flooding scopes. 6.1. TE-NODE-CAP sub-TLV The flooding scope is defined on a per capability basis. If the capability must be flooded within a single IS-IS area/level, the TE-NODE-CAP sub-TLV MUST be carried within a CAPABILITY TLV having the S flag cleared. Conversely, if the capability must be flooded throughout the entire routing domain, the TE-NODE-CAP sub-TLV MUST be carried within a CAPABILITY TLV having the S flag set. Capabilities with an identical flooding scope MUST be flooded within the same TE-NODE-CAP sub-TLV. 6.2. PCED sub-TLV If the PCE can compute an intra-area TE LSP path, the L bit of the PCE-CAPABILITY sub-TLV of the PCED TLV MUST be set. The PCED sub-TLV MUST be carried within a CAPABILITY TLV having the S flag cleared. If the PCE can compute an inter-area TE LSP path, the I bit of the PCE-CAPABILITY sub-TLV of the PCED TLV MUST be set. The PCED sub-TLV MUST be carried: - Within a CAPABILITY TLV having the S flag cleared if the PCE can compute an inter-area TE LSP path for the LSRs in the area(s) it resides in (for instance the PCE is an ABR computing an inter- area TE LSP path for its area). - Within a CAPABILITY TLV having the S flag set if the PCE can compute an inter-area TE LSP path for the whole domain. If the PCE can compute an inter-AS TE LSP path, the A bit of the PCE- CAPABILITY sub-TLV of the PCED TLV MUST be set and the PCED TLV MUST be carried within CAPABILITY TLV having the S flag set. Note: if the PCE can compute both intra and inter-area TE LSP paths, both the L and I bits of the PCE-CAPABILITY sub-TLV MUST be set. The flags are not exclusive. If the PCE can compute inter-as TE-LSPs path, both the A bit of the Vasseur, Le Roux et al. [Page 9] Internet Draft draft-vasseur-isis-te-caps-00.txt July 2004 PCED TLV MUST and the S bit of CAPABILITY TLV MUST be set. Example -----------------AS1----------------- R1(L1)------R3(L1L2)*-----R4(L1L2)*----| ------------ | | | | | | | S1(L1) | S2(L1) | ASBR1*(L1)--eBGP--ASBR2-| AS2 | | | | | | | R2(L1)------R5(L1L2)*-----R6(L1L2)-----| ------------ The areas contents are not detailed. Assumptions: - the * indicates a Path Computation Element capability - R3 is a PCE for level 1 only - R5 is a PCE for intra and inter-area TE LSP path computation for both levels - R4 is a PCE for inter-area TE LSP path computation only for both levels - S1 is a PCE for level 1 only - S2 is a PCE for the whole AS - ASBR1 is a PCE for inter-AS TE LSPs 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 PCED sub-TLV with: o The L bit of the PCE-CAPABILITY sub-TLV set, o The I and A bits of the PCE-CAPABILITY sub-TLV cleared. The S bit of the CAPABILITY TLV MUST be cleared. - S2 originates a level 2 LSP containing -an IS-IS CAPABILITY TLV with the S flag cleared carrying: a PCED TLV with: - The L, and I bits of the PCE-CAPABILITY sub-TLV set, - The A bit of the PCE-CAPABILITY sub-TLV cleared -an IS-IS CAPABILITY TLV with the S flag set carrying: a PCED TLV with -The I bit set -The L and A bit cleared - ASBR1 originates a level1 LSP containing a PCED TLV with: o The L and I bits of the PCE-CAPABILITY sub-TLV cleared, o The A bit of the PCE-CAPABILITY sub-TLV set, o One AS-domain sub-TLV within the PCED sub-TLV with AS number = AS2 The S bit of the CAPABILITY TLV MUST be set - R3 originates: Vasseur, Le Roux et al. [Page 10] Internet Draft draft-vasseur-isis-te-caps-00.txt July 2004 * a level 1 LSP containing - an IS-IS CAPABILITY TLV with the S flag cleared carrying: o a PCED TLV describing its own PCE capability with: - The L bit of the PCE-CAPABILITY sub-TLV set, - The I and A bits of the PCE-CAPABILITY sub-TLV cleared, - an IS-IS CAPABILITY TLV with the S flag set carrying: o the S2's PCED TLV (with I and A bit unchanged) o the ASBR1s PCED TLV (unchanged), leaked from level-2 LSP (S bit set). * a level 2 LSP including no PCED TLV - R5 originates: * a level1 LSP containing: - an IS-IS CAPABILITY TLV with the S flag cleared carrying: o a PCED TLV describing its own PCE capability with: - The L and I bits of the PCE-CAPABILITY sub-TLV set, - The A bit of the PCE-CAPABILITY sub-TLV cleared, - an IS-IS CAPABILITY TLV with the S flag set carrying: o the S2's PCED TLV (with the I, A and L bits of the PCE- CAPABILITY sub-TLV unchanged) o the ASBR1's PCED TLV (unchanged) * a level 2 LSP containing an IS-IS CAPABILITY TLV with the S flag cleared carrying: o a PCED sub-TLV describing its own PCED capability with: - Both the L and I bit of the PCE-CAPABILITY sub-TLV set, - The A bit of the PCE-CAPABILITY sub-TLV cleared. The receipt of an IS-IS LSP containing a new PCED TLV never triggers an SPF calculation. When a PCE is newly configured, the corresponding PCED TLV MUST be immediately flooded. When a PCE looses its capability or when one of its PCED capabilities changes, the IS-IS LSP MUST be immediately flooded. 6.3. TE-MESH-GROUP sub-TLV If the MPLS TE mesh-group is contained within a single IS-IS level (all the LSRs have their head-end and tail-end LSR within the same IS-IS level), the TE-MESH-GROUP sub-TLV MUST be carried within a CAPABILITY TLV having the S flag cleared. Conversely, if the MPLS TE mesh-group spans multiple IS-IS levels, the TE- MESH-GROUP sub-TLV MUST be carried within a CAPABILITY TLV having the S flag set. Vasseur, Le Roux et al. [Page 11] Internet Draft draft-vasseur-isis-te-caps-00.txt July 2004 7. Interoperability with routers not supporting the IS-IS MPLS TE capabilities There is no interoperability issue as a router not supporting the PCED, TE-MESH-GROUP or TE-NODE-CAP sub-TLVs SHOULD just silently ignore those sub-TLVs. 8. Security considerations No new security issues are raised in this document. 9. 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. 10. References Normative references [RFC] Bradner, S., "Key words for use in RFCs to indicate requirements levels", RFC 2119, March 1997. [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. [ISIS] "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol " ISO 10589. Vasseur, Le Roux et al. [Page 12] Internet Draft draft-vasseur-isis-te-caps-00.txt July 2004 [ISIS-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. [ISIS-CAP] Vasseur, J.P., Aggarwal, R., Shen, N. et al. "IS-IS extensions for advertising router information", draft-vasseur-isis- caps-02.txt, work in progress. [TE-INFO] Vasseur, J.P., Le Roux, J.L., et al., "Routing extensions for discovery of TE router information", draft-vasseur-ccamp-te- router-info-00.txt, work in progress. Informative References [ISIS-G] Kompella, K., Rekhter, Y., "IS-IS extensions in support of Generalized Multi-protocol Label Switching", draft-ietf-isis-gmpls- extensions-19.txt, work in progress. [INT-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J., "Requirements for inter-area MPLS Traffic Engineering", draft-ietf-tewg-interarea- mpls-te-req-02.txt, work in progress. [INT-AS-REQ] Zhang, R., Vasseur, J.P., "MPLS Inter-AS Traffic Engineering Requirements", draft-ietf-tewg-interas-mpls-te-req- 07.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. [P2MP-Req] Yasukawa, S., et. al., "Requirements for point-to- multipoint extension to RSVP-TE", draft-ietf-mpls-p2mp-requirement- 02.txt, work in progress. [RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP tunnels", RFC 3209, December 2001. [RSVP-G] Berger, L, et. al., "GMPLS Signaling RSVP-TE extensions", RFC 3473, January 2003. [RSVP-P2MP] Aggarwal, Papadimitriou, Yasukawa, et. al. "Extensions to RSVP-TE for point-to-multipoint TE LSPs", draft-dry-mpls-rsvp-te- p2mp-00.txt, work in progress. 11. Authors' Address: Jean-Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Vasseur, Le Roux et al. [Page 13] Internet Draft draft-vasseur-isis-te-caps-00.txt July 2004 Boxborough , MA - 01719 USA Email: jpv@cisco.com Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: jeanlouis.leroux@francetelecom.com Stefano Previdi Cisco Systems, Inc. Via Del Serafico 200 00142 - Roma ITALY Email: sprevidi@cisco.com Paul Mabey Qwest Communications 950 17th Street, Denver, CO 80202 USA Email: pmabey@qwest.com 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, Le Roux et al. [Page 14]