GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3786

Network Working Group A. Hermelin Request for Comments: 3786 Montilio Inc. Category: Informational S. Previdi

                                                              M. Shand
                                                         Cisco Systems
                                                              May 2004
                      Extending the Number of
        Intermediate System to Intermediate System (IS-IS)
        Link State PDU (LSP) Fragments Beyond the 256 Limit

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

 This document describes a mechanism that allows a system to originate
 more than 256 Link State PDU (LSP) fragments, a limit set by the
 original Intermediate System to Intermediate System (IS-IS) Routing
 protocol, as described in ISO/IEC 10589.  This mechanism can be used
 in IP-only, OSI-only, and dual routers.

Table of Contents

 1.  Introduction .................................................  2
     1.1.  Keywords ...............................................  2
     1.2.  Definitions of Commonly Used Terms .....................  2
     1.3.  Operation Modes ........................................  3
     1.4.  Overview ...............................................  4
 2.  IS Alias ID TLV (IS-A) .......................................  5
 3.  Generating LSPs ..............................................  6
     3.1.  Both Operation Modes ...................................  6
     3.2.  Operation Mode 1 Additives .............................  8
 4.  Purging Extended LSP Fragments ............................... 10
 5.  Modifications to LSP handling in SPF ......................... 10
 6.  Forming Adjacencies .......................................... 11
 7.  Interoperating between extension-capable and non-capable ISs . 11
 8.  Security Considerations ...................................... 12
 9.  Acknowledgements ............................................. 12

Hermelin, et al. Informational [Page 1] RFC 3786 IS-IS LSP Fragments May 2004

 10. References ................................................... 12
 11. Authors' Addresses ........................................... 13
 12. Full Copyright Statement ..................................... 14

1. Introduction

 In the Intermediate System to Intermediate System (IS-IS) protocol, a
 system floods its link-state information in Link State PDU (LSP) Data
 Units, or LSPs for short.  These logical LSPs can become quite large,
 therefore the protocol specifies a means of fragmenting this
 information into multiple LSP fragments.  The number of fragments a
 system can generate is limited by ISO/IEC 10589 [ISIS-ISO] to 256
 fragments, where each fragment's size is also limited.  Hence, there
 is a limit on the amount of link-state information a system can
 generate.
 A number of factors can contribute to exceeding this limit:
  1. Introduction of new TLVs and sub-TLVs to be included in LSPs.
  2. The use of LSPs to propagate various types of information (such as

traffic-engineering information).

  1. The increasing number of destinations and AS topologies.
  2. Finer granularity routing, and the ability to inject external

routes into areas [DOMAIN-WIDE].

  1. Other emerging technologies, such as optical, IPv6, etc.
 This document describes mechanisms to relax the limit on the number
 of LSP fragments.

1.1. Keywords

 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 BCP 14, RFC 2119
 [BCP14].

1.2. Definitions of Commonly Used Terms

 This section provides definitions for terms that are used throughout
 the text.
    Originating System
       A router physically running the IS-IS protocol.  As this
       document describes methods allowing a single IS-IS process to
       advertise its LSPs as multiple "virtual" routers, the
       Originating System represents the single "physical" IS-IS
       process.

Hermelin, et al. Informational [Page 2] RFC 3786 IS-IS LSP Fragments May 2004

    Normal system-id
       The system-id of an Originating System.
    Additional system-id
       An Additional system-id that is assigned by the network
       administrator.  Each Additional system-id allows generation of
       256 additional, or extended, LSP fragments.  The Additional
       system-id, like the Normal system-id, must be unique throughout
       the routing domain.
    Virtual System
       The system, identified by an Additional system-id, advertised
       as originating the extended LSP fragments.  These fragments
       specify the Additional system-id in their LSP IDs.
    Original LSP
       An LSP using the Normal system-id in its LSP ID.
    Extended LSP
       An LSP using an Additional system-id in its LSP ID.
    LSP set
       Logical LSP.  This term is used only to resolve the ambiguity
       between a logical LSP and an LSP fragment, both of which are
       sometimes termed "LSP".
    Extended LSP set
       A group of LSP fragments using an Additional system-id, and
       originated by the Originating System.
    Extension-capable IS
       An IS implementing the mechanisms described in this document.

1.3. Operation Modes

 Two administrative operation modes are provided:
  1. Operation Mode 1 provides behavior that allows implementations

that don't support this extension, to correctly process the

    extended fragment information, without any modifications.  This
    mode has some restrictions on what may be advertised in the
    extended LSP fragments.  Namely, only leaf information may be
    advertised in the extended LSPs.

