| Networking Working Group | L. Ginsberg |
| Internet-Draft | S. Previdi |
| Intended status: Standards Track | Y. Yang |
| Expires: March 16, 2014 | Cisco Systems |
| September 12, 2013 |
IS-IS Flooding Scope LSPs
draft-ietf-isis-fs-lsp-00.txt
Intermediate System To Intermediate System (IS-IS) provides efficient and reliable flooding of information to its peers. However the current flooding scopes are limited to either area wide scope or domain wide scope. There are existing use cases where support of other flooding scopes are desirable. This document defines new Protocol Data Units (PDUs) which provide support for new flooding scopes as well as additional space for advertising information targeted for the currently supported flooding scopes.
The protocol extensions defined in this document are not backwards compatible with existing implementations and so must be deployed with care.
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 [RFC2119].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on March 16, 2014.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
The Update Process as defined by [IS-IS] provides reliable and efficient flooding of information to all routers in a given flooding scope. Currently the protocol supports two flooding scopes and associated Protocol Data Units (PDUs). Level 1 (L1) Link State PDUs (LSPs) are flooded to all routers in an area. Level 2 (L2) LSPs are flooded to all routers in the Level 2 sub-domain. The basic operation of the Update Process can be applied to any subset of the routers in a given topology so long as that topology is not partitioned. It is therefore possible to introduce new PDUs in support of other flooding scopes and utilize the same Update Process machinery to provide the same reliability and efficiency which the Update Process currently provides for L1 and L2 scopes. This document defines these new PDUs and the modified Update Process rules which are to be used in supporting new flooding scopes.
New deployment cases have introduced the need for reliable and efficient circuit scoped flooding. For example, Appointed Forwarder information as defined in [RFC6326] needs to be flooded reliably and efficiently to all RBridges on a broadcast circuit. Currently, only Intermediate System to Intermediate System Hellos (IIHs) have the matching scope - but IIHs are unreliable i.e. individual IIHs may be lost without affecting correct operation of the protocol. To provide reliability in cases where the set of information to be flooded exceeds the carrying capacity of a single PDU requires sending the information periodically even when no changes in the content have occurred. When the information content is large this is inefficient and still does not provide a guarantee of reliability. This document defines circuit scoped flooding in order to provide a solution for such cases.
Another existing limitation of [IS-IS] is the carrying capacity of an LSP set. It has been noted in [RFC5311] that the set of LSPs that may be originated by a system at each level is limited to 256 LSPs and the maximum size of each LSP is limited by the minimum Maximum Transmission Unit (MTU) of any link used to flood LSPs. [RFC5311] has defined a backwards compatible protocol extension which can be used to overcome this limitation if needed. While the [RFC5311] solution is viable, in order to be interoperable with routers which do not support the extension it imposes some restrictions on what can/cannot be advertised in the Extended LSPs and requires allocation of multiple unique system IDs to a given router. A more flexible and less constraining solution is possible if interoperability with legacy routers is not a requirement. As the introduction of new PDUs required to support new flooding scopes is by definition not interoperable with legacy routers, it is possible to simultaneously introduce an alternative solution to the limited LSP set carrying capacity as part of the extensions defined in this document. This capability is also defined in this document.
The PDU type field in the common header for all IS-IS PDUs is a 5 bit field. The possible PDU types supported by the protocol are therefore limited to a maximum of 32. In order to minimize the need to introduce additional PDU types in the future, the new PDUs introduced in this document are defined so as to allow multiple flooding scopes to be associated with the same PDU type. This means if new flooding scopes are required in the future the same PDU type can be used.
In support of new flooding scopes the following new PDUs are required:
Each of these PDUs is intentionally defined with a header as similar in format as possible to the corresponding PDU types currently defined in [IS-IS]. Although it might have been possible to eliminate or redefine PDU header fields in a new way the existing formats are retained in order to allow maximum reuse of existing PDU processing logic in an implementation.
Note that in the case of all FS PDUs, the Maximum Area Addresses field in the header of the corresponding standard PDU has been replaced with a Scope field. The maximum area addresses checks specified in [IS-IS] are therefore not performed on FS PDUs.
An FS-LSP has the following format:
No. of octets
+-------------------------+
| Intradomain Routeing | 1
| Protocol Discriminator |
+-------------------------+
| Length Indicator | 1
+-------------------------+
| Version/Protocol ID | 1
| Extension |
+-------------------------+
| ID Length | 1
+-------------------------+
|R|R|R| PDU Type | 1
+-------------------------+
| Version | 1
+-------------------------+
| Reserved | 1
+-------------------------+
|P| Scope | 1
+-------------------------+
| PDU Length | 2
+-------------------------+
| Remaining Lifetime | 2
+-------------------------+
| FS LSP ID | ID Length + 2
+-------------------------+
| Sequence Number | 4
+-------------------------+
| Checksum | 2
+-------------------------+
|Reserved|LSPDBOL|IS Type | 1
+-------------------------+
: Variable Length Fields : Variable
+-------------------------+
Intradomain Routeing Protocol Discriminator - 0x83
(as defined in [IS-IS])
Length Indicator - Length of the Fixed Header in octets
Version/Protocol ID Extension - 1
ID Length - As defined in [IS-IS]
PDU Type - 10 (Subject to assignment by IANA) Format as
defined in [IS-IS]
Version - 1
Reserved - transmitted as zero, ignored on receipt
Scope - Bits 1-7 define the flooding scope.
The value 0 is reserved
and MUST NOT be used. Received FS-LSPs with a scope of 0 MUST
be ignored.
P - Bit 8 - Priority Bit. If set to 1 this LSP SHOULD be flooded
at high priority.
PDU Length - Entire Length of this PDU, in octets, including the
header.
Remaining Lifetime - Number of seconds before this FS-LSP is
considered expired.
FS LSP ID - the system ID of the source of the FS-LSP. One of
the following two formats is used:
FS LSP ID Standard Format
+-------------------------+
| Source ID | ID Length
+-------------------------+
| Pseudonode ID | 1
+-------------------------+
| FS LSP Number | 1
+-------------------------+
FS LSP ID Extended Format
+-------------------------+
| Source ID | ID Length
+-------------------------+
| Extended FS LSP Number | 2
+-------------------------+
Which format is used is specific to the Scope and MUST be defined
when the specific flooding scope is defined.
Sequence Number - sequence number of this FS-LSP
Checksum - Checksum of contents of FS-LSP from Source ID to end.
Checksum is computed as defined in [IS-IS].
Reserved/LSPDBOL/IS Type
Bits 4-8 are reserved, which means they are transmitted as 0 and
ignored on receipt.
LSPDBOL - Bit 3 - A value of 0 indicates no FS-LSP Database
Overload and a value of 1 indicates that the FS-LSP Database is
overloaded. The overload condition is specific to FS-LSPs with the
scope specified in the scope field.
IS Type - Bits 1 and 2. The type of Intermediate System as defined
in [IS-IS].
Variable Length Fields which are allowed in an FS-LSP are specific to
the defined scope.
An FS-CSNP has the following format:
No. of octets
+-------------------------+
| Intradomain Routeing | 1
| Protocol Discriminator |
+-------------------------+
| Length Indicator | 1
+-------------------------+
| Version/Protocol ID | 1
| Extension |
+-------------------------+
| ID Length | 1
+-------------------------+
|R|R|R| PDU Type | 1
+-------------------------+
| Version | 1
+-------------------------+
| Reserved | 1
+-------------------------+
|R| Scope | 1
+-------------------------+
| PDU Length | 2
+-------------------------+
| Source ID | ID Length + 1
+-------------------------+
| Start FS-LSP ID | ID Length + 2
+-------------------------+
| End FS-LSP ID | ID Length + 2
+-------------------------+
: Variable Length Fields : Variable
+-------------------------+
Intradomain Routeing Protocol Discriminator - 0x83
(as defined in [IS-IS]
Length Indicator - Length of the Fixed Header in octets
Version/Protocol ID Extension - 1
ID Length - As defined in [IS-IS]
PDU Type - 11 (Subject to assignment by IANA) Format as defined in
[IS-IS]
Version - 1
Reserved - transmitted as zero, ignored on receipt
Scope - Bits 1-7 define the flooding scope.
The value 0 is reserved
and MUST NOT be used. Received FS-CSNPs with a scope of 0 MUST
be ignored.
Bit 8 is Reserved which means it is transmitted as 0 and
ignored on receipt.
PDU Length - Entire Length of this PDU, in octets, including the
header.
Source ID - the system ID of the Intermediate System
(with zero Circuit ID) generating this Sequence Numbers PDU
Start FS-LSP ID - The FS-LSP ID of the first FS-LSP with the
specified scope in the range covered by this FS-CSNP.
End FS-LSP ID - The FS-LSP ID of the last FS-LSP with the
specified scope in the range covered by this FS-CSNP.
Variable Length Fields which are allowed in an FS-CSNP are
limited to those TLVs which are supported by standard CSNP.
An FS-PSNP has the following format:
No. of octets
+-------------------------+
| Intradomain Routeing | 1
| Protocol Discriminator |
+-------------------------+
| Length Indicator | 1
+-------------------------+
| Version/Protocol ID | 1
| Extension |
+-------------------------+
| ID Length | 1
+-------------------------+
|R|R|R| PDU Type | 1
+-------------------------+
| Version | 1
+-------------------------+
| Reserved | 1
+-------------------------+
|U| Scope | 1
+-------------------------+
| PDU Length | 2
+-------------------------+
| Source ID | ID Length + 1
+-------------------------+
: Variable Length Fields : Variable
+-------------------------+
Intradomain Routeing Protocol Discriminator - 0x83
(as defined in [IS-IS]
Length Indicator - Length of the Fixed Header in octets
Version/Protocol ID Extension - 1
ID Length - As defined in [IS-IS]
PDU Type - 12 (Subject to assignment by IANA) Format
as defined in [IS-IS]
Version - 1
Reserved - transmitted as zero, ignored on receipt
Scope - Bits 1-7 define the flooding scope.
The value 0 is reserved
and MUST NOT be used. Received FS-PSNPs with a scope of 0 MUST
be ignored.
U - Bit 8 - A value of 0 indicates that the specified
flooding scope is supported. A value of 1 indicates
that the specified flooding scope is unsupported. When
U = 1, variable length fields other than authentication
MUST NOT be included in the PDU.
PDU Length - Entire Length of this PDU, in octets, including
the header.
Source ID - the system ID of the Intermediate System
(with zero Circuit ID) generating this Sequence Numbers PDU
Variable Length Fields which are allowed in an FS-PSNP are
limited to those TLVs which are supported by standard PSNPs.
The Update Process as defined in [IS-IS] maintains a Link State Database (LSDB) for each level supported. Each level specific LSDB contains the full set of LSPs generated by all routers operating in that level specific scope. The introduction of FS-LSPs creates additional LSDBs (FS-LSDBs) for each additional scope supported. The set of FS-LSPs in each FS-LSDB consists of all FS-LSPs generated by all routers operating in that scope. There is therefore an additional instance of the Update Process for each supported flooding scope.
Operation of the scope specific Update Process follows the Update Process specification in [IS-IS]. The circuit(s) on which FS-LSPs are flooded are limited to those circuits which are participating in the given scope. Similarly the sending/receiving of FS-CSNPs and FS-PSNPs is limited to the circuits participating in the given scope.
Consistent support of a given flooding scope on a circuit by all routers operating on that circuit is required.
A flooding scope may be limited to a single circuit (circuit scope). Circuit scopes may be further limited by level (L1 circuit scope/L2 circuit scope).
A flooding scope may be limited to all circuits enabled for L1 routing (area scope).
A flooding scope may be limited to all circuits enabled for L2 routing (L2 sub-domain scope).
Additional scopes may be defined which include all circuits enabled for either L1 or L2 routing (domain-wide scope).
When a new adjacency is formed, synchronization of all FS-LSDBs supported on that circuit is required. Therefore FS-CSNPs for all supported scopes MUST be sent when a new adjacency reaches the UP state. Send Receive Message (SRM) bit MUST be set for all FS-LSPs associated with the scopes supported on that circuit. Receipt of an FS-PSNP with the U bit equal to 1 indicates that the neighbor does not support that scope (although it does support FS PDUs). This MUST cause SRM bit to be cleared for all FS-LSPs with the matching scope which are currently marked for flooding on that circuit.
FS PDUs are sent to the same destination address(es) as standard PDUs for the given protocol instance. For specification of the defined destination addresses consult [IS-IS], [IEEEaq], [RFC6822], and [RFC6325].
The Designated Intermediate System (DIS) for a broadcast circuit has the responsibility to generate periodic scope specific FS-CSNPs for all supported scopes. A scope specific DIS is NOT elected as all routers on a circuit MUST support a consistent set of flooding scopes.
It is possible that a scope may be defined which is not level specific. In such a case the DIS for each level enabled on a broadcast circuit MUST independently send FS PDUs for that scope to the appropriate level specific destination address. This may result in redundant flooding of FS-LSPs for that scope.
Authentication TLVs MAY be included in FS PDUs. When authentication is in use, the scope is first used to select the authentication configuration that is applicable. The authentication check is then performed as normal. Although scope specific authentication MAY be used, sharing of authentication among multiple scopes and/or with the standard LSP/CSNP/PSNP PDUs is considered sufficient.
When the FS LSP ID Extended Format is used the set of LSPs generated by an IS may be quite large. It may be useful to identify those LSPs in the set which contain information of higher priority. Such LSPs will have the P bit set to 1 in the Scope field in the LSP header. Such LSPs SHOULD be flooded at a higher priority than LSPs with the P bit set to 0. This is a suggested behavior on the part of the originator of the LSP. When an LSP is purged the original state of the P bit MUST be preserved.
Introduction of new PDU types is incompatible with legacy implementations. Legacy implementations do not support the FS specific Update process(es) and therefore flooding of the FS-LSPs throughout the defined scope is unreliable when not all routers in the defined scope support FS PDUs. Further, legacy implementations will likely treat the reception of an FS PDUs as an error. Even when all routers in a given scope support FS PDUs, if not all routers in the flooding domain for a given scope support that scope flooding of the FS-LSPs may be compromised. Therefore all routers in the flooding domain for a given scope SHOULD support both FS PDUs and the specified scope before use of that scope can be enabled.
The U bit in FS-PSNPs provides a means to suppress retransmissions of unsupported scopes. Routers which support FS PDUs SHOULD support the sending of PSNPs with the U bit equal to 1 when an FS-LSP is received with a scope which is unsupported. Routers which support FS PDUs SHOULD trigger management notifications when FS PDUs are received for unsupported scopes and when PSNPs with the U bit equal to 1 are received.
[RFC5306] defines protocol extensions in support of graceful restart of a routing instance. Synchronization of all supported FS-LSDBs is required in order for database synchronization to be complete. This involves the use of additional T2 timers. Receipt of a PSNP with the U bit equal to 1 will cause FS-LSDB synchronization with that neighbor to be considered complete for that scope. See [RFC5306] for further details.
In cases where FS-PDUs are associated with a non-zero instance the use of IID-TLVs in FS-PDUs follows the rules for use in LSPs, CSNPs, PSNPs as defined in [RFC6822].
This document defines two circuit scoped flooding identifiers:
FS-LSPs with the scope field set to one of these values contain information specific to the circuit on which they are flooded. When received, such FS-LSPs MUST NOT be flooded on any other circuit. The FS LSP ID Extended format is used in these PDUs. The FS-LSDB associated with circuit scoped FS-LSPs consists of the set of FS-LSPs which both have matching circuit scope and are transmitted(locally generated) or received on a specific circuit.
The set of TLVs which may be included in such FS-LSPs is specific to the given use case and is outside the scope of this document.
The need for additional space in the set of LSPs generated by a single IS has been articulated in [RFC5311]. When legacy interoperability is not a requirement, the use of FS-LSPs meets that need without requiring the assignment of alias system-ids to a single IS. Two flooding scopes are defined for this purpose:
The FS LSP ID Extended format is used in these PDUs. This provides 64K of additional LSPs which may be generated by a single system at each level.
Lx-FS-LSPs are used by the level specific Decision Process (defined in [IS-IS]) in the same manner as standard LSPs (i.e. as additional information sourced by the same IS) subject to the following restrictions:
There are no further restrictions as to what TLVs may be advertised in FS-LSPs.
Existing support for flooding information domain wide (i.e. to L1 routers in all areas as well as to routers in the Level 2 sub-domain) requires the use of leaking procedures between levels. For further details see [RFC4971]. This is sufficient when the data being flooded domain-wide consists of individual TLVs. If it is desired to retain the identity of the originating IS for the complete contents of a PDU, then support for flooding the unchanged PDU is desirable. This document therefore defines a domain-wide flooding scope. FS-LSPs with this scope MUST be flooded on all circuits regardless of what level(s) are supported on that circuit.
The FS LSP ID Extended format is used in these PDUs.
Use of information in FS-LSPs for a given scope depends on determining the reachability to the IS originating the FS-LSP. This presents challenges for FS-LSPs with domain-scopes because no single IS has the full view of the topology across all areas. It is therefore necessary for the originator of domain scoped FS-LSPs to advertise an identifier which will allow an IS who receives such an FS-LSP to determine whether the source of the FS-LSP is currently reachable. The identifier required depends on what "address-families" are being advertised.
When IS-IS is deployed in support of Layer 3 routing for IPv4 and/or IPv6 then FS-LSP #0 with domain-wide scope MUST include at least one of the following TLVs:
When IS-IS is deployed in support of Layer 2 routing, current standards (e.g. [RFC6325]) only support a single area. Therefore domain-wide scope is not yet applicable. When the Layer 2 standards are updated to include multi-area support the identifiers which can be used to support inter-area reachability will be defined - at which point the use of domain-wide scope for Layer 2 can be fully defined.
Announcements of support for flooding scope may be useful in validating that full support has been deployed and/or in isolating the reasons for incomplete flooding of FS-LSPs for a given scope.
ISs supporting FS-PDUs MAY announce supported scopes in IIH PDUs. To do so a new TLV is defined.
Scoped Flooding Support
Type: 243 (suggested - to be assigned by IANA)
Length: 1 - 127
Value
No of octets
+----------------------+
|R| Supported Scope | 1
+----------------------+
: :
+----------------------+
|R| Supported Scope | 1
+----------------------+
A list of the circuit scopes supported on this circuit and
other non-circuit flooding scopes supported.
R bit MUST be 0 and is ignored on receipt.
In a Point-Point IIH L1, L2 and domain-wide scopes MAY
be advertised.
In Level 1 LAN IIHs L1 and domain-wide scopes MAY be advertised.
In Level 2 LAN IIHs L2 and domain-wide scopes MAY be advertised.
Information in this TLV MUST NOT be considered in adjacency formation.
Whether information in this TLV is used to determine when FS-LSPs associated with a locally supported scope are flooded is an implementation choice.
This document requires the definition of three new PDU types that need to be reflected in the ISIS PDU registry. Values below are suggested values subject to assignment by IANA.
Value Description ---- --------------------- 10 FS-LSP 11 FS-CSNP 12 FS-PSNP
This document requires that a new IANA registry be created to control the assignment of scope identifiers in FS-PDUs. The registration procedure is "Expert Review" as defined in [RFC5226]. Suggested registry name is "LSP Flooding Scoped Identifier Registry". A scope identifier is a number from 1-127 inclusive. The following scope identifiers are defined by this document. Values are suggested values subject to assignment by IANA.
Value Description FS LSP ID Format ----- ------------------------------ ---------------- 1 Level 1 Circuit Flooding Scope Extended 2 Level 2 Circuit Flooding Scope Extended 3 Level 1 Flooding Scope Extended 4 Level 2 Flooding Scope Extended 5 Domain-wide Flooding Scope Extended
This document requires the definition of a new IS-IS TLV to be reflected in the "IS-IS TLV Codepoints" registry:
Type Description IIH LSP SNP Purge ---- ------------ --- --- --- ----- 243 Circuit Scoped Flooding Support Y N N N
Security concerns for IS-IS are addressed in [IS-IS], [RFC5304], and [RFC5310].
The new PDUs introduced are subject to the same security issues associated with their standard LSP/CSNP/PSNP counterparts. To the extent that additional PDUs represent additional load for routers in the network this increases the opportunity for denial of service attacks.
The authors wish to thank Ayan Banerjee, Donald Eastlake, and Mike Shand for their comments.
| [RFC5311] | McPherson, D., Ginsberg, L., Previdi, S. and M. Shand, "Simplified Extension of Link State PDU (LSP) Space for IS-IS", RFC 5311, February 2009. |
| [RFC6325] | Perlman, R., Eastlake, D., Dutt, D., Gai, S. and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011. |
| [RFC6326] | Eastlake, D., Banerjee, A., Dutt, D., Perlman, R. and A. Ghanwani, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 6326, July 2011. |