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]