Hermelin, et al. Informational [Page 3] RFC 3786 IS-IS LSP Fragments May 2004

  1. Operation Mode 2 extends the previous mode and relaxes its

advertisement restrictions. Any link-state information may be

    advertised in the extended LSPs.  However, it mandates a change to
    the way LSPs are considered during the SPF algorithm, in a way
    that is not compatible with previous implementations.
 These modes are configured on a per-level and area basis.  That is,
 all LSPs considered in the same SPF instance MUST use the same Mode.
 There is no restriction that an L1/L2 IS operates in the same mode,
 for both its L1 and L2 instances.  It can use Mode 1 for its L1 LSPs,
 and Mode 2 for its L2 LSPs, or vice versa.
 Mode 1 has the only advantage of being backwards compatible with
 older implementations.  It does have restrictions which are
 considered drawbacks.  Therefore, routers should operate in Mode 1
 only if backwards compatibility is desired.  Otherwise, it is
 recommended to run in Mode 2.
 Routers MAY implement Operational Mode 2 without supporting running
 in Operational Mode 1.  They will still interoperate correctly with
 routers that support both modes.

1.4. Overview

 Using Additional system-ids assigned by the administrator, the
 Originating System can advertise the excess link-state information in
 extended LSPs under these Additional system-ids.  It would do so as
 if other routers, or "Virtual Systems", were advertising this
 information.  These extended LSPs will also have the specified limit
 on their LSP fragments; however, the Originating System may generate
 extended LSPs under numerous Virtual Systems.
 For Operation Mode 1, 0-cost adjacencies are advertised from the
 Originating System to its Virtual System(s).  No adjacencies (other
 than back to the Originating System) are advertised in the extended
 LSPs.  As a consequence, the Virtual Systems are 'stub', meaning they
 can only be reached through their Originating System.  Therefore,
 older implementations do not need modifications in order to correctly
 process these extended LSPs.
 For both modes, each LSP (set) created by a node will contain in its
 fragment-0 a new TLV (IS Alias ID TLV) that contains the Normal
 system-id and PN Number of the Original LSP created by the router.
 Extension-capable ISs can then use this information and store the
 original and extended LSPs as one logical LSP.
 The only sections that deal only with Mode 1 additions are 3.2,
 3.2.1, and 3.2.2.  All other sections relate to both modes.

Hermelin, et al. Informational [Page 4] RFC 3786 IS-IS LSP Fragments May 2004

2. IS Alias ID TLV (IS-A)

 The proposed IS-A TLV allows extension-capable ISs to recognize all
 LSPs of an Originating System, and combine the original and extended
 LSPs for the purpose of SPF computation.  It identifies the Normal
 system-id of the Originating System.
 The proposed IS Alias ID TLV is type 24, and its format is as
 follows:
 x CODE   - 24.
 x LENGTH - total length of the value field.
 x VALUE  -
                          No. of Octets
    +-------------------+
    | Normal system-id  |      6
    +-------------------+
    | Pseudonode number |      1
    +-------------------+
    | Sub-TLVs length   |      1
    +-------------------+
    |                   |     0-247
    : Sub-TLVs          :
    :                   :
    |                   |
    +-------------------+
 Normal system-id
    The Normal system-id of the LSP set, as described in section 1.2
    of this document.
 Pseudonode number
    The Pseudonode number of the LSP set.  LSPs with the same Normal
    system-id and Pseudonode number are considered in SPF as one
    logical LSP, as described in section 5 of this document.
 Sub-TLVs length
    Total length of all sub-TLVs.

Hermelin, et al. Informational [Page 5] RFC 3786 IS-IS LSP Fragments May 2004

 Sub-TLVs
 A series of tuples with the following format:
                       No. of Octets
 +-------------------+
 | Sub-type          |      1
 +-------------------+
 | Length            |      1
 +-------------------+
 |                   |     0-245
 : Value             :
 :                   :
 |                   |
 +-------------------+
 Sub-type
    Type of the sub-TLV
 Length
    Total length of the value field
 Value
    Type-specific TLV payload.
 For an explanation on sub-TLV handling, see [ISIS-TE].
 Without sub-TLVs, this structure consumes 8 octets per LSP set.  This
 TLV MUST be included in fragment 0 of every LSP set belonging to an
 Originating System running in either Mode 1 or Mode 2.  Currently,
 there are no sub-TLVs defined.
 For a complete list of used IS-IS TLV numbers, see [ISIS-CODES].

