From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7688.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc7688.txt (limited to 'doc/rfc/rfc7688.txt') diff --git a/doc/rfc/rfc7688.txt b/doc/rfc/rfc7688.txt new file mode 100644 index 0000000..a56bc35 --- /dev/null +++ b/doc/rfc/rfc7688.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Engineering Task Force (IETF) Y. Lee, Ed. +Request for Comments: 7688 Huawei +Category: Standards Track G. Bernstein, Ed. +ISSN: 2070-1721 Grotto Networking + November 2015 + + + GMPLS OSPF Enhancement for Signal and Network Element Compatibility + for Wavelength Switched Optical Networks + +Abstract + + This document provides Generalized Multiprotocol Label Switching + (GMPLS) Open Shortest Path First (OSPF) routing enhancements to + support signal compatibility constraints associated with Wavelength + Switched Optical Network (WSON) elements. These routing enhancements + are applicable in common optical or hybrid electro-optical networks + where not all the optical signals in the network are compatible with + all network elements participating in the network. + + This compatibility constraint model is applicable to common optical + or hybrid electro-optical systems such as optical-electronic-optical + (OEO) switches, regenerators, and wavelength converters, since such + systems can be limited to processing only certain types of WSON + signals. + +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 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7688. + + + + + + + + + + + + +Lee & Bernstein Standards Track [Page 1] + +RFC 7688 OSPF Enhancement for WSON November 2015 + + +Copyright Notice + + Copyright (c) 2015 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. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Conventions Used in This Document ..........................3 + 2. The Optical Node Property TLV ...................................3 + 2.1. Resource Block Information .................................4 + 2.2. Resource Accessibility .....................................5 + 2.3. Resource Wavelength Constraints ............................5 + 2.4. Resource Block Pool State ..................................5 + 2.5. Resource Block Shared Access Wavelength Availability .......5 + 3. Interface Switching Capability Descriptor (ISCD) Format + Extensions ......................................................5 + 3.1. Switching Capability Specific Information (SCSI) ...........6 + 4. WSON-Specific Scalability and Timeliness ........................7 + 5. Security Considerations .........................................8 + 6. IANA Considerations .............................................8 + 6.1. Optical Node Property TLV ..................................8 + 6.1.1. Optical Node Property Sub-TLV .......................8 + 6.2. WSON-LSC Switching Type TLV ................................9 + 6.2.1. WSON-LSC SCSI Sub-TLVs ..............................9 + 7. References .....................................................10 + 7.1. Normative References ......................................10 + 7.2. Informative References ....................................10 + Authors' Addresses ................................................12 + + + + + + + + + + + + +Lee & Bernstein Standards Track [Page 2] + +RFC 7688 OSPF Enhancement for WSON November 2015 + + +1. Introduction + + The documents [RFC6163], [RFC7446], and [RFC7581] explain how to + extend the Wavelength Switched Optical Network (WSON) control plane + to support both multiple WSON signal types and common hybrid electro- + optical systems as well hybrid systems containing optical switching + and electro-optical resources. In WSON, not all the optical signals + in the network are compatible with all network elements participating + in the network. Therefore, signal compatibility is an important + constraint in path computation in a WSON. + + This document provides GMPLS OSPF routing enhancements to support + signal compatibility constraints associated with general WSON network + elements. These routing enhancements are applicable in common + optical or hybrid electro-optical networks where not all optical + signals in the network are compatible with all network elements + participating in the network. + + This compatibility constraint model is applicable to common optical + or hybrid electro-optical systems such as OEO switches, regenerators, + and wavelength converters, since such systems can be limited to + processing only certain types of WSON signals. + + Related to this document is [RFC7580], which provides GMPLS OSPF + routing enhancements to support the generic routing and label + assignment process that can be applicable to a wider range of + technologies beyond WSON. + +1.1. 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 [RFC2119]. + +2. The Optical Node Property TLV + + [RFC3630] defines OSPF Traffic Engineering (TE) Link State + Advertisement (LSA) using an opaque LSA. This document adds a new + top-level TLV for use in the OSPF TE LSA: the Optical Node Property + TLV. The Optical Node Property TLV describes a single node. It is + comprised of a set of optional sub-TLVs. There are no ordering + requirements for the sub-TLVs. + + When using the extensions defined in this document, at least one + Optical Node Property TLV MUST be advertised in each LSA. To allow + for fine-grained changes in topology, more than one Optical Node + Property TLV MAY be advertised in a single LSA. Implementations MUST + support receiving multiple Optical Node Property TLVs in an LSA. + + + +Lee & Bernstein Standards Track [Page 3] + +RFC 7688 OSPF Enhancement for WSON November 2015 + + + The Optical Node Property TLV contains all WSON-specific node + properties and signal compatibility constraints. The detailed + encodings of these properties are defined in [RFC7581]. + + The following sub-TLVs of the Optical Node Property TLV are defined: + + Value Length Sub-TLV Type + + 1 variable Resource Block Information + 2 variable Resource Accessibility + 3 variable Resource Wavelength Constraints + 4 variable Resource Block Pool State + 5 variable Resource Block Shared Access Wavelength + Availability + + The detailed encodings of these sub-TLVs are found in [RFC7581] as + indicated in the table below. + + Sub-TLV Type Section from [RFC7581] + + Resource Block Information 4 + Resource Accessibility 3.1 + Resource Wavelength Constraints 3.2 + Resource Block Pool State 3.3 + Resource Block Shared Access Wavelength Availability 3.4 + + All sub-TLVs defined here may occur at most once in any given Optical + Node TLV under one TE LSA. If more than one copy of the sub-TLV is + received in the same LSA, the redundant sub-TLV SHOULD be ignored. + If the same sub-TLV is advertised in a different TE LSA (which would + only occur if there was a packaging error), then the sub-TLV with the + largest LSA ID (Section 2.2 of RFC 3630) SHOULD be picked. These + restrictions need not apply to future sub-TLVs. Unrecognized sub- + TLVs are ignored. + + Among the sub-TLVs defined above, the Resource Block Pool State sub- + TLV and Resource Block Shared Access Wavelength Availability are + dynamic in nature, while the rest are static. As such, they can be + separated out from the rest and be advertised with multiple TE LSAs + per OSPF router, as described in [RFC3630] and [RFC5250]. + +2.1. Resource Block Information + + As defined in [RFC7446], this sub-TLV is used to represent resource + signal constraints and processing capabilities of a node. + + + + + + +Lee & Bernstein Standards Track [Page 4] + +RFC 7688 OSPF Enhancement for WSON November 2015 + + +2.2. Resource Accessibility + + This sub-TLV describes the structure of the resource pool in relation + to the switching device. In particular, it indicates the ability of + an ingress port to reach a resource block and of a resource block to + reach a particular egress port. + +2.3. Resource Wavelength Constraints + + Resources, such as wavelength converters, etc., may have limited + input or output wavelength ranges. Additionally, due to the + structure of the optical system, not all wavelengths can necessarily + reach or leave all the resources. The Resource Wavelength + Constraints sub-TLV describes these properties. + +2.4. Resource Block Pool State + + This sub-TLV describes the usage state of a resource that can be + encoded as either a list of integer values or a bitmap indicating + whether a single resource is available or in use. This information + can be relatively dynamic, i.e., can change when a connection is + established or torn down. + +2.5. Resource Block Shared Access Wavelength Availability + + Resource blocks may be accessed via a shared fiber. If this is the + case, then wavelength availability on these shared fibers is needed + to understand resource availability. + +3. Interface Switching Capability Descriptor (ISCD) Format Extensions + + The ISCD describes the switching capability of an interface + [RFC4202]. This document defines a new Switching Capability value + for WSON as follows: + + Value Type + ----- ---- + 151 WSON-LSC + + Switching Capability and Encoding values MUST be used as follows: + + Switching Capability = WSON-LSC + + Encoding Type = Lambda (as defined in [RFC3471]) + + + + + + + +Lee & Bernstein Standards Track [Page 5] + +RFC 7688 OSPF Enhancement for WSON November 2015 + + + When Switching Capability and Encoding fields are set to values as + stated above, the Interface Switching Capability Descriptor MUST be + interpreted as in [RFC4203] with the optional inclusion of one or + more Switching Capability Specific Information sub-TLVs. + +3.1. Switching Capability Specific Information (SCSI) + + The technology-specific part of the WSON ISCD may include a variable + number of sub-TLVs called Bandwidth sub-TLVs. Two types of Bandwidth + sub-TLV are defined: + + - Type 1: Available Labels + + - Type 2: Shared Backup Labels + + A SCSI may contain multiple Available Label sub-TLVs and multiple + Shared Backup Label sub-TLVs. The following figure shows the format + for a SCSI that contains these sub-TLVs, where the Available Label + Sub-TLV and Shared Backup Label sub-TLV are as defined in [RFC7579]. + The order of the sub-TLVs in the SCSI is arbitrary. + + 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 = 1 (Available) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Available Label Sub-TLV | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ ... ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type = 2 (Shared backup) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Shared Backup Label Sub-TLV | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: SCSI Format + + If duplicated sub-TLVs are advertised, the router/node will ignore + the duplicated labels that are identified by the Label format defined + in [RFC6205]. + + The label format defined in [RFC6205] MUST be used when advertising + interfaces with a WSON-LSC type Switching Capability. + + + + +Lee & Bernstein Standards Track [Page 6] + +RFC 7688 OSPF Enhancement for WSON November 2015 + + +4. WSON-Specific Scalability and Timeliness + + This document has defined five sub-TLVs specific to WSON. The + examples given in [RFC7581] show that very large systems, in terms of + channel count, ports, or resources, can be very efficiently encoded. + + There has been concern expressed that some possible systems may + produce LSAs that exceed the IP Maximum Transmission Unit (MTU). In + a typical node configuration, the Optical Node Property TLV will not + exceed the IP MTU. A typical node configuration refers to a system + with several hundreds of channels with an OEO element in the node. + This would give the Optical Node Property TLV less than 350 bytes. + In addition, [RFC7581] provides mechanisms to compactly encode + required information elements. In a rare case where the TLV exceeds + the IP MTU, IP fragmentation/reassembly can be used, which is an + acceptable method. For IPv6, a node may use the IPv6 Fragment header + to fragment the packet at the source and have it reassembled at the + destination(s). + + If the size of this LSA is greater than the MTU, then these sub-TLVs + can be packed into separate LSAs. From the point of view of path + computation, the presence of the Resource Block Information sub-TLV + indicates that resources exist in the system and may have signal + compatibility or other constraints. The other four sub-TLVs indicate + constraints on access to and availability of those resources. + + Hence, the "synchronization" procedure is quite simple from the point + of view of path computation. Until a Resource Block Information sub- + TLV is received for a system, path computation cannot make use of the + other four sub-TLVs since it does not know the nature of the + resources, e.g., whether the resources are wavelength converters, + regenerators, or something else. Once this sub-TLV is received, path + computation can proceed with whatever sub-TLVs it may have received + (their use is dependent upon the system type). + + If path computation proceeds with out-of-date or missing information + from these sub-TLVs, then there is the possibility of either (a) path + computation yielding a path that does not exist in the network, (b) + path computation failing to find a path through the network that + actually exists. Both situations are currently encountered with + GMPLS, i.e., out-of-date information on constraints or resource + availability. + + If the new sub-TLVs or their attendant encodings are malformed, a + proper implementation SHOULD log the problem and MUST stop sending + the LSA that contains malformed TLVs or sub-TLVs. + + + + + +Lee & Bernstein Standards Track [Page 7] + +RFC 7688 OSPF Enhancement for WSON November 2015 + + + Errors of this nature SHOULD be logged for the local operator. + Implementations MUST provide a rate limit on such logs, and that rate + limit SHOULD be configurable. + + Note that the connection establishment mechanism (signaling or + management) is ultimately responsible for the establishment of the + connection, and this implies that such mechanisms must ensure signal + compatibility. + +5. Security Considerations + + This document does not introduce security issues other than those + discussed in [RFC3630] and [RFC4203]. + + As with [RFC4203], it specifies the contents of Opaque LSAs in + OSPFv2. As Opaque LSAs are not used for Shortest Path First (SPF) + computation or normal routing, the extensions specified here have no + direct effect on IP routing. Tampering with GMPLS TE LSAs may have + an effect on the underlying transport. [RFC3630] notes that the + security mechanisms described in [RFC2328] apply to Opaque LSAs + carried in OSPFv2. + + For general security aspects relevant to GMPLS-controlled networks, + please refer to [RFC5920]. + +6. IANA Considerations + +6.1. Optical Node Property TLV + + This document introduces a new Top-Level Node TLV (Optical Node + Property TLV) under the OSPF TE LSA defined in [RFC3630]. IANA has + registered a new TLV for "Optical Node Property". The new TLV is in + the "Top Level Types in TE LSAs" registry in "Open Shortest Path + First (OSPF) Traffic Engineering TLVs" located at + , and is as + follows: + + Value TLV Type Reference + + 6 Optical Node Property RFC 7688 + +6.1.1. Optical Node Property Sub-TLV + + Additionally, a new IANA registry has been created named "Types for + sub-TLVs of Optical Node Property (Value 6)" in the "Open Shortest + Path First (OSPF) Traffic Engineering TLVs" registry located at + . New sub- + TLVs and their values have been assigned as follows: + + + +Lee & Bernstein Standards Track [Page 8] + +RFC 7688 OSPF Enhancement for WSON November 2015 + + + Value Length Sub-TLV Reference + + 0 Reserved + 1 variable Resource Block Information RFC 7688 + 2 variable Resource Accessibility RFC 7688 + 3 variable Resource Wavelength + Constraints RFC 7688 + 4 variable Resource Block Pool State RFC 7688 + 5 variable Resource Block Shared + Access Wavelength Availability RFC 7688 + 6-65535 Unassigned + + The registration procedure for this registry is Standards Action as + defined in [RFC5226]. + +6.2. WSON-LSC Switching Type TLV + + IANA has registered a new switching type in the "Switching Types" + registry in "GMPLS Signaling Parameters", located at + , as follows: + + Value Description Reference + + 151 WSON-LSC RFC 7688 + + Also, IANA has added the following entry to the + IANAGmplsSwitchingTypeTC MIB: + + wsonlsc(151), -- WSON-LSC + +6.2.1. WSON-LSC SCSI Sub-TLVs + + Additionally, a new IANA registry has been created for sub-TLVs of + the WSON-LSC SCSI sub-TLV. It is named "Types for sub-TLVs of + WSON-LSC SCSI (Switching Capability Specific Information)" and is in + the "Open Shortest Path First (OSPF) Traffic Engineering TLVs" + registry. It contains the following sub-TLVs: + + Value Sub-TLV Reference + + 0 Reserved + 1 Available Labels RFC 7688 + 2 Shared Backup Labels RFC 7688 + 3-65535 Unassigned + + The registration procedure for this registry is Standards Action as + defined in [RFC5226]. + + + + +Lee & Bernstein Standards Track [Page 9] + +RFC 7688 OSPF Enhancement for WSON November 2015 + + +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, + . + + [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering + (TE) Extensions to OSPF Version 2", RFC 3630, + DOI 10.17487/RFC3630, September 2003, + . + + [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, + . + + [RFC6205] Otani, T., Ed., and D. Li, Ed., "Generalized Labels for + Lambda-Switch-Capable (LSC) Label Switching Routers", RFC + 6205, DOI 10.17487/RFC6205, March 2011, + . + + [RFC7579] Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and + J. Han, "General Network Element Constraint Encoding for + GMPLS-Controlled Networks", RFC 7579, + DOI 10.17487/RFC7579, June 2015, + . + + [RFC7580] Zhang, F., Lee, Y., Han, J., Bernstein, G., and Y. Xu, + "OSPF-TE Extensions for General Network Element + Constraints", RFC 7580, DOI 10.17487/RFC7580, June 2015, + . + + [RFC7581] Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and + J. Han, "Routing and Wavelength Assignment Information + Encoding for Wavelength Switched Optical Networks", RFC + 7581, DOI 10.17487/RFC7581, June 2015, + . + +7.2. Informative References + + [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, + DOI 10.17487/RFC2328, April 1998, + . + + + + + +Lee & Bernstein Standards Track [Page 10] + +RFC 7688 OSPF Enhancement for WSON November 2015 + + + [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Functional Description", RFC + 3471, DOI 10.17487/RFC3471, January 2003, + . + + [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, . + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + . + + [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The + OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, + July 2008, . + + [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS + Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, + . + + [RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, + "Framework for GMPLS and Path Computation Element (PCE) + Control of Wavelength Switched Optical Networks (WSONs)", + RFC 6163, DOI 10.17487/RFC6163, April 2011, + . + + [RFC7446] Lee, Y., Ed., Bernstein, G., Ed., Li, D., and W. Imajuku, + "Routing and Wavelength Assignment Information Model for + Wavelength Switched Optical Networks", RFC 7446, + DOI 10.17487/RFC7446, February 2015, + . + + + + + + + + + + + + + + + + + +Lee & Bernstein Standards Track [Page 11] + +RFC 7688 OSPF Enhancement for WSON November 2015 + + +Authors' Addresses + + Young Lee (editor) + Huawei Technologies + 5340 Legacy Drive, Building 3 + Plano, TX 75024 + United States + + Phone: (469) 277-5838 + Email: leeyoung@huawei.com + + + Greg M. Bernstein (editor) + Grotto Networking + Fremont, CA + United States + + Phone: (510) 573-2237 + Email: gregb@grotto-networking.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lee & Bernstein Standards Track [Page 12] + -- cgit v1.2.3