CCAMP Internet Draft Jean-Philippe Vasseur Stefano Previdi Cisco Systems Paul Mabey Qwest Jean-Louis Le Roux France Telecom Document: draft-vasseur-ccamp-isis-te- caps-00.txt Expires: August 2004 February 2004 IS-IS MPLS Traffic Engineering capabilities draft-vasseur-ccamp-isis-te-caps-00.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 proposes IS-IS traffic engineering capability sub-TLVs related to various MPLS Traffic Engineering capabilities. These sub- TLVs are carried within the IS-IS CAPABILITY TLV. Conventions used in this document Vasseur et al. Expires - - August 2004 [Page 1] draft-vasseur-ccamp-isis-te-caps-00.txt February 2004 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. Where does this draft fit in the picture of the CCAMP and ISIS WG? ..................................................................2 2. Terminology....................................................2 3. Introduction...................................................3 4. PCED sub-TLV...................................................4 4.1 Description................................................4 4.2 PCED sub-TLV format........................................4 4.2.2 PCE-ADDRESS sub-TLV.........................................4 4.2.3 PCE-CAPABILITY sub-TLV......................................5 4.2.4 AS-DOMAIN sub-TLV...........................................7 5. TE-MESH-GROUP sub-TLV..........................................7 5.1 Introduction...............................................7 5.2 TE-MESH-GROUP sub-TLV format...............................8 6. TE-NODE-CAP sub-TLV............................................9 6.1 Introduction...............................................9 6.2 TE-NODE-CAP sub-TLV format.................................9 7. Element of procedure...........................................9 7.1 PCED sub-TLV..............................................10 7.2 TE-MESH-GROUP sub-TLV.....................................12 7.3 TE-NODE-CAP sub-TLV.......................................12 8. Interoperability with routers non supporting this capability..13 9. Security considerations.......................................13 10. Intellectual Property Considerations.........................13 11. References...................................................14 Normative references.............................................14 Informative references...........................................14 12. Author's Addresses...........................................14 1. Where does this draft fit in the picture of the CCAMP and ISIS WG? This document specifies IS-IS extensions in support of MPLS Traffic Engineering. It will be discussed in the CCAMP Working Group with a review in the ISIS Working Group. 2. 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 (e.g Vasseur et al. Expires - - August 2004 [Page 2] draft-vasseur-ccamp-isis-te-caps-00.txt February 2004 ABR or ASBR) in the context of some distributed PCE-based path computation scenario as defined in [INTER-AREA-AS] or a centralized Path Computation Element 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 head-end and tail-end reside in the same area, and whose path does not transit across areas/levels. Inter-area MPLS TE LSP: A TE LSP where the head-end LSR and tail-end LSR do not reside in the same area or both the head-end and tail end LSR reside in the same area but the TE LSP transits one or more different areas along the path. Inter-AS MPLS TE LSP: A TE LSP whose head-end LSR and tail-end LSR do not reside within the same Autonomous System (AS), or whose head-end LSR and tail-end LSR are both in the same AS but the TE LSPªs path may be across different ASes. Note that this definition also applies to TE LSP whose Head-end and Tail-end LSRs reside in different sub- ASes (BGP confederations). 3. Introduction 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 PCED sub-TLV type is 1. 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 type is 2. The TE-MESH-GROUP sub-TLV does not have any sub-TLV currently defined. The TE-NODE-CAP sub-TLV type is 3. The TE-NODE-CAP sub-TLV does not have any sub-TLV currently defined. Vasseur et al. Expires - - August 2004 [Page 3] draft-vasseur-ccamp-isis-te-caps-00.txt February 2004 4. PCED sub-TLV 4.1 Description The PCED sub-TLV allows for the auto-discovery of one or more Path Computation Element(s). In various situations (GMPLS, inter-area TE, inter-AS TE, etc), an LSR maybe required to send a request to a Path Computation Element (PCE) to compute one or more TE LSP paths obeying a set of specified constraints ([INTER-AREA-AS]). An example of such a signaling protocol used between a PCC to send a request to a PCE and conversely a PCE to return a reply to a PCC is defined in [PATH- COMP]. The scope of this document is to define a new IS-IS TE capability sub-TLV carried within an IS-IS CAPABILITY TLV specified in [IS-IS- CAP] such that a PCE may announce its capability to be a Path Computation Element within an IS-IS level, area or an Autonomous System. This allows every LSR in the network to automatically discover the Path Computation Element(s) and recognize its capability(ies), which substantially simplifies head-end LSRs configuration. Moreover, this allows dynamic detection of any new PCE(s), perform some load sharing among a set of potential PCE candidates or whether that a PCE is no longer active. 4.2 PCED sub-TLV format This section specifies the sub-TLVs carried within the PCED sub-TLV payload which define the PCE capabilities. The PCED sub-TLV is made of various non ordered sub-TLVs defined bellow: 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. 4.2.2 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. Vasseur et al. Expires - - August 2004 [Page 4] draft-vasseur-ccamp-isis-te-caps-00.txt February 2004 The 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 // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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.3 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: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L|I|A|P|M|D| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vasseur et al. Expires - - August 2004 [Page 5] draft-vasseur-ccamp-isis-te-caps-00.txt February 2004 PCE-CAPABILITY sub-TLV format The first 3 bits L, I and A defines the PCEªs 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 area/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 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. See [PATH-COMP] for more details. D=1: the PCE is capable of computing diversely (link, node, SRLG) routed paths. Vasseur et al. Expires - - August 2004 [Page 6] draft-vasseur-ccamp-isis-te-caps-00.txt February 2004 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.2.4 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 two bytes (which is the current defined format as the time of writing this document), 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 5.1 Introduction As of today, there are different approaches in deploying MPLS Traffic Engineering: (1) The ªªsystematic approach consisting of setting up a full mesh of TE LSPs between a set of LSRs, Vasseur et al. Expires - - August 2004 [Page 7] draft-vasseur-ccamp-isis-te-caps-00.txt February 2004 (2) The "by exception" approach where a set of TE LSPs are set up on hot spots to alleviate a congestion resulting for instance in an unexpected traffic growth in some part of the network. Setting up a full mesh of TE LSPs between a set of LSRs requires the configuration of a large number of TE LSPs on every head-end LSR. A full TE mesh of n LSRs requires to set up O(n^2) TE LSPs. Furthermore, the addition of any new LSR in the mesh implies to configure n TE LSPs on the new LSR and to add a new TE LSP on every LSR ending to this new LSR, which gives a total of 2*n TE LSPs. This is not only time consuming but also not a low risk operation for Service Providers. Hence, a more automatic way of setting up a full mesh of TE LSPs is desirable. This requires defining a new TE capability sub-TLV (called the TE-MESH-GROUP sub-TLV) such that an LSR can announce its desire to join a particular TE LSP mesh, identified by a mesh-group number. 5.2 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 the 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 allowing to ease the TE LSP identification which can be very useful in inter-area/AS MPLS TE environments. Vasseur et al. Expires - - August 2004 [Page 8] draft-vasseur-ccamp-isis-te-caps-00.txt February 2004 6. TE-NODE-CAP sub-TLV 6.1 Introduction The aim of the TE-NODE-CAP sub-TLV is to flood some MPLS TE capabilities that could either be relevant to a single IS-IS level, area or the entire routing domain. 6.2 TE-NODE-CAP sub-TLV format The TE-NODE-CAP is a series of bit flags and has a variable length. CODE: 3 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| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TE-NODE-CAP sub-TLV format One bit is currently defined: ªªB ªª bit. When set, this indicates that the LSR has the capability to act as a branch node for an MPLS Point to Multipoint TE LSP (see [P2MP-reqs] and [P2MP]). Note that some TE capabilities defined in the future may require inserting a sub-object in the TE-NODE-CAP sub-TLV. 7. 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, + ). 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. Vasseur et al. Expires - - August 2004 [Page 9] draft-vasseur-ccamp-isis-te-caps-00.txt February 2004 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. 7.1 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 intra-area TE LSP path for the LSRs in the area/level it resides in - Within a CAPABILITY TLV having the S flag set if the PCE can compute an intra-area TE LSP path for the whole domain. 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 PCED TLV MUST and the S bit of CAPABILITY TLV MUST be set. Example <-----------------AS1-----------------> Vasseur et al. Expires - - August 2004 [Page 10] draft-vasseur-ccamp-isis-te-caps-00.txt February 2004 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 server 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 a PCED TLV with: o Both the L and I bit of the PCE-CAPABILITY sub-TLV set, o The A bit of the PCE-CAPABILITY sub-TLV cleared, The S bit of the CAPABILITY TLV MUST be set - 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: * 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) Vasseur et al. Expires - - August 2004 [Page 11] draft-vasseur-ccamp-isis-te-caps-00.txt February 2004 o the ASBR1ªs 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. 7.2 TE-MESH-GROUP sub-TLV If the MPLS TE mesh-group is contained within a single IS-IS level/area (all the LSRs have their head-end and tail-end LSR within the same IS-IS level/area), the TE-MESH-GROUP sub-TLV MUST be carried within a CAPABILITY TLV having the S flag cleared. If the MPLS TE mesh-group spans multiple IS-IS levels/areas, the TE- MESH-GROUP sub-TLV MUST be carried within a CAPABILITY TLV having the S flag set. 7.3 TE-NODE-CAP sub-TLV The flooding scope is defined on a per capability basis. Vasseur et al. Expires - - August 2004 [Page 12] draft-vasseur-ccamp-isis-te-caps-00.txt February 2004 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. 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. 8. Interoperability with routers non supporting this capability 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. 9. Security considerations No new security issues are raised in this document. 10. 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 13] draft-vasseur-ccamp-isis-te-caps-00.txt February 2004 11. 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) [IS-IS-CAP] Vasseur JP, Previdi S. Shand M.,Ginsberg L. "IS-IS extensions for advertising router capabilities", , Internet Draft, work in progress. Informative references [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. [PATH-COMP] Vasseur et al, +RSVP Path computation request and reply messages -, draft-vasseur-mpls-computation-rsvp-te-03.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. 12. Author's Addresses Jean-Philippe Vasseur CISCO Systems, Inc. 300 Beaver Brook Boxborough, MA 01719 USA Email: jpv@cisco.com Stefano Previdi Vasseur et al. Expires - - August 2004 [Page 14] draft-vasseur-ccamp-isis-te-caps-00.txt February 2004 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 Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France E-mail: jeanlouis.leroux@francetelecom.com 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 15] draft-vasseur-ccamp-isis-te-caps-00.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 16]