Movatterモバイル変換


[0]ホーム

URL:


[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

PROPOSED STANDARD
Internet Engineering Task Force (IETF)                       Y. Lee, Ed.Request for Comments: 7688                                        HuaweiCategory: Standards Track                              G. Bernstein, Ed.ISSN: 2070-1721                                        Grotto Networking                                                           November 2015GMPLS OSPF Enhancement for Signal and Network Element Compatibilityfor Wavelength Switched Optical NetworksAbstract   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 inSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc7688.Lee & Bernstein              Standards Track                    [Page 1]

RFC 7688                OSPF Enhancement for WSON          November 2015Copyright Notice   Copyright (c) 2015 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 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 Contents1. Introduction ....................................................31.1. Conventions Used in This Document ..........................32. The Optical Node Property TLV ...................................32.1. Resource Block Information .................................42.2. Resource Accessibility .....................................52.3. Resource Wavelength Constraints ............................52.4. Resource Block Pool State ..................................52.5. Resource Block Shared Access Wavelength Availability .......5   3. Interface Switching Capability Descriptor (ISCD) Format      Extensions ......................................................53.1. Switching Capability Specific Information (SCSI) ...........64. WSON-Specific Scalability and Timeliness ........................75. Security Considerations .........................................86. IANA Considerations .............................................86.1. Optical Node Property TLV ..................................86.1.1. Optical Node Property Sub-TLV .......................86.2. WSON-LSC Switching Type TLV ................................96.2.1. WSON-LSC SCSI Sub-TLVs ..............................97. References .....................................................107.1. Normative References ......................................107.2. Informative References ....................................10   Authors' Addresses ................................................12Lee & Bernstein              Standards Track                    [Page 2]

RFC 7688                OSPF Enhancement for WSON          November 20151.  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 20152.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 20154.  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 Considerations6.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   <http://www.iana.org/assignments/ospf-traffic-eng-tlvs>, and is as   follows:      Value             TLV Type                           Reference      6                 Optical Node PropertyRFC 76886.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   <http://www.iana.org/assignments/ospf-traffic-eng-tlvs>.  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 InformationRFC 7688   2          variable    Resource AccessibilityRFC 7688   3          variable    Resource Wavelength                          ConstraintsRFC 7688   4          variable    Resource Block Pool StateRFC 7688   5          variable    Resource Block Shared                          Access Wavelength AvailabilityRFC 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   <http://www.iana.org/assignments/gmpls-sig-parameters>, as follows:   Value    Description       Reference   151      WSON-LSCRFC 7688   Also, IANA has added the following entry to the   IANAGmplsSwitchingTypeTC MIB:      wsonlsc(151), -- WSON-LSC6.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 LabelsRFC 7688      2             Shared Backup LabelsRFC 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 20157.  References7.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,              <http://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,              <http://www.rfc-editor.org/info/rfc3630>.   [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,              <http://www.rfc-editor.org/info/rfc4203>.   [RFC6205]  Otani, T., Ed., and D. Li, Ed., "Generalized Labels for              Lambda-Switch-Capable (LSC) Label Switching Routers",RFC6205, DOI 10.17487/RFC6205, March 2011,              <http://www.rfc-editor.org/info/rfc6205>.   [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,              <http://www.rfc-editor.org/info/rfc7579>.   [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,              <http://www.rfc-editor.org/info/rfc7580>.   [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",RFC7581, DOI 10.17487/RFC7581, June 2015,              <http://www.rfc-editor.org/info/rfc7581>.7.2. Informative References   [RFC2328]  Moy, J., "OSPF Version 2", STD 54,RFC 2328,              DOI 10.17487/RFC2328, April 1998,              <http://www.rfc-editor.org/info/rfc2328>.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",RFC3471, DOI 10.17487/RFC3471, January 2003,              <http://www.rfc-editor.org/info/rfc3471>.   [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, <http://www.rfc-editor.org/info/rfc4202>.   [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,              <http://www.rfc-editor.org/info/rfc5226>.   [RFC5250]  Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The              OSPF Opaque LSA Option",RFC 5250, DOI 10.17487/RFC5250,              July 2008, <http://www.rfc-editor.org/info/rfc5250>.   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS              Networks",RFC 5920, DOI 10.17487/RFC5920, July 2010,              <http://www.rfc-editor.org/info/rfc5920>.   [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,              <http://www.rfc-editor.org/info/rfc6163>.   [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,              <http://www.rfc-editor.org/info/rfc7446>.Lee & Bernstein              Standards Track                   [Page 11]

RFC 7688                OSPF Enhancement for WSON          November 2015Authors' 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.comLee & Bernstein              Standards Track                   [Page 12]

[8]ページ先頭

©2009-2025 Movatter.jp