RFC 8258 PROPOSED STANDARD ROUTING · GMPLS
Generalized SCSI: A Generic Structure for Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI)
A reusable type-length-value layout for the technology-specific part of GMPLS routing advertisements.
RFC EDITOR
Ceccarelli, D. and L. Berger, "Generalized SCSI: A Generic Structure for Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI)", RFC 8258, DOI 10.17487/RFC8258, October 2017, <https://www.rfc-editor.org/info/rfc8258>.
BIBTEX
@misc{rfc8258,
series = {Request for Comments},
number = 8258,
howpublished = {RFC 8258},
publisher = {RFC Editor},
doi = {10.17487/RFC8258},
url = {https://www.rfc-editor.org/info/rfc8258},
author = {D. Ceccarelli and L. Berger},
title = {{Generalized SCSI: A Generic Structure for Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI)}},
pagetotal = 7,
year = 2017,
month = oct,
} RFC text
Contents
Internet Engineering Task Force (IETF) D. Ceccarelli
Request for Comments: 8258 Ericsson
Category: Standards Track L. Berger
ISSN: 2070-1721 LabN Consulting, L.L.C.
October 2017
Generalized SCSI: A Generic Structure
for Interface Switching Capability Descriptor (ISCD)
Switching Capability Specific Information (SCSI)
Abstract
This document defines a generic information structure for information
carried in routing protocol Interface Switching Capability Descriptor
(ISCD) Switching Capability Specific Information (SCSI) fields. This
"Generalized SCSI" can be used with routing protocols that define
GMPLS ISCDs and any specific technology. This document does not
modify any existing technology-specific formats and is defined for
use in conjunction with new GMPLS Switching Capability types. The
context for this document is Generalized MPLS, and the reader is
expected to be familiar with the GMPLS architecture and associated
protocol standards.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8258.
Copyright Notice
Copyright (c) 2017 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
(https://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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Generalized SCSI Formats . . . . . . . . . . . . . . . . . . 3
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
The context for this document is Generalized MPLS, and the reader is
expected to be familiar with the GMPLS architecture, associated
terminology, and protocol standards: notably, but not limited to,
[RFC3945], [RFC4202], [RFC4203] and [RFC5307].
The Interface Switching Capability Descriptor (ISCD) [RFC4202] allows
routing protocols such as OSPF and ISIS to carry technology-specific
information in the Switching Capability-specific information field,
see [RFC4203] and [RFC5307]. The format of an SCSI field is dictated
by the specific technology being represented as indicated by the ISCD
Switching Capability field. Existing Switching Capabilities are
managed by IANA in the "Switching Types" registry
<http://www.iana.org/assignments/gmpls-sig-parameters> and the
related "IANA-GMPLS-TC-MIB" definitions.
[RFC7138] introduced a "sub-TLV" structure to its technology-specific
SCSI field. The sub-TLV-based approach allows for greater
flexibility in the structure, ordering, and ability to support
extensions of the SC-specific format. This Sub-TLV approach is also
used in [RFC7688].
This document generalizes this approach and defines a new generalized
SCSI field format for use by future specific technologies and
Switching Capability types. The generalized SCSI carries SCSI-TLVs
that may be defined within the scope of a specific technology or
shared across multiple technologies (e.g., [AVAIL-EXT]). This
document also establishes a registry for SCSI-TLV definitions that
may be shared across multiple technologies.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The reader is expected to be familiar with GMPLS terminology (e.g.,
as found in [RFC3945]) as well as the terminology used in [RFC4202],
[RFC4203], and [RFC5307].
3. Generalized SCSI Formats
The Generalized SCSI is composed of zero or more variable-length TLV
fields each of which is called an "SCSI-TLV". There are no specific
size restrictions on these SCSI-TLVs. Size and other formatting
restrictions may be imposed by the routing protocol ISCD field (refer
to [RFC4203] and [RFC5307]). Please refer to [RFC3630] for the
treatment of malformed Link TLVs.
The SCSI-TLV format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: TLV Format
Type (2 octets):
This field indicates the type and structure of the information
contained in the Value field.
Length (2 octets):
This field MUST be set to the size, in octets (bytes), of the
Value field. The value of the field MUST be zero or divisible by
4. Note that this implies that the Value field can be omitted or
contain padding.
Value (variable):
A variable-length field, formatted according to the definition
indicated by value of the Type field. This field can be omitted
for certain types.
4. Procedures
The ISCD can include a Generalized SCSI when advertising technologies
whose Switching Capability definition references this document. The
corollary of this is that the Generalized SCSI MUST NOT be used for
ISCDs of technologies whose Switching Capability definition do not
reference this document.
The Generalized SCSI MAY contain a sequence of zero or more SCSI-
TLVs. Sub-TLV parsing (format) errors MUST be treated as a malformed
ISCD. SCSI-TLVs MUST be processed in the order received and, if re-
originated, ordering MUST be preserved. Unknown SCSI-TLVs MUST be
ignored and transparently processed, i.e., re-originated when
appropriate. Processing related to multiple SCSI-TLVs of the same
type may be further refined based on the definition on the type.
5. Security Considerations
This document does not introduce any security issue beyond those
discussed in [RFC4203] and [RFC5307]. As discussed there, the
information carried in ISCDs is not used for Shortest Path First
(SPF) computation or normal routing, and the extensions here defined
do not have a direct effect on IP routing. Tampering with GMPLS
Traffic Engineering (TE) Link State Advertisements (LSAs) may have an
effect on the underlying transport network. Mechanisms such as those
described in [RFC2154] and [RFC5304] to protect the transmission of
this information are suggested.
6. IANA Considerations
This document defines a new SCSI-TLV that is carried in the SCSI
field of the ISCDs defined in [RFC4203] and [RFC5307]. The SCSI-TLV
includes a 16-bit type identifier (the Type field). The same Type
field values are applicable to the new SCSI-TLV.
IANA has created and will maintain a new registry, the "Generalized
SCSI (Switching Capability Specific Information) TLV Types" registry
under the "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Parameters" registry.
The initial contents of this registry are as follows:
Value SCSI-TLV Switching Type Reference
--------- ----------------------- -------------- ---------
0 Reserved [RFC8258]
1-65535 Unassigned (value list)
New allocation requests to this registry must indicate the value or
values to be used in the Switching Type column.
The registry should be established with registration policies of
"Specification Required", see [RFC8126].
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,
<https://www.rfc-editor.org/info/rfc4202>.
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
<https://www.rfc-editor.org/info/rfc4203>.
[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
<https://www.rfc-editor.org/info/rfc5307>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References
[AVAIL-EXT]
Long, H., Ye, M., Mirsky, G., D'Alessandro, A., and H.
Shah, "OSPF-TE Link Availability Extension for Links with
Variable Discrete Bandwidth", Work in Progress,
draft-ietf-ccamp-ospf-availability-extension-10,
August 2017.
[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with
Digital Signatures", RFC 2154, DOI 10.17487/RFC2154, June
1997, <https://www.rfc-editor.org/info/rfc2154>.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945,
DOI 10.17487/RFC3945, October 2004,
<https://www.rfc-editor.org/info/rfc3945>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, DOI 10.17487/RFC5304, October
2008, <https://www.rfc-editor.org/info/rfc5304>.
[RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and
J. Drake, "Traffic Engineering Extensions to OSPF for
GMPLS Control of Evolving G.709 Optical Transport
Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014,
<https://www.rfc-editor.org/info/rfc7138>.
[RFC7688] Lee, Y., Ed. and G. Bernstein, Ed., "GMPLS OSPF
Enhancement for Signal and Network Element Compatibility
for Wavelength Switched Optical Networks", RFC 7688,
DOI 10.17487/RFC7688, November 2015,
<https://www.rfc-editor.org/info/rfc7688>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
Acknowledgments
The authors would like to thank Adrian Farrel and Julien Meuric for
the careful review and suggestions. Thomas Heide Clausen provided
useful comments as part of the Routing Directorate review.
Authors' Addresses
Daniele Ceccarelli
Ericsson
Torshamnsgatan 21
Kista - Stockholm
Sweden
Email: daniele.ceccarelli@ericsson.com
Lou Berger
LabN Consulting, L.L.C.
Email: lberger@labn.net
AI ELI5
On this page
PROBLEMEach new GMPLS switching technology needs a format for the Switching Capability Specific Information (SCSI) field in routing advertisements, and inventing a new layout each time is wasteful.
MECHANISMThe RFC defines one generic structure: zero or more SCSI-TLVs, each with a 2-octet Type, a 2-octet Length and a Value, plus rules for processing them and a new IANA registry for type values.
WHY IT MATTERSNew technologies can reference this document instead of defining their own SCSI layout. Existing technology-specific formats are not changed.
§1Why a Generic SCSI
In Generalized MPLS (GMPLS), routing protocols such as OSPF and IS-IS advertise links using an Interface Switching Capability Descriptor (ISCD), defined in RFC 4202. The ISCD has a field called Switching Capability Specific Information (SCSI), and its layout depends on the technology named in the ISCD's Switching Capability field.
RFC 7138 introduced a sub-TLV structure for its technology-specific SCSI, which allows more flexibility in structure, ordering and extension. RFC 7688 uses the same approach. RFC 8258 generalizes it for future technologies and Switching Capability types.
The reader is expected to know the GMPLS architecture (RFC 3945) and the OSPF and IS-IS extensions in RFC 4203 and RFC 5307.
Network gear needs to tell its neighbours what it can do. Each kind of gear used to need its own special note format. This makes one note format that all of them can share.
§3The SCSI-TLV Format
The Generalized SCSI is made of zero or more variable-length SCSI-TLV fields. The RFC sets no specific size limits on them, though the routing protocol's ISCD field may impose size and formatting limits. Malformed Link TLVs are treated as described in RFC 3630.
- Type (2 octets): says what kind of information the Value holds and how it is structured.
- Length (2 octets): MUST be the size of the Value in octets. It MUST be zero or divisible by 4, so the Value can be omitted or contain padding.
- Value (variable): formatted according to the Type. It can be omitted for certain types.
Each item is a little labelled package: a label saying what it is, a number saying how big it is, and then the contents. Packages come in sizes that fit neatly in groups of four.
§4Processing Rules
An ISCD can include a Generalized SCSI only for technologies whose Switching Capability definition references this document. It MUST NOT be used for technologies whose definition does not reference it.
A Generalized SCSI MAY contain a sequence of zero or more SCSI-TLVs. The rules are:
- Sub-TLV parsing (format) errors MUST be treated as a malformed ISCD.
- SCSI-TLVs MUST be processed in the order received, and if re-originated, the order MUST be preserved.
- Unknown SCSI-TLVs MUST be ignored and transparently processed, that is, re-originated when appropriate.
- Handling of several SCSI-TLVs of the same type may be refined by the definition of that type.
Read the packages in the order they arrive and pass them along in the same order. If you meet a package you do not understand, do not throw it away. Just hand it on.
§5Security Considerations
The RFC introduces no security issue beyond those in RFC 4203 and RFC 5307. The information in ISCDs is not used for Shortest Path First (SPF) computation or normal routing, so the extensions do not directly affect IP routing.
Tampering with GMPLS Traffic Engineering (TE) Link State Advertisements (LSAs) may still affect the underlying transport network. The RFC suggests protecting the transmission of this information with mechanisms such as those in RFC 2154 and RFC 5304.
These notes do not steer normal traffic, but someone sneaking in fake notes could still confuse the equipment underneath. So it is wise to lock the notes so only trusted senders can write them.
§6The SCSI-TLV Type Registry
IANA has created the Generalized SCSI (Switching Capability Specific Information) TLV Types registry under the GMPLS Signaling Parameters registry. The Type field is a 16-bit identifier.
Value 0 is Reserved and values 1 to 65535 are Unassigned. New allocation requests must say which Switching Type or types the value is to be used with. The registration policy is Specification Required (RFC 8126).
There is a public list of label numbers so two groups never pick the same number for different things. Number 0 is kept back and the rest are free to claim.
§6References
[RFC3945]RFC 3945Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.November 2004[RFC4202]RFC 4202Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.October 2005[RFC4203]RFC 4203Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.October 2005[RFC5307]RFC 5307Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.October 2008[RFC7138]RFC 7138Ceccarelli, D., Ed., et al., "Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks", RFC 7138, March 2014.March 2014[RFC7688]RFC 7688Lee, Y., Ed. and G. Bernstein, Ed., "GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks", RFC 7688, November 2015.November 2015