CCAMP Working Group JP Vasseur (Ed.) Cisco System Inc. Internet Draft JL Le Roux (Ed.) France Telecom Category: Standard Track Expires: January 2005 July 2004 Routing extensions for discovery of TE router information draft-vasseur-ccamp-te-router-info-00.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. 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 describes extensions to MPLS Traffic Engineering routing for the advertisement of Traffic Engineering Router Information and capabilities. This document specifies a functional description of these extensions whereas protocol specific formats and mechanisms are described in separate documents. Vasseur, Le Roux et al. [Page 1] Internet Draft draft-vasseur-ccamp-te-router-info-00 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. Contributors....................................................2 2. Terminology.....................................................3 3. Introduction....................................................3 4. TE Node Capability Descriptor TLV...............................4 4.1. Description...................................................4 4.2. Required Information..........................................5 4.3. Procedure.....................................................5 5. PCE Discovery Information.......................................5 5.1. Description...................................................5 5.2. Required Information..........................................6 5.3. Procedure.....................................................7 6. TE Mesh Group Information.......................................8 6.1. Description...................................................8 6.2. Required Information..........................................8 6.3. Procedure.....................................................8 7. Security Considerations.........................................9 8. Intellectual Property Statement.................................9 8.1. IPR Disclosure Acknowledgement................................9 9. Acknowledgment..................................................9 10. References....................................................10 11. Editors' Address:.............................................11 1. Contributors This document was the collective work of several. The text and content of this document was contributed by the editors and the co-authors listed below (the contact information for the editors appears in section 14, and is not repeated below): Paul Mabey Seisho Yasukawa Qwest Communications NTT 950 17th street 9-11, Midori-Cho 3-Chome Denver, CO 80202 Musashino-Shi, Tokyo 180-8585 USA JAPAN Email: pmabey@qwest.com Email: yasukawa.seisho@lab.ntt.co.jp Stefano Previdi Peter Psenak Cisco System, Inc. Cisco System, Inc. Via del Serafico 200 Pegasus Park 00142 Roma DE Kleetlaan 6A ITALY 1831, Diegmen Email: sprevidi@cisco.com BELGIUM Email: ppsenak@cisco.com Vasseur, Le Roux et al. [Page 2] Internet Draft draft-vasseur-ccamp-te-router-info-00 July 2004 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 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. IGP Area: OSPF Area or ISIS level Link State Advertisement: An OSPF LSA or ISIS LSP Intra-area TE LSP: TE LSP whose path does not transit across areas. 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). 3. Introduction MPLS Traffic Engineering (MPLS-TE) routing ([ISIS-TE], [OSPF-TE]) relies on extensions to link state IGP routing protocols ([OSPF], [ISIS]) in order to carry Traffic Engineering link information used for constraint based routing. Further Generalized MPLS (GMPLS) related extensions are defined in [ISIS-G] and [OSPF-G]. The current MPLS-TE/GMPLS routing focuses on TE link information. In return TE router information are limited to the TE router id. However, it would be highly useful to advertise more TE router information for various purposes such as: - A Path Computation Elements (PCE) can compute paths for TE-LSPs it is not the head-end for. This can be an LSR or an offline tool not forwarding packets. PCE are useful in various MPLS-TE and GMPLS situations such as, for instance, inter-domain path computation (see [INT-DOMAIN-FRWK]) or backup path computation (see [FACILTY-BACKUP]). It would be highly useful that a node Vasseur, Le Roux et al. [Page 3] Internet Draft draft-vasseur-ccamp-te-router-info-00 July 2004 advertise its PCE capabilities so as for the LSRs in the network to automatically discover PCEs in addition to their capabilities, and thus would reduce the LSR configuration overhead. This would also allow for the dynamic discovery of a new PCE or that a PCE is not longer alive. - A TE mesh group is a group of LSRs that are connected by a full mesh of TE-LSPs. It is useful to advertise the desire of a node to join/leave a particular TE mesh group. This allows for an automatic provisioning of a full mesh of TE LSP, and thus drastically reduces the configuration overhead. - Data plane capabilities related to the node itself and not to its links, such as the capability to be a branch node or a bud LSR of a P2MP LSP tunnel (see [P2MP-REQ]). These node capabilities should be advertised by the IGP for path selection. It would also be highly useful to advertise control plane node Capabilities; for instance, the capability to support GMPLS signaling for a packet LSR, or the capability to support P2MP signaling. This would ease backward compatibility. For instance this would allow selecting a path that would avoid nodes that do not support a given signaling feature, or automatically triggering a mechanism that would handle these nodes on the path. This document specifies routing extensions in support of carrying Traffic Engineering router information for MPLS Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS). Such Traffic Engineering router information will be carried into Link State Advertisements. This document specifies a functional description of the extensions required to advertise TE router information and capabilities. Generic routing protocol formats, procedure and definitions are provided in this document whereas protocol specific formats and procedures are defined in [OSPF-CAP], [OSPF-TE-CAP] for OSPF, and in [ISIS-CAP] and [ISIS-TE-CAP] for ISIS. The TE Router Information and capabilities defined in this document consists of three pieces of information: -The TE Node Capability Descriptor TLV used to advertise data and control plane TE capabilities of an LSR, -The PCE Discovery Information TLV used to advertise PCE capabilities. -The TE Mesh Group Information TLV used to advertise the desire of an LSR to join/leave one or more TE mesh groups. 4. TE Node Capability Descriptor TLV 4.1. Description LSRs in a network may have distinct control plane and data plane Traffic Engineering capabilities. The TE Node capability Descriptor TLV describes data and control plane capabilities of an LSR. Such Vasseur, Le Roux et al. [Page 4] Internet Draft draft-vasseur-ccamp-te-router-info-00 July 2004 information can be used for instance for path computation algorithm so as to avoid nodes that do not support a given TE feature either in the control or data plane or to trigger procedure to handle these nodes. In some case, this may also be useful for backward compatibility. 4.2. Required Information The TE Node Capability Descriptor TLV contains two variable length sets of bit flags: the Control Plane Capability flags and the Data Plane Capability flags. Each flag corresponds to a given capability. Two flags are currently defined in the Data Plane Capability Flags: B bit: when set, this flag indicates that the LSR can act as a branch node on a P2MP LSP (see [P2MP-REQ]) and [RSVP-P2MP]). E bit: when set, this flag indicates that the LSR can act as a bud LSR on a P2MP LSP, i.e. and LSR that is both transit and egress. Three flags are currently defined in the Control Plane Capability Flags: M bit: when set, this flag indicates that the LSR supports MPLS-TE signalling ([RSVP-TE]). G bit: when set this flag indicates that the LSR supports GMPLS signalling ([RSVP-G]). P bit: when set, this flag indicates that the LSR supports P2MP MPLS- TE signalling ([RSVP-P2MP]). Note that new flags may be added if required. 4.3. Procedure The TE Node Capability Descriptor TLV is carried in Link State Advertisements. A router MUST originate a new Link State Advertisement whenever the content of this information changes, or whenever required by regular routing procedure (e.g. refresh). TE Node Capability Descriptor TLVs are optional. When a Link State Advertisement does not contain any TE Node capability Descriptor TLV, this means that the TE Capabilities of that LSR are unknown. 5. PCE Discovery Information 5.1. Description The PCE Discovery Information allows for the auto-discovery of one or more Path Computation Element(s). In various MPLS and GMPLS Vasseur, Le Roux et al. [Page 5] Internet Draft draft-vasseur-ccamp-te-router-info-00 July 2004 situations, such as inter-domain TE or backup path computation, an LSR may require to send a request to a Path Computation Element (PCE) to compute one or more TE LSPs paths obeying a set of specified constraints. Note that a PCE can be an LSR or an offline tool without any forwarding capability. The PCE Discovery Information allows a PCE to announce its capability to be a Path Computation Element within an area or an AS. This allows every LSR in the network to automatically discover the PCEs and recognize their capabilities, which substantially simplifies head-end LSR configuration. Moreover, this also allows for: - The dynamic detection of any new PCE, - To determine that PCE is no longer active, - To perform some load sharing among a set of potential PCE candidates. 5.2. Required Information The PCE Discovery Information carries the IP address to be used to reach the PCE. This address will typically be a loop-back address that is always reachable, provided the router is not isolated. The PCE IP address is mandatory, and MUST appear only once, except when the PCE has both an IPv4 and an IPv6 address. The PCE Discovery Information TLV also carries an optional set of capability flag bits that is used by the PCE to signal its PCE capabilities. This could then be used by an LSR to select the appropriate PCE among a list of PCE candidates. Six capability flags are currently defined. The first three bits define the scope for which the PCE 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 PCE Discovery Information 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: Inter-AS scope. When set, the PCE can perform path computation for inter-AS TE LSPs. Note that those flags are not exclusive (a PCE may set one or more flags). P bit: Request Priority. The notion of request priority allows a PCC to specify the degree of urgency of a particular request. When set, this Vasseur, Le Roux et al. [Page 6] Internet Draft draft-vasseur-ccamp-te-router-info-00 July 2004 flag indicates that the PCE takes into account the 'request priority' in its scheduling of the various requests. M bit: Multiple Path Computation. When set, this flag indicates that the PCE is capable of computing more than one path obeying a set of specified constraints (in a single pass), provided that they exist. D bit: Diversity. When set, this flag indicates that the PCE is capable of computing diversely routed paths (link, node, SRLG). 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. Note that new flags may be defined in the future to announce additional PCE capabilities. If the PCE is capable of computing inter-AS TE LSP path, the PCE Discovery Information TLV MAY also contain the list of AS numbers identifying the AS for which the PCE can compute inter-AS TE LSP paths (TE-LSPs having their destination address in this AS). This set is optional and should be included only when the A bit is set. 5.3. Procedure The PCE Discovery Information TLV is carried in Link State Advertisements. A router MUST originate a new Link State Advertisement whenever the content of this information changes, or whenever required by regular routing procedure (e.g. refresh) The PCE Discovery Information TLV is optional. If the PCE can compute an intra-area TE LSP path, the L bit MUST be set. If it can compute an intra-area TE LSP path only for the LSRs in the area it resides in, then the PCE Discovery Information must be contained within an area. Otherwise, if the PCE can compute intra-area TE LSP paths for the whole AS, then the PCE Discovery Information TLV must be flooded across the whole AS. If the PCE can compute an inter-area TE LSP path, the I bit MUST be set. If it can compute an inter-area TE LSP path only 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), then the PCE Discovery Information must be contained within this or these area(s). Else, if it can compute an inter-area TE LSP path for the whole AS, then the PCE Discovery Information must be flooded across the whole AS. If the PCE can compute an inter-AS TE LSP path, the A bit MUST be set, and the PCE Discovery Information must be flooded across the whole AS. Vasseur, Le Roux et al. [Page 7] Internet Draft draft-vasseur-ccamp-te-router-info-00 July 2004 6. TE Mesh Group Information 6.1. Description 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, (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 a risky operation for Service Providers. Hence, a more automatic way of setting up a full mesh of TE LSPs is desirable. A TE-mesh group is defined as a group of LSRs fully meshed by a set of LSPs having common TE attributes. An LSR MUST setup a TE-LSP towards each LSR belonging to its TE mesh-group(s). The TE Mesh-Group Information allows an LSR to advertise its desire to join/leave one or more TE mesh-groups. 6.2. Required Information The TE Mesh Group Information TLV allows an LSR to advertise the set of TE mesh-groups it belongs to. For each mesh group announced by the LSR, the TE Mesh Group Information TLV carries the following set of information: -A Mesh-Group number identifying the TE mesh-group, -A Tail-end address (address used as a tail end address by other LSRs belonging to the same mesh-group), -A Tail-end name: string used to ease the TE-LSP naming (e.g. 'head-name->tail-name'). 6.3. Procedure The TE Mesh-Group Information TLV is carried in Link State Advertisements. A router MUST originate a new Link State Advertisement whenever the content of this information changes, or whenever required by regular routing procedure (e.g. refresh) Vasseur, Le Roux et al. [Page 8] Internet Draft draft-vasseur-ccamp-te-router-info-00 July 2004 The TE Mesh-Group Information is optional. If the TE Mesh Group is contained within a single area, the TE Mesh Group Information TLV must be advertised with an area scope for OSPF and MUST not be leaked across levels for IS-IS. Conversely, if the TE Mesh Group spans multiple IGP areas, the TE Mesh Group Information TLV must be advertisement with a routing domain scope for OSPF and MUST be leaked across levels for IS-IS. 7. Security Considerations No new security issues are raised in this document. 8. 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.. 8.1. IPR Disclosure Acknowledgement 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. 9. Acknowledgment We would like to thank Yannick Le Louedec, for its useful comments. Vasseur, Le Roux et al. [Page 9] Internet Draft draft-vasseur-ccamp-te-router-info-00 July 2004 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. [OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [ISIS] "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol " ISO 10589. [ISIS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering Extensions to OSPF Version 2", RFC 3630, September 2003. [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", RFC 3784, June 2004. Informative References [GMPLS-RTG] Kompella, K., Rekhter, Y., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching", draft-ietf-ccamp- gmpls-routing-09.txt (work in progress) [OSPF-G] Kompella, K., Rekhter, Y., "OSPF extensions in support of Generalized Multi-protocol Label Switching", draft-ietf-ccamp-ospf- gmpls-extensions-12.txt, work in progress. [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. [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur, J.P., "Extensions to OSPF for advertising Optional Router Capabilities", draft-ietf-ospf-cap-03.txt, work in progress. [OSPF-TE-CAP] Vasseur, J.P., Psenak, P., Yasukawa, S., "OSPF MPLS Traffic Engineering Capabilities", draft-vasseur-ospf-te-caps-00.txt, work in progress. [ISIS-CAP] Vasseur, J.P., Aggarwal, R., Shen, N., "IS-IS extensions for advertising router information", draft-vasseur-isis-caps-02.txt, work in progress. Vasseur, Le Roux et al. [Page 10] Internet Draft draft-vasseur-ccamp-te-router-info-00 July 2004 [ISIS-TE-CAP] Vasseur, J.P, Previdi, S., Mabey, P., Le Roux, J.L., "IS-IS MPLS Traffic Engineering Capabilities", draft-vasseur-isis-te- caps-00.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. [FACILITY-BACKUP] Le Roux, J.L., Vasseur, J.P. et al. "Framework for PCE based MPLS Facility Backup Path Computation", draft-leroux-pce- backup-comp-frwk-00.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. Editors' Address: Jean-Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road 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 Vasseur, Le Roux et al. [Page 11] Internet Draft draft-vasseur-ccamp-te-router-info-00 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, Le Roux et al. [Page 12]