3. Generating LSPs

3.1. Both Operation Modes

 Under both modes, the Originating System MUST include information
 binding the Original LSP and the Extended ones.  It can do this since
 it is trivially an extension-capable IS.  This is to ensure other
 extension-capable routers correctly process the extra information in
 their SPF calculation.  This binding is advertised via a new IS Alias
 ID TLV, which is advertised in all fragment 0 of Original and
 Extended LSPs.

Hermelin, et al. Informational [Page 6] RFC 3786 IS-IS LSP Fragments May 2004

 +---------------------------------------------+
 |  Originating System                         |
 |  system-id   = S                            |
 |  is-alias-id = S                            |
 +---------------------------------------------+
 +-------------------+     +-------------------+
 |  Virtual System   |     |  Virtual System   |
 |  system-id   = S' |     |  system-id   = S''|
 |  is-alias-id = S  |     |  is-alias-id = S  |
 +-------------------+     +-------------------+
 Figure 1. Advertising binding between all of a system's LSPs
           (both modes).  S' and S'' are configured as Additional
           system-ids.
 When new extended LSP fragments are generated, these fragments should
 be generated as specified in ISO/IEC 10589 [ISIS-ISO].  Furthermore,
 a system SHOULD treat its extended LSPs the same as it treats its
 original LSPs, with the exceptions noted in the following sections.
 Specifically, creating, flooding, renewing, purging and all other
 operations are similar for both Original and Extended LSPs, unless
 stated otherwise.  The Extended LSPs will use one of the Additional
 system-ids configured for the router, in their LSP ID.
 Extended LSPs fragment zero should be regarded in the same special
 manner as specified in ISO/IEC 10589 for LSPs with number zero, and
 should include the same type of extra information as specified in
 ISO/IEC 10589 and RFC 1195 [ISIS-IP].  So, for example, when a system
 reissues its LSP fragment zero due to an area address change, it
 should reissue all extended LSPs fragment zero as well.
 An extended LSP fragment zero MUST be generated for every extended
 LSP set, to allow a router's SPF calculation to consider those
 fragments in that set.  See section 5 for details.

3.1.1. The Attached Bits

 The Attached (ATT) bits SHOULD be set to zero for all four metric
 types, on all Extended LSPs.  This is due to the following: if a
 Virtual System is reachable, so is its Originating System.  It is
 preferable, then, that an L1 IS chooses the Originating System and
 not the Virtual System as its nearest L2 exit point, as connectivity
 to the Virtual System has a higher probability of being lost (as a
 result of the extended LSP no longer being advertised).  This could
 cause unnecessary computations on some implementations.

Hermelin, et al. Informational [Page 7] RFC 3786 IS-IS LSP Fragments May 2004

3.1.2. The Partition Repair Bit

 The Partition Repair (P) bit SHOULD be set to zero on all extended
 LSPs.  This is for the same reasons as for the Attached bits.

3.1.3. ES Neighbors TLV

 ISO/IEC 10589 [ISIS-ISO] section 7.3.7 specifies inserting an ES
 Neighbor TLV in L1 LSPs, with the system ID of the router.  RFC 1195
 [ISIS-IP] relieves IP-only routers of this requirement.  However, for
 routers that do insert this ESN TLV in L1 LSPs (whether IP-only or
 OSI-capable), then in an extended LSP, the ESN TLV should include the
 relevant Additional system-id.  Furthermore, OSI-capable routers
 should accept packets destined for this Additional system-id.

3.1.4. Overload Bit

 The overload bit should be set consistently across all LSPs, original
 and extended, belonging to an Originating System, and should reflect
 the Originating System's overload state.

3.1.5. Other Fields and TLVs

 Other fields and TLVs not mentioned above remain the same, both for
 original and extended LSPs.

3.2. Operation Mode 1 Additions

 The following additions apply only to routers generating LSPs in Mode
 1.  Routers, which are configured to operate in Operation Mode 2,
 SHOULD NOT apply these additions to their advertisements.
 Under Operation Mode 1, adjacencies from the Originating System to
 its Virtual Systems are advertised using the standard neighbor TLVs.
 The metric for these connections MUST be zero, since the cost of
 reaching a Virtual System is the same as the cost of reaching its
 Originating System.
 To older implementations, Virtual Systems would appear reachable only
 through their Originating System, hence loss of connectivity to the
 Originating System means loss of connectivity to all of its
 information, including that advertised in its extended LSPs.
 Furthermore, the cost of reaching information advertised in non-
 extended LSPs is the same as the cost of reaching information
 advertised in the new extended LSPs, with an additional hop.

