draft-ietf-mpls-number-0-bw-te-lsps-00.txt   draft-ietf-mpls-number-0-bw-te-lsps-01.txt 
Networking Working Group JP. Vasseur, Ed. Networking Working Group JP. Vasseur, Ed.
Internet-Draft Cisco Systems, Inc Internet-Draft Cisco Systems, Inc
Expires: November 16, 2006 May 15, 2006 Expires: November 25, 2006 Matthew. R. Meyer
Global Crossing
K. Kumaki
KDDI Corporation
Alberto. Tempia Bonda
Telecom Italia
May 24, 2006
A Link-Type sub-TLV to convey the number of Traffic Engineering Label A Link-Type sub-TLV to convey the number of Traffic Engineering Label
Switch Paths signalled across a link Switch Paths signalled across a link
draft-ietf-mpls-number-0-bw-te-lsps-00 draft-ietf-mpls-number-0-bw-te-lsps-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 16, 2006. This Internet-Draft will expire on November 25, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
Several Link-type sub-TLVs have been defined for OSPF and ISIS in the Several Link-type sub-TLVs have been defined for OSPF and ISIS in the
context of MPLS Traffic Engineering in order to convery some link context of MPLS Traffic Engineering in order to convery some link
characteristics such as the available bandwidth, traffic enginering characteristics such as the available bandwidth, traffic enginering
metric, adminstrative group and so on. There are various metric, adminstrative group and so on. There are various
circumstances where it would be useful to also know the number of circumstances where it would be useful to also advertise the number
unconstrained Traffic Engineering Label Switched Path(s) (TE LSP). of unconstrained Traffic Engineering Label Switched Path(s) (TE LSP)
This document specifies a new Link-type Traffic Engineering sub-TLV signalled across a link. This document specifies a new Link-type
used to advertise the number of unconstrained TE LSP(s) signalled Traffic Engineering sub-TLV used to advertise the number of
across a specific link. unconstrained TE LSP(s) signalled across a link.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol extensions . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol extensions . . . . . . . . . . . . . . . . . . . . . . 4
3.1. ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Elements of procedure . . . . . . . . . . . . . . . . . . . . . 4 4. Elements of procedure . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8
1. Introduction 1. Introduction
Several Link-type sub-TLVs have been defined for OSPF and ISIS (see A set of Link-type sub-TLVs have been defined for OSPF and ISIS (see
[I-D.ietf-isis-te-bis] and [RFC3630]) in the context of MPLS Traffic [I-D.ietf-isis-te-bis] and [RFC3630]) in the context of MPLS Traffic
Engineering in order to advertise various link characteristics such Engineering in order to advertise various link characteristics such
as the available bandwidth, traffic enginering metric, adminstrative as the available bandwidth, traffic enginering metric, administrative
group and so on. There are various circumstances where it would be group and so on. There are various circumstances where it would be
useful to also know the number of unconstrained Traffic Engineering useful to also advertise the number of unconstrained Traffic
Label Switch Path(s) (TE LSP). Engineering Label Switch Path(s) (TE LSP).
It is not uncommon to deploy MPLS Traffic Engineering for the sake of It is not uncommon to deploy MPLS Traffic Engineering for the sake of
fast recovery with MPLS TE Fast Reroute (see [RFC4090]). In this fast recovery relying on a local protection recovery mechanism such
case, a common deployment model consists of deploying a full mesh of as MPLS TE Fast Reroute (see [RFC4090]). In this case, a deployment
unconstrained TE LSPs between a set of LSRs and protect these TE LSPs model consists of deploying a full mesh of unconstrained TE LSPs
thanks to pre-established backup tunnels against link, SRLG and/or between a set of LSRs and protect these TE LSPs with pre-established
node failures. backup tunnels against link, SRLG and/or node failures. The traffic
routed onto such unconstrained TE LSP simply follows the IGP shortest
path but is protected with MPLS TE Fast Reroute.
With MPLS Traffic Engineering a usual rerouting criteria is the
discovery of a better path for a TE LSP where a better path is
defined as a path with a lower cost according to a specific metric;
other metric such that the percentage of reserved bandwidth or the
number of hops can also be used. Unfortunately, for instance in the
presence of ECMPs (Equal Cost Multi-Paths) in symetrical networks
when unconstrained TE LSP are used, such metrics are usually
inneffective and may lead to poorly load balanced traffic. If the
number of unconstrained TE LSPs traversing each link in the network
is known, various algorithms can be designed so as to efficiently
load balance the traffic carried by such unconstrained TE LSPs. As
currently defined in [RFC3630] and [I-D.ietf-isis-te-bis] the
information related to the number of unconstrained TE LSP(s) is not
available. This document specifies a new Link-type Traffic
Engineering sub-TLV used to indicate the number of unconstrained TE
LSP signalled across a link.
When a set of unconstrained TE LSPs is deployed, various algorithms
can be designed so as efficiently load balance the traffic carried by
such unconstrained TE LSPs provided that the number of unconstrained
TE LSPs traversing each link in the network is known. As currently
defined in [RFC3630] and [I-D.ietf-isis-te-bis] the information
related to the number of unconstrained TE LSP(s) is not available.
Note that the specification of load balancing algorithms is outside Note that the specification of load balancing algorithms is outside
of the scope of this document and merely listed for the sake of of the scope of this document and merely listed for the sake of
illustration of the motivation for gathering such information. illustration of the motivation for gathering such information.
Furthermore, the knowledge of the number of unconstrained TE LSPs Furthermore, the knowledge of the number of unconstrained TE LSPs
signalled across each link can be used for other purposes (e.g. signalled across each link can be used for other purposes (e.g.
management, ...). management, ...).
This document specifies a new Link-type Traffic Engineering sub-TLV
used to indicate the number of unconstrained TE LSP signalled across
a specific link.
2. Terminology 2. Terminology
Terminology used in this document LSR: Label Switch Router. Terminology used in this document
LSA: Link State Advertisement.
TE LSP: MPLS Traffic Engineering Label Switched Path. LSP: Link State Packet.
Backup tunnel: the TE LSP that is used to backup up one of the many LSR: Label Switching Router.
TE LSPs in many-to-one backup (as defined in [FAST-REROUTE]).
Unconstrained TE LSP: A TE LSP signalled with a bandwidth requirement TE LSP: Traffic Engineering Label Switched Path.
Unconstrained TE LSP: A TE LSP signalled with a bandwidth metric
equal to 0. equal to 0.
3. Protocol extensions 3. Protocol extensions
A new Sub-TLV named NB-O-BW-LSP is defined that specifies the number A new Sub-TLV named NB-O-BW-LSP is defined that specifies the number
of unconstrained TE LSPs signalled across a link. of unconstrained TE LSPs signalled across a link.
3.1. ISIS 3.1. IS-IS
The NB-0-BW-LSP TLV is OPTIONAL and MUST appear at most once within The NB-0-BW-LSP TLV is OPTIONAL and MUST appear at most once within
the extended IS reachability TLV (type 22) specified in [ISIS-TE]. the extended IS reachability TLV (type 22) specified in [I-D.ietf-
The NB-0-BW-LSP consists of: isis-te-bis].
Type (1 octet): To be assigned by IANA (Recommended value = 19) The IS-IS NB-0-BW-LSP TLV format is defined below:
Type (1 octet): To be assigned by IANA (suggested value = 19)
Length (1 octet): 4 Length (1 octet): 4
Value (4 octets): field value that comprises the number of Value (4 octets): number of unconstrained TE LSP(s) signalled across
unconstrained TE LSP(s) signalled across the link. the link.
3.2. OSPF 3.2. OSPF
The NB-0-BW-LSP is OPTIONAL and MUST appear at most once within the The NB-0-BW-LSP is OPTIONAL and MUST appear at most once within the
Link TLV (Type 2) that is itself carried within the Traffic Link TLV (Type 2) that is itself carried within the Traffic
Engineering LSA specified in [OSPF-TE]. The NB-0-BW-LSP consists of: Engineering LSA specified in [RFC3630].
Type (2 octets): To be assigned by IANA (Recommended value = 19) The OSPF NB-0-BW-LSP TLV format is defined below:
Type (2 octets): To be assigned by IANA (suggested value = 19)
Length (2 octets): 4 Length (2 octets): 4
Value (4 octets): field value that comprises the number of Value (4 octets): number of unconstrained TE LSP(s) signalled across
unconstrained TE LSP(s) signalled across the link. the link.
4. Elements of procedure 4. Elements of procedure
An implementation may decide to implement a dual-thresholds mechanism An implementation may decide to implement a dual-thresholds mechanism
so as to trigger the origination of an updated OSPF LSA or ISIS LSP. to govern the origination of updated OSPF LSA () or ISIS LSP ().
Similalry to other MPLS Traffic Engineering link characteristics, Similalry to other MPLS Traffic Engineering link characteristics,
LSA/LSP origination trigger mechanisms are outside of the scope of LSA/LSP origination trigger mechanisms are outside of the scope of
this document. this document.
5. IANA Considerations 5. IANA Considerations
IANA will assign a new code point for the newly defined ISIS sub-TLV IANA will assign a new code point for the newly defined IS-IS sub-TLV
(NB-0-BW-LSP) carried within the TLV 22 (suggested value =19) (NB-0-BW-LSP) carried within the TLV 22 (suggested value =19)
IANA will assign a new code point for the newly defined OSPF sub-TLV IANA will assign a new code point for the newly defined OSPF sub-TLV
(NB-0-BW-LSP) carried within the Link TLV (Type 2) of the Traffic (NB-0-BW-LSP) carried within the Link TLV (Type 2) of the Traffic
Engineering LSA (suggested value=19). Engineering LSA (suggested value=19).
6. Security Considerations 6. Security Considerations
This document raises no new security issues for IS-IS and OSPF. This document raises no new security issues for IS-IS and OSPF.
7. Acknowledgements 7. Acknowledgements
The author would want to thank Kenji Kumaki, Alberto Tempia, Jean- The authors would like to thank Jean-Louis Le Roux for his useful
Louis Le Roux and Matt Meyer for their useful inputs. inputs.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-isis-te-bis] [I-D.ietf-isis-te-bis]
Li, T. and H. Smit, "IS-IS extensions for Traffic Li, T. and H. Smit, "IS-IS extensions for Traffic
Engineering", draft-ietf-isis-te-bis-00 (work in Engineering", draft-ietf-isis-te-bis-00 (work in
progress), September 2005. progress), September 2005.
skipping to change at page 6, line 5 skipping to change at page 7, line 5
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
September 2003. September 2003.
8.2. Informative References 8.2. Informative References
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005. May 2005.
Author's Address Authors' Addresses
JP Vasseur (editor) JP Vasseur (editor)
Cisco Systems, Inc Cisco Systems, Inc
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
Matthew R. Meyer
Global Crossing
3133 Indian Valley Tr.
Howell, MI 48855
USA
Email: mrm@gblx.net
Kenji Kumaki
KDDI Corporation
Garden Air Tower Iidabashi, Chiyoda-ku,
Tokyo, 102-8460
JAPAN
Email: ke-kumaki@kddi.com
Alberto Tempia Bonda
Telecom Italia
via G. Reiss Romoli 274
Torino, 10148
ITALIA
Email: alberto.tempiabonda@telecomitalia.it
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 30 change blocks. 
53 lines changed or deleted 99 lines changed or added

This html diff was produced by rfcdiff 1.31. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/