One document matched: draft-vasseur-isis-caps-00.txt
ISIS
Internet Draft Jean-Philippe Vasseur
Stefano Previdi
Mike Shand
Cisco Systems
Document: draft-vasseur-isis-caps-00.txt
Expires: August 2004 February 2004
IS-IS extensions for advertising router capabilities
draft-vasseur-isis-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 defines a new optional IS-IS TLV named CAPABILITY TLV,
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-00.txt February 2004
Table of Contents
1. Introduction...................................................2
2. IS-IS CAPABILITY TLV...........................................2
2.1 IS-IS CAP-SCOPE sub-TLV....................................3
2.2 IS-IS router-ID sub-TLV....................................3
3. Element of procedure...........................................4
4. Interoperability with routers not supporting the capability TLV.4
5. Security considerations........................................4
6. Intellectual Property Considerations...........................4
7. References.....................................................5
Normative references..............................................5
Informative references............................................5
8. Author's Addresses.............................................6
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-req]).
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-00.txt February 2004
The IS-IS TLV is composed of 1 octet for the type, 1 octet specifying
the TLV length and a variable length value field.
CODE: To be assigned by IANA
LENGTH: Variable (1 octet)
VALUE: set of sub-TLVs
The CAPABILITY TLV is OPTIONAL. As specified in section 3, more than
one CAPABILITY TLVs may be present.
The CAPABILITY TLV MUST be inserted in fragment 0 in case of a
fragmented IS-IS LSP. A CAPABILITY TLV inserted in non-0 LSP fragment
MUST be ignored.
2.1
IS-IS CAP-SCOPE sub-TLV
The CAP-SCOPE sub-TLV is mandatory and MUST be included in the
CAPABILITY TLV. It MUST also always be the first sub-TLV.
Furthermore, a router MUST include exactly one CAP-SCOPE TLV. A
router receiving a CAPABILITY TLV not starting with the CAP-SCOPE
sub-TLV MUST IGNORE the CAPABILITY TLV and continue processing the
IS-IS LSP.
CODE: 1
LENGTH: 1
VALUE:
+-+-+-+-+-+-+-+-+
|S|U| |
+-+-+-+-+-+-+-+-+
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.
2.2
IS-IS router-ID sub-TLV
The router-ID sub-TLV is mandatory and MUST be included in the
CAPABILITY TLV. It MUST immediately follow the CAP-SCOPE TLV.
Furthermore, a router MUST include exactly one router-ID TLV.
CODE: 2
LENGTH: 4
VALUE: unsigned 32 bit number representing the router-ID.
Vasseur et al. Expires û August 2004 [Page 3]
draft-vasseur-isis-caps-00.txt February 2004
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 a area/level scope and
routing domain scope, C1 and C2 being specified by their respective
sub-TLV, the router MUST include two CAPABILITY TLVs:
- One CAPABILITY TLV with one CAP-SCOPE sub-TLV (S flag set), the
ROUTER-ID sub-TLV, followed by the sub-TLV relative to C1. This
CAPABILITY TLV MUST be leaked into other IS-IS levels or areas or
the same level after having set the U bit of the CAP-SCOPE sub-TLV.
Other sub-TLVs MUST be unchanged during the leaking procedure.
- One CAPABILITY TLV with one CAP-SCOPE sub-TLV (S flag set), the
ROUTER-ID sub-TLV, followed by the sub-TLV relative to C2. Such a
CAPABILITY TLV MUST not be leaked into other level or areas of the
same level.
A router receiving a CAPABILITY TLV carrying a CAP-SCOPE sub-TLV with
the S flag and 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 non-supporting the
capability TLV MUST just silently ignore the TLV(s). If just a subset
of the sub-TLVs carried within the capability TLV are supported, then
the non-supported sub-TLV MUST be silently ignored.
5.
Security considerations
No new security issues are raised in this document.
6.
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
Vasseur et al. Expires û August 2004 [Page 4]
draft-vasseur-isis-caps-00.txt February 2004
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.
7.
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.
Vasseur et al. Expires û August 2004 [Page 5]
draft-vasseur-isis-caps-00.txt February 2004
8.
Author's Addresses
Jean-Philippe Vasseur
CISCO Systems, Inc.
300 Beaver Brook
Boxborough, MA 01719
USA
Email: jpv@cisco.com
Stefano Previdi
CISCO Systems, Inc.
Via Del Serafico 200
00142 - Roma
ITALY
Email: sprevidi@cisco.com
Mike Shand
Cisco Systems
250 Longwater Avenue,
Reading,
Berkshire,
RG2 6GB
UK
Phone: +44 208 824 8690
Email: mshand@cisco.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.
Vasseur et al. Expires û August 2004 [Page 6]
draft-vasseur-isis-caps-00.txt February 2004
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
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]
| PAFTECH AB 2003-2026 | 2026-04-22 23:21:41 |