Hermelin, et al. Informational [Page 8] RFC 3786 IS-IS LSP Fragments May 2004

 +---------------------------------------------+
 |         Originating System                  |
 |         system-id = S                       |
 |         is-alias-id = S                     |
 +---------------------------------------------+
        |    /\                    |    /\
 cost=0 |    |cost=max-1    cost=0 |    |cost=max-1
        |    |                     |    |
        \/   |                     \/   |
 +-------------------+     +-------------------+
 |  Virtual System   |     |  Virtual System   |
 |  system-id   = S' |     |  system-id   = S''|
 |  is-alias-id = S  |     |  is-alias-id = S  |
 +-------------------+     +-------------------+
 Figure 2. Advertising connections to Virtual Systems under
           Operation Mode 1.  S' and S'' are configured as
           Additional system-ids.
 Under Operation Mode 1, only "leaf" information, i.e., information
 that serves only as leaves in a shortest path tree, can be advertised
 in extended LSPs.
 When an Extended LSP belonging to Additional system-id S' is first
 created, the Original LSP MUST specify S' as a neighbor, with metric
 set to zero.  This is in order to consider the cost of reaching the
 Virtual System S' the same as the cost of reaching its Originating
 System.  Furthermore, the Extended LSP MUST specify the Normal
 system-id as a neighbor.  The metric SHOULD be set to MaxLinkMetric -
 1 (this is only for uniformity purpose, any metric greater than zero
 is acceptable).  This in order to satisfy the two-way connectivity
 check on other routers.  Where relevant, this adjacency SHOULD be
 considered as point-to-point.
 Note, that the restriction specified in ISO/IEC 10589 section 7.2.5
 holds:  if an LSP Number zero of the Originating System is not
 present, none of that system's neighbor entries would be processed
 during SPF, hence none of its extended LSPs would be processed as
 well.

3.2.1. IS Neighbors TLV (Mode 1 Only)

 An Extended LSP must specify only the Originating System as a
 neighbor, with the metric set to (MaxLinkMetric - 1).  Where
 relevant, this adjacency should be considered as point-to-point.
 Other neighbors MUST NOT be specified in an Extended LSP, because

Hermelin, et al. Informational [Page 9] RFC 3786 IS-IS LSP Fragments May 2004

 those other neighbors would only specify the Originating System and
 not the Virtual System, and hence would not satisfy the bi-
 directionality check in the SPF computation.

3.2.2. Originating System in the Overload State in (Mode 1 Only)

 If the Originating System is in the overload state, information in
 the extended LSPs will not be processed by other routers in their SPF
 computation.  This is because in Mode 1, extended LSPs are reachable
 only through adjacencies from the Original LSP.  If this LSP has set
 its OL bit, adjacencies will not be processed in the SPF computation.
 This side effect should be taken into consideration when operating in
 Mode 1.

4. Purging Extended LSP Fragments

 ISO/IEC 10589 [ISIS-ISO] section 7.3.4.4 note 25 suggests that an
 implementation keeps the number of LSP fragments within a certain
 limit based on the optimal (minimal) number of fragments needed.
 Section 7.3.4.6 also recommends that an IS purge its empty LSPs to
 conserve resources.  These recommendations hold for the extended LSP
 fragments as well.  However, an extended LSP fragment zero should not
 be purged until all of the fragments in its set (i.e., belonging to a
 particular Additional system-id), are empty as well.  This is to
 ensure implementations consider the fragments in their SPF
 computations, as specified in section 7.2.5.
 In Operational Mode 1, when all the extended LSP fragments of a
 particular Additional system-id S' have been purged, the Originating
 System SHOULD remove the neighbor information to S' from its original
 LSPs.

5. Modifications to LSP handling in SPF

 This section describes modifications to the way extension-capable ISs
 handle LSPs for the SPF computation.
 When considering LSPs of an extension-capable IS (identified by the
 inclusion of the IS Alias ID TLV), the original and extended LSPs are
 combined to form one large logical LSP.  If the LSP belongs to an IS
 running Operational Mode 1, there might be adjacencies between the
 original and extended LSPs.  These are trivially ignored (since when
 processing them the large logical LSP is already on PATHS), and does
 not complicate the SPF.  Furthermore, this check should already be
 implemented (this scenario could occur on error, without this
 extension).

