ISIS
Internet Draft Jean-Philippe Vasseur
Stefano Previdi
Mike Shand
Les Ginsberg
Cisco Systems
Document: draft-vasseur-isis-caps-01.txt
Expires: August 2004 February 2004
IS-IS extensions for advertising router information
draft-vasseur-isis-caps-01.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 defines a new optional IS-IS TLVs named CAPABILITY,
formed of multiple sub-TLVs, which allows a router to announce its
capabilities within an IS-IS level or the entire routing domain.
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 [ii].
Vasseur et al. Expires û August 2004 [Page 1]
draft-vasseur-isis-caps-01.txt February 2004
Table of Contents
1. Introduction...................................................2 Field Code
2. IS-IS CAPABILITY TLV...........................................2 Field Code
3. Element of procedure...........................................3 Field Code
4. Interoperability with routers not supporting the capability TLV.4 Field Code
5. Security considerations........................................4
6. Acknowledgment.................................................4 Field Code
7. Intellectual Property Considerations...........................4 Field Code
8. References.....................................................5 Field Code
Normative references..............................................5
Field Code
Informative references............................................5
9. Author's Addresses.............................................5 Field Code
Field Code
Field Code
1.
Introduction
There are several situations where it is useful for the IS-IS routers
to learn the capabilities of the other routers of their IS-IS level,
area or routing domain. Some applications are described in [IS-IS-TE-
CAP] but for the sake of illustration, one can briefly describes
three of them related to MPLS Traffic Engineering.
- Path Computation Element (PCE) discovery: in several situations,
the Traffic Engineering Label Switched (TE LSP) path is computed by
a Label Switch Router (LSR) it is not the head-end for (e.g an ABR
or an ASBR respectively in the context of inter-area and inter-AS
MPLS TE ([INTER-AREA-AS]). In such a case, having the ability to
discover the capability of an router to act as a PCE is extremely
useful in term of ease of operation, capacity to react to PCE
failure, load sharing between a set of PCEs, etc
- Mesh-group: the setting up of a mesh of TE LSPs requires some
significant configuration effort. [IS-IS-TE-CAP] proposes an auto-
discovery mechanism whereby every LSR of a mesh advertises its
mesh-group membership by means of IS-IS extensions.
- Point to Multi-point TE LSP (P2MP LSP). A specific sub-TLV ([IS-
IS-TE]) allows an LSR to advertise its capabilities to be a ôbranch
nodeö of a P2MP TE LSP (see [P2MP] and [P2MP-reqs]).
The capability mentioned above lead to the specification of specific
TLVs carried within the CAPABILITY TLV defined in this document.
Note that the examples above are provided for the sake of
illustration. This document proposes a generic capability
advertisement mechanism not limited to MPLS Traffic Engineering.
2.
IS-IS CAPABILITY TLV
Vasseur et al. Expires û August 2004 [Page 2]
draft-vasseur-isis-caps-01.txt February 2004
The IS-IS CAPABILITY TLV is composed of 1 octet for the type, 1 octet
specifying the TLV length, 1 octet of bit flags and a variable length
value field, starting with 4 octets of Router ID.
CODE: To be assigned by IANA
LENGTH: Variable (1 octet)
VALUE:
Router ID (4 octets)
Flags (1 octet)
Set of optional sub-TLVs (0-249 octets)
Flags
+-+-+-+-+-+-+-+-+
|S|U| |
+-+-+-+-+-+-+-+-+
Currently two bit flags are defined.
S bit: when set, the IS-IS CAPABILITY TLV MUST be flooded across the
entire routing domain; hence, according to the element of procedure
defined in section 3, the CAPABILITY TLV MUST be leaked between IS-IS
levels or multiple areas of the same IS-IS level by L1L2 routers that
support the CAPABILITY TLV.
U bit: the U bit MUST be set each time the CAPABILITY TLV is leaked
into another IS-IS level or another area of the same IS-IS level.
When set, the U bit MUST not be changed by any other router.
The CAPABILITY TLV is OPTIONAL. As specified in section 3, more than
one CAPABILITY TLVs may be present.
3.
Element of procedure
In case of capabilities with different scopes, a router MUST include
two CAPABILITY TLVs, each TLV carrying the set of sub-TLVs with the
same flooding scope. For instance, if a router advertises two
capabilities C1 and C2 respectively with an area/level scope and
routing domain scope, C1 and C2 being specified by their respective
sub-TLV(s), the router MUST include two CAPABILITY TLVs:
- One CAPABILITY TLV with the S flag cleared carrying the sub-
TLV(s) relative to C1. The CAPABILITY TLV MUST NOT be leaked into
other level or areas of the same level.
- One CAPABILITY TLV with the S flag set carrying the sub-TLV(s)
relative to C2. This CAPABILITY TLV MUST be leaked into other IS-IS
levels or areas or the same level after having set the U bit. Other
sub-TLVs MUST be unchanged during the leaking procedure.
Vasseur et al. Expires û August 2004 [Page 3]
draft-vasseur-isis-caps-01.txt February 2004
A router receiving a CAPABILITY TLV with the U flag set MUST NOT leak
the CAPABILITY TLV into another ISIS level or areas. This prevents
TLV looping.
4.
Interoperability with routers not supporting the capability TLV.
There is no interoperability issue as a router not supporting the
CAPABILITY TLV MUST just silently ignore the TLV(s) and continue the
LSP processing. If just a subset of the sub-TLVs carried within the
CAPABILITY TLV are supported, then the not supported sub-TLV MUST be
silently ignored.
5.
Security considerations
No new security issues are raised in this document.
6.
Acknowledgment
The authors would like to thank Jean-Louis Le Roux and Paul Mabey for
their useful comments.
7.
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 4]
draft-vasseur-isis-caps-01.txt February 2004
8.
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)
Informative references
[IS-IS-TE-CAP] JP Vasseur, S. Previdi, JL. Le Roux, ôIS-IS MPLS
Traffic Engineering capabilitiesö, draft-vasseur-ccamp-isis-te-caps-
00.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.
[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.
9.
Author's Addresses
Jean-Philippe Vasseur
CISCO Systems, Inc.
300 Beaver Brook
Boxborough, MA 01719
USA
Email: jpv@cisco.com Field Code
Stefano Previdi
CISCO Systems, Inc.
Vasseur et al. Expires û August 2004 [Page 5]
draft-vasseur-isis-caps-01.txt February 2004
Via Del Serafico 200
00142 - Roma
ITALY
Email: sprevidi@cisco.com Field Code
Mike Shand
Cisco Systems
250 Longwater Avenue,
Reading,
Berkshire,
RG2 6GB
UK
Phone: +44 208 824 8690
Email: mshand@cisco.com Field Code
Les Ginsberg
Cisco Systems
510 McCarthy Blvd.
Milpitas, Ca. 95035 USA
Email: ginsberg@cisco.com Field Code
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 6]
draft-vasseur-isis-caps-01.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 7]