Hermelin, et al. Informational [Page 10] RFC 3786 IS-IS LSP Fragments May 2004

 If LSP fragment 0 of the Original LSP set is missing or its
 RemainingLifetime is zero, all of the LSPs generated by that
 Originating System (Extended as well) MUST NOT be considered in the
 SPF.  That is, the large logical LSP is not considered in the SPF.
 The original LSP fragments are identified when the is-alias-id value
 is the same as the system-id of those LSPs.  If an LSP fragment 0 of
 an extended LSP set is missing or its RemainingLifetime is zero, only
 that LSP set MUST NOT be considered in the SPF.  These rules are
 present to ensure consistent SPF results on Mode 1 and Mode 2 LSPs.
 Note, that the above behavior is consistent with how previous
 implementations will interpret Mode 1 LSPs.

6. Forming Adjacencies

 It should be noted, that an IS MUST use the system-id of the LSP that
 will include a neighbor, when forming an adjacency with that
 neighbor.  That is, if a neighbor is to be included in extended LSP
 S', then S' should be used as the system-id in IS Hellos [3] and IS-
 IS Hellos when forming an adjacency with that neighbor.  This is
 regardless of the Operational Mode.  Of course, in Mode 1 this means
 that only the Normal system-id will be used when sending hellos.

7. Interoperating between extension-capable and non-extension-capable

  ISs.
 In order to correctly advertise link-state information under
 Operation Mode 2, all ISs in an area must be extension-capable.
 However, it is possible to not upgrade every router in the network,
 if the extended information is not routing information, but rather
 data that is of use to only a subset of routers (e.g., optical
 switches using IS-IS could carry optical-specific information in
 extended LSPs)
 If a live network contains routers exceeding the 256 fragment limit,
 and for some reason the upgrade has to be done incrementally, it is
 possible to transition the network, using the following steps:
  1. Upgrade the routers, one-by-one, to run this extension in

Operation Mode 1. The other non-extension-capable routers will

    interoperate correctly.
  1. When all routers are extension-capable, configure them one-by-one

to run in Operation Mode 2. All extension-capable routers

    interoperate correctly, regardless of what mode they are run in.

Hermelin, et al. Informational [Page 11] RFC 3786 IS-IS LSP Fragments May 2004

 Implementations SHOULD support a configuration parameter controlling
 the LSP origination behavior.  The default value of this parameter
 SHOULD correspond to the behavior described in [ISIS-ISO], i.e.,
 neither of the two modes described in this document should be enabled
 without explicit configuration when the router software is upgraded
 with this extension.

8. Security Considerations

 This document raises no new security issues for IS-IS.

9. Acknowledgments

 The authors would like to thank Tony Li and Radia Perlman for helpful
 comments and suggestions on the subject.

10. References

10.1. Normative References

 [ISIS-ISO]    "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/IEC 10589:2002, Second Edition.
 [ISIS-IP]     Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
               dual environments", RFC 1195, December 1990.
 [ISIS-TE]     Smit, H. and T. Li, "Intermediate System to
               Intermediate System (IS-IS) Extensions for Traffic
               Engineering (TE)", RFC 3784, May 2004.
 [BCP14]       Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2. Informative References

 [DOMAIN-WIDE] Li, T., Przygienda, T. and H. Smit, "Domain-wide Prefix
               Distribution with Two-Level IS-IS", RFC 2966, October
               2000.
 [ISIS-CODES]  Przygienda, T., "Reserved Type, Length and Value (TLV)
               Codepoints in Intermediate System to Intermediate
               System", RFC 3359, August 2002.

Hermelin, et al. Informational [Page 12] RFC 3786 IS-IS LSP Fragments May 2004

11. Authors' Addresses

 Amir Hermelin
 Montilio Inc.
 1 Maskit St.
 POB 12253
 Herzelia, 46733
 ISRAEL
 Phone: +972 9 9511944
 Fax: +972 9 9542430
 EMail: amir@montilio.com
 Stefano Previdi
 Cisco Systems, Inc.
 Via Del Serafico 200
 00142 Roma
 Italy
 Phone: +39 06 5164 4491
 EMail: sprevidi@cisco.com
 Mike Shand
 Cisco Systems
 250, Longwater Avenue,
 Green Park,
 Reading,
 RG2 6GB,
 UK
 Phone: +44 20 8824 8690
 EMail: mshand@cisco.com

Hermelin, et al. Informational [Page 13] RFC 3786 IS-IS LSP Fragments May 2004

12. 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.

Intellectual Property

 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.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Hermelin, et al. Informational [Page 14]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3786.txt · Last modified: 2004/05/25 22:02 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki