doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc7689.txt b/doc/rfc/rfc7689.txt
new file mode 100644
index 0000000..09f9879
--- /dev/null
+++ b/doc/rfc/rfc7689.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                 G. Bernstein, Ed.
+Request for Comments: 7689                             Grotto Networking
+Category: Standards Track                                          S. Xu
+ISSN: 2070-1721                                                     NICT
+                                                             Y. Lee, Ed.
+                                                                  Huawei
+                                                           G. Martinelli
+                                                                   Cisco
+                                                                H. Harai
+                                                                    NICT
+                                                           November 2015
+
+
+     Signaling Extensions for Wavelength Switched Optical Networks
+
+Abstract
+
+   This document provides extensions to Generalized Multiprotocol Label
+   Switching (GMPLS) signaling for control of Wavelength Switched
+   Optical Networks (WSONs).  Such extensions are applicable in WSONs
+   under a number of conditions including: (a) when optional processing,
+   such as regeneration, must be configured to occur at specific nodes
+   along a path, (b) where equipment must be configured to accept an
+   optical signal with specific attributes, or (c) where equipment must
+   be configured to output an optical signal with specific attributes.
+   This document provides mechanisms to support distributed wavelength
+   assignment with a choice of distributed wavelength assignment
+   algorithms.
+
+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/rfc7689.
+
+
+
+
+
+
+
+
+
+Bernstein, et al.            Standards Track                    [Page 1]
+
+RFC 7689                WSON Signaling Extensions          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
+   2. Terminology .....................................................3
+      2.1. Conventions Used in This Document ..........................4
+   3. Requirements for WSON Signaling .................................4
+      3.1. WSON Signal Characterization ...............................4
+      3.2. Per-Node Processing Configuration ..........................5
+      3.3. Bidirectional WSON LSPs ....................................5
+      3.4. Distributed Wavelength Assignment Selection Method .........6
+      3.5. Optical Impairments ........................................6
+   4. WSON Signal Traffic Parameters, Attributes, and Processing ......6
+      4.1. Traffic Parameters for Optical Tributary Signals ...........7
+      4.2. WSON Processing Hop Attribute TLV ..........................7
+           4.2.1. ResourceBlockInfo Sub-TLV ...........................8
+           4.2.2. WavelengthSelection Sub-TLV .........................9
+   5. Security Considerations ........................................11
+   6. IANA Considerations ............................................11
+   7. References .....................................................13
+      7.1. Normative References ......................................13
+      7.2. Informative References ....................................14
+   Acknowledgments ...................................................15
+   Contributors ......................................................15
+   Author's Addresses ................................................16
+
+
+
+
+
+
+
+
+
+
+
+
+Bernstein, et al.            Standards Track                    [Page 2]
+
+RFC 7689                WSON Signaling Extensions          November 2015
+
+
+1.  Introduction
+
+   This document provides extensions to Generalized Multiprotocol Label
+   Switching (GMPLS) signaling for control of Wavelength Switched
+   Optical Networks (WSONs).  Fundamental extensions are given to permit
+   simultaneous bidirectional wavelength assignment, while more advanced
+   extensions are given to support the networks described in [RFC6163],
+   which feature connections requiring configuration of input, output,
+   and general signal processing capabilities at a node along a Label
+   Switched Path (LSP).
+
+   These extensions build on previous work for the control of lambda and
+   G.709-based networks.
+
+   Related documents are [RFC7446] that provides a high-level
+   information model and [RFC7581] that provides common encodings that
+   can be applicable to other protocol extensions such as routing.
+
+2.  Terminology
+
+   CWDM: Coarse Wavelength Division Multiplexing.
+
+   DWDM: Dense Wavelength Division Multiplexing.
+
+   ROADM: Reconfigurable Optical Add/Drop Multiplexer.  A reduced port
+      count wavelength selective switching element featuring ingress and
+      egress line side ports as well as add/drop side ports.
+
+   RWA: Routing and Wavelength Assignment.
+
+   Wavelength Conversion/Converters: The process of converting
+      information bearing optical signal centered at a given frequency
+      (wavelength) to one with "equivalent" content centered at a
+      different wavelength.  Wavelength conversion can be implemented
+      via an optical-electronic-optical (OEO) process or via a strictly
+      optical process.
+
+   WDM: Wavelength Division Multiplexing.
+
+   Wavelength Switched Optical Networks (WSONs): WDM-based optical
+      networks in which switching is performed selectively based on the
+      frequency of an optical signal.
+
+   AWG: Arrayed Waveguide Grating.
+
+   OXC: Optical Cross-Connect.
+
+
+
+
+
+Bernstein, et al.            Standards Track                    [Page 3]
+
+RFC 7689                WSON Signaling Extensions          November 2015
+
+
+   Optical Transmitter: A device that has both a laser, tuned on a
+      certain wavelength, and electronic components that convert
+      electronic signals into optical signals.
+
+   Optical Receiver: A device that has both optical and electronic
+      components.  It detects optical signals and converts optical
+      signals into electronic signals.
+
+   Optical Transponder: A device that has both an optical transmitter
+      and an optical receiver.
+
+   Optical End Node: The end of a wavelength (optical lambdas) lightpath
+      in the data plane.  It may be equipped with some
+      optical/electronic devices such as wavelength
+      multiplexers/demultiplexer (e.g., AWG), optical transponder, etc.,
+      which are employed to transmit/terminate the optical signals for
+      data transmission.
+
+   FEC: Forward Error Correction.  FEC is a digital signal processing
+      technique used to enhance data reliability.  It does this by
+      introducing redundant data, called error correcting code, prior to
+      data transmission or storage.  FEC provides the receiver with the
+      ability to correct errors without a reverse channel to request the
+      retransmission of data.
+
+   3R Regeneration: The process of amplifying (correcting loss),
+      reshaping (correcting noise and dispersion), retiming
+      (synchronizing with the network clock), and retransmitting an
+      optical signal.
+
+2.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].
+
+3.  Requirements for WSON Signaling
+
+   The following requirements for GMPLS-based WSON signaling are in
+   addition to the functionality already provided by existing GMPLS
+   signaling mechanisms.
+
+3.1.  WSON Signal Characterization
+
+   WSON signaling needs to convey sufficient information characterizing
+   the signal to allow systems along the path to determine compatibility
+   and perform any required local configuration.  Examples of such
+   systems include intermediate nodes (ROADMs, OXCs, wavelength
+
+
+
+Bernstein, et al.            Standards Track                    [Page 4]
+
+RFC 7689                WSON Signaling Extensions          November 2015
+
+
+   converters, regenerators, OEO switches, etc.), links (WDM systems),
+   and end systems (detectors, demodulators, etc.).  The details of any
+   local configuration processes are outside the scope of this document.
+
+   From [RFC6163], we have the following list of WSON signal
+   characteristics:
+
+   1.  Optical tributary signal class (modulation format).
+   2.  FEC: whether forward error correction is used in the digital
+      stream and what type of error correcting code is used
+   3.  Center frequency (wavelength)
+   4.  Bit rate
+   5.  G-PID: General Protocol Identifier for the information format
+
+   The first three items on this list can change as a WSON signal
+   traverses a network with regenerators, OEO switches, or wavelength
+   converters.  These parameters are summarized in the Optical Interface
+   Class as defined in [RFC7446], and the assumption is that a class
+   always includes signal compatibility information.  An ability to
+   control wavelength conversion already exists in GMPLS signaling along
+   with the ability to share client signal type information (G-PID).  In
+   addition, bit rate is a standard GMPLS signaling traffic parameter.
+   It is referred to as bandwidth encoding in [RFC3471].
+
+3.2.  Per-Node Processing Configuration
+
+   In addition to configuring a node along an LSP to input or output a
+   signal with specific attributes, we may need to signal the node to
+   perform specific processing, such as 3R regeneration, on the signal
+   at a particular node.  [RFC6163] discussed three types of processing:
+
+      (A) Regeneration (possibly different types)
+
+      (B) Fault and Performance Monitoring
+
+      (C) Attribute Conversion
+
+   The extensions here provide for the configuration of these types of
+   processing at nodes along an LSP.
+
+3.3.  Bidirectional WSON LSPs
+
+   WSON signaling can support LSP setup consistent with the wavelength
+   continuity constraint for bidirectional connections.  The following
+   cases need to be supported separately:
+
+   (a)  Where the same wavelength is used for both upstream and
+        downstream directions
+
+
+
+Bernstein, et al.            Standards Track                    [Page 5]
+
+RFC 7689                WSON Signaling Extensions          November 2015
+
+
+   (b)  Where different wavelengths are used for both upstream and
+        downstream directions.
+
+   This document will review existing GMPLS bidirectional solutions
+   according to WSON case.
+
+3.4.  Distributed Wavelength Assignment Selection Method
+
+   WSON signaling can support the selection of a specific distributed
+   wavelength assignment method.
+
+   This method is beneficial in cases of equipment failure, etc., where
+   fast provisioning used in quick recovery is critical to protect
+   carriers/users against system loss.  This requires efficient
+   signaling that supports distributed wavelength assignment, in
+   particular, when the wavelength assignment capability is not
+   available.
+
+   As discussed in [RFC6163], different computational approaches for
+   wavelength assignment are available.  One method is the use of
+   distributed wavelength assignment.  This feature would allow the
+   specification of a particular approach when more than one is
+   implemented in the systems along the path.
+
+3.5.  Optical Impairments
+
+   This document does not address signaling information related to
+   optical impairments.
+
+4.  WSON Signal Traffic Parameters, Attributes, and Processing
+
+   As discussed in [RFC6163], single-channel optical signals used in
+   WSONs are called "optical tributary signals" and come in a number of
+   classes characterized by modulation format and bit rate.  Although
+   WSONs are fairly transparent to the signals they carry, to ensure
+   compatibility amongst various networks devices and end systems, it
+   can be important to include key lightpath characteristics as traffic
+   parameters in signaling [RFC6163].
+
+   LSPs signaled through extensions provided in this document MUST apply
+   the following signaling parameters:
+
+      o  Switching Capability = WSON-LSC [RFC7688]
+      o  Encoding Type = Lambda [RFC3471]
+      o  Label Format = as defined in [RFC6205]
+
+   [RFC6205] defines the label format as applicable to LSC capable
+   devices.
+
+
+
+Bernstein, et al.            Standards Track                    [Page 6]
+
+RFC 7689                WSON Signaling Extensions          November 2015
+
+
+4.1.  Traffic Parameters for Optical Tributary Signals
+
+   In [RFC3471] we see that the G-PID (client signal type) and bit rate
+   (byte rate) of the signals are defined as parameters, and in
+   [RFC3473] they are conveyed in the Generalized Label Request object
+   and the RSVP SENDER_TSPEC/FLOWSPEC objects, respectively.
+
+4.2.  WSON Processing Hop Attribute TLV
+
+   Section 3.1 provides requirements to signal to a node along an LSP
+   what type of processing to perform on an optical signal and how to
+   configure itself to accept or transmit an optical signal with
+   particular attributes.
+
+   To target a specific node, this section defines a WSON Processing Hop
+   Attribute TLV.  This TLV is encoded as an attributes TLV; see
+   [RFC5420].  The TLV is carried in the ERO and RRO Hop Attributes
+   subobjects and processed according to the procedures defined in
+   [RFC7570].  The type value of the WSON Processing Hop Attribute TLV
+   is 4 as assigned by IANA.
+
+   The WSON Processing Hop Attribute TLV carries one or more sub-TLVs
+   with the following format:
+
+    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                            //
+   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           ...                 |        Padding                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      The identifier of the sub-TLV.
+
+   Length
+
+      Indicates the total length of the sub-TLV in octets.  That is, the
+      combined length of the Type, Length, and Value fields, i.e., two
+      plus the length of the Value field in octets.
+
+   Value
+
+      Zero or more octets of data carried in the sub-TLV.
+
+
+
+
+Bernstein, et al.            Standards Track                    [Page 7]
+
+RFC 7689                WSON Signaling Extensions          November 2015
+
+
+   Padding
+
+      Variable
+
+   The entire sub-TLV MUST be padded with zeros to ensure four-octet
+   alignment of the sub-TLV.
+
+   Sub-TLV ordering is significant and MUST be preserved.  Error
+   processing follows [RFC7570].
+
+   The following sub-TLV types are defined in this document:
+
+   Sub-TLV Name        Type    Length
+   --------------------------------------------------------------
+   ResourceBlockInfo    1      variable
+   WavelengthSelection  2      8 octets (2-octet padding)
+
+   The TLV can be represented in Reduced Backus-Naur Form (RBNF)
+   [RFC5511] syntax as:
+
+   <WSON Processing Hop Attribute> ::= <ResourceBlockInfo>
+   [<ResourceBlockInfo>] [<WavelengthSelection>]
+
+4.2.1.  ResourceBlockInfo Sub-TLV
+
+   The format of the ResourceBlockInfo sub-TLV value field is defined in
+   Section 4 of [RFC7581].  It is a list of available Optical Interface
+   Classes and processing capabilities.
+
+   At least one ResourceBlockInfo sub-TLV MUST be present in the WSON
+   Processing Hop Attribute TLV.  No more than two ResourceBlockInfo
+   sub-TLVs SHOULD be present.  Any present ResourceBlockInfo sub-TLVs
+   MUST be processed in the order received, and extra (unprocessed) sub-
+   TLVs SHOULD be ignored.
+
+   The ResourceBlockInfo field contains several information elements as
+   defined by [RFC7581].  The following rules apply to the sub-TLV:
+
+   o  RB Set field can carry one or more RB Identifier.  Only the first
+      RB Identifier listed in the RB Set field SHALL be processed; any
+      others SHOULD be ignored.
+
+   o  In the case of unidirectional LSPs, only one ResourceBlockInfo
+      sub-TLV SHALL be processed, and the I and O bits can be safely
+      ignored.
+
+
+
+
+
+
+Bernstein, et al.            Standards Track                    [Page 8]
+
+RFC 7689                WSON Signaling Extensions          November 2015
+
+
+   o  In the case of a bidirectional LSP, there MUST be either:
+
+      (a) only one ResourceBlockInfo sub-TLV present in a WSON
+          Processing Hop Attribute TLV, and the bits I and O both set to
+          1, or
+
+      (b) two ResourceBlockInfo sub-TLVs present, one with only the I
+          bit set and the other with only the O bit set.
+
+   o  The rest of the information carried within the ResourceBlockInfo
+      sub-TLV includes the Optical Interface Class List, Input Bit Rate
+      List, and Processing Capability List.  These lists MAY contain one
+      or more elements.  These elements apply equally to both
+      bidirectional and unidirectional LSPs.
+
+   Any violation of these rules detected by a transit or egress node
+   SHALL be treated as an error and be processed per [RFC7570].
+
+   A ResourceBlockInfo sub-TLV can be constructed by a node and added to
+   an ERO Hop Attributes subobject in order to be processed by
+   downstream nodes (transit and egress).  As defined in [RFC7570], the
+   R bit reflects the LSP_REQUIRED_ATTRIBUTE and LSP_ATTRIBUTE semantic
+   defined in [RFC5420], and it SHOULD be set accordingly.
+
+   Once a node properly parses a ResourceBlockInfo sub-TLV received in
+   an ERO Hop Attributes subobject (according to the rules stated above
+   and in [RFC7570]), the node allocates the indicated resources, e.g.,
+   the selected regeneration pool, for the LSP.  In addition, the node
+   SHOULD report compliance by adding an RRO Hop Attributes subobject
+   with the WSON Processing Hop Attribute TLV (and its sub-TLVs)
+   indicating the utilized resources.  ResourceBlockInfo sub-TLVs
+   carried in an RRO Hop Attributes subobject are subject to [RFC7570]
+   and standard RRO processing; see [RFC3209].
+
+4.2.2.  WavelengthSelection Sub-TLV
+
+   Routing + Distributed Wavelength Assignment (R+DWA) is one of the
+   options defined by [RFC6163].  The output from the routing function
+   will be a path, but the wavelength will be selected on a hop-by-hop
+   basis.
+
+   As discussed in [RFC6163], the wavelength assignment can be either
+   for a unidirectional lightpath or for a bidirectional lightpath
+   constrained to use the same lambda in both directions.
+
+   In order to indicate wavelength assignment directionality and
+   wavelength assignment method, the WavelengthSelection sub-TLV is
+   carried in the WSON Processing Hop Attribute TLV defined above.
+
+
+
+Bernstein, et al.            Standards Track                    [Page 9]
+
+RFC 7689                WSON Signaling Extensions          November 2015
+
+
+   The WavelengthSelection sub-TLV value field is defined as:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |W|  WA Method  |                    Reserved                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Where:
+
+   W (1 bit): 0 denotes requiring the same wavelength in both
+      directions; 1 denotes that different wavelengths on both
+      directions are allowed.
+
+      Wavelength Assignment (WA) Method (7 bits):
+
+      0: unspecified (any); This does not constrain the WA method used
+          by a specific node.  This value is implied when the
+          WavelengthSelection sub-TLV is absent.
+
+      1: First-Fit.  All the wavelengths are numbered, and this WA
+          method chooses the available wavelength with the lowest index.
+
+      2: Random.  This WA method chooses an available wavelength
+          randomly.
+
+      3: Least-Loaded (multi-fiber).  This WA method selects the
+          wavelength that has the largest residual capacity on the most
+          loaded link along the route.  This method is used in multi-
+          fiber networks.  If used in single-fiber networks, it is
+          equivalent to the First-Fit WA method.
+
+      4-127: Unassigned.
+
+   The processing rules for this TLV are as follows:
+
+   If a receiving node does not support the attribute(s), its behaviors
+   are specified below:
+
+   -  W bit not supported: a PathErr MUST be generated with the Error
+      Code "Routing Problem" (24) with error sub-code "Unsupported
+      WavelengthSelection Symmetry value" (107).
+
+   -  WA method not supported: a PathErr MUST be generated with the
+      Error Code "Routing Problem" (24) with error sub-code "Unsupported
+      Wavelength Assignment value" (108).
+
+
+
+
+
+Bernstein, et al.            Standards Track                   [Page 10]
+
+RFC 7689                WSON Signaling Extensions          November 2015
+
+
+   A WavelengthSelection sub-TLV can be constructed by a node and added
+   to an ERO Hop Attributes subobject in order to be processed by
+   downstream nodes (transit and egress).  As defined in [RFC7570], the
+   R bit reflects the LSP_REQUIRED_ATTRIBUTE and LSP_ATTRIBUTE semantic
+   defined in [RFC5420], and it SHOULD be set accordingly.
+
+   Once a node properly parses the WavelengthSelection sub-TLV received
+   in an ERO Hop Attributes subobject, the node use the indicated
+   wavelength assignment method (at that hop) for the LSP.  In addition,
+   the node SHOULD report compliance by adding an RRO Hop Attributes
+   subobject with the WSON Processing Hop Attribute TLV (and its sub-
+   TLVs) that indicate the utilized method.  WavelengthSelection sub-
+   TLVs carried in an RRO Hop Attributes subobject are subject to
+   [RFC7570] and standard RRO processing; see [RFC3209].
+
+5.  Security Considerations
+
+   This document is built on the mechanisms defined in [RFC3473], and
+   only differs in the specific information communicated.  The specific
+   additional information (optical resource and wavelength selection
+   properties) is not viewed as substantively changing or adding to the
+   security considerations of the existing GMPLS signaling protocol
+   mechanisms.  See [RFC3473] for details of the supported security
+   measures.  Additionally, [RFC5920] provides an overview of security
+   vulnerabilities and protection mechanisms for the GMPLS control
+   plane.
+
+6.  IANA Considerations
+
+   IANA has assigned a new value in the existing "Attributes TLV Space"
+   registry located at
+   <http://www.iana.org/assignments/rsvp-te-parameters>, as updated by
+   [RFC7570]:
+
+   Type  Name        Allowed on  Allowed on   Allowed on   Reference
+                     LSP         LSP REQUIRED RO LSP
+                     ATTRIBUTES  ATTRIBUTES   Attribute
+                                              Subobject
+
+   4     WSON        No          No           Yes          RFC 7689
+         Processing
+         Hop
+         Attribute
+         TLV
+
+
+
+
+
+
+
+Bernstein, et al.            Standards Track                   [Page 11]
+
+RFC 7689                WSON Signaling Extensions          November 2015
+
+
+   IANA has created a new registry named "Sub-TLV Types for WSON
+   Processing Hop Attribute TLV" located at
+   <http://www.iana.org/assignments/rsvp-te-parameters>.
+
+   The following entries have been added:
+
+   Value            Sub-TLV Type            Reference
+
+   0                Reserved                RFC 7689
+
+   1                ResourceBlockInfo       RFC 7689
+
+   2                WavelengthSelection     RFC 7689
+
+   All assignments are to be performed via Standards Action or
+   Specification Required policies as defined in [RFC5226].
+
+   IANA has created a new registry named "Values for Wavelength
+   Assignment Method field in WavelengthSelection Sub-TLV" located at
+   <http://www.iana.org/assignments/rsvp-te-parameters>.
+
+   The following entries have been added:
+
+   Value          Meaning                    Reference
+
+
+   0             unspecified                RFC 7689
+
+   1             First-Fit                  RFC 7689
+
+   2             Random                     RFC 7689
+
+   3             Least-Loaded (multi-fiber) RFC 7689
+
+   4-127         Unassigned
+
+   All assignments are to be performed via Standards Action or
+   Specification Required policies as defined in [RFC5226].  The
+   assignment policy chosen for any specific code point must be clearly
+   stated in the document that describes the code point so that IANA can
+   apply the correct policy.
+
+
+
+
+
+
+
+
+
+
+Bernstein, et al.            Standards Track                   [Page 12]
+
+RFC 7689                WSON Signaling Extensions          November 2015
+
+
+   IANA has assigned new values in the existing "Sub-Codes - 24 Routing
+   Problem" registry located at
+   <http://www.iana.org/assignments/rsvp-parameters>:
+
+   Value              Description                          Reference
+
+   107                Unsupported WavelengthSelection
+                      symmetry value                       RFC 7689
+
+   108                Unsupported Wavelength Assignment
+                      value                                RFC 7689
+
+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,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
+              <http://www.rfc-editor.org/info/rfc3209>.
+
+   [RFC3471]  Berger, L., Ed., "Generalized Multi-Protocol Label
+              Switching (GMPLS) Signaling Functional Description", RFC
+              3471, DOI 10.17487/RFC3471, January 2003,
+              <http://www.rfc-editor.org/info/rfc3471>.
+
+   [RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
+              Switching (GMPLS) Signaling Resource ReserVation Protocol-
+              Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
+              DOI 10.17487/RFC3473, January 2003,
+              <http://www.rfc-editor.org/info/rfc3473>.
+
+   [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>.
+
+   [RFC5420]  Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
+              Ayyangarps, "Encoding of Attributes for MPLS LSP
+              Establishment Using Resource Reservation Protocol Traffic
+              Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420,
+              February 2009, <http://www.rfc-editor.org/info/rfc5420>.
+
+
+
+
+Bernstein, et al.            Standards Track                   [Page 13]
+
+RFC 7689                WSON Signaling Extensions          November 2015
+
+
+   [RFC5511]  Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
+              Used to Form Encoding Rules in Various Routing Protocol
+              Specifications", RFC 5511, DOI 10.17487/RFC5511, April
+              2009, <http://www.rfc-editor.org/info/rfc5511>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc6205>.
+
+   [RFC7570]  Margaria, C., Ed., Martinelli, G., Balls, S., and B.
+              Wright, "Label Switched Path (LSP) Attribute in the
+              Explicit Route Object (ERO)", RFC 7570,
+              DOI 10.17487/RFC7570, July 2015,
+              <http://www.rfc-editor.org/info/rfc7570>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc7581>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc7688>.
+
+7.2. Informative References
+
+   [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>.
+
+
+
+
+
+
+Bernstein, et al.            Standards Track                   [Page 14]
+
+RFC 7689                WSON Signaling Extensions          November 2015
+
+
+Acknowledgments
+
+   The authors would like to thanks Lou Berger, Cyril Margaria, and Xian
+   Zhang for their comments and suggestions.
+
+Contributors
+
+   Nicola Andriolli
+   Scuola Superiore Sant'Anna
+   Pisa, Italy
+   Email: nick@sssup.it
+
+   Alessio Giorgetti
+   Scuola Superiore Sant'Anna
+   Pisa, Italy
+   Email: a.giorgetti@sssup.it
+
+   Lin Guo
+   Key Laboratory of Optical Communication and Lightwave Technologies
+   Ministry of Education
+   P.O. Box 128, Beijing University of Posts and Telecommunications
+   China
+   Email: guolintom@gmail.com
+
+   Yuefeng Ji
+   Key Laboratory of Optical Communication and Lightwave Technologies
+   Ministry of Education
+   P.O. Box 128, Beijing University of Posts and Telecommunications
+   China
+   Email: jyf@bupt.edu.cn
+
+   Daniel King
+   Old Dog Consulting
+   Email: daniel@olddog.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bernstein, et al.            Standards Track                   [Page 15]
+
+RFC 7689                WSON Signaling Extensions          November 2015
+
+
+Authors' Addresses
+
+   Greg M. Bernstein (editor)
+   Grotto Networking
+   Fremont, CA
+   United States
+   Phone: (510) 573-2237
+   Email: gregb@grotto-networking.com
+
+
+   Sugang Xu
+   National Institute of Information and Communications Technology
+   4-2-1 Nukui-Kitamachi, Koganei,
+   Tokyo, 184-8795
+   Japan
+   Phone: +81 42-327-6927
+   Email: xsg@nict.go.jp
+
+
+   Young Lee (editor)
+   Huawei Technologies
+   5340 Legacy Dr. Building 3
+   Plano, TX  75024
+   United States
+   Phone: (469) 277-5838
+   Email: leeyoung@huawei.com
+
+
+   Giovanni Martinelli
+   Cisco
+   Via Philips 12
+   20052 Monza
+   Italy
+   Phone: +39 039-209-2044
+   Email: giomarti@cisco.com
+
+
+   Hiroaki Harai
+   National Institute of Information and Communications Technology
+   4-2-1 Nukui-Kitamachi, Koganei,
+   Tokyo, 184-8795
+   Japan
+   Phone: +81 42-327-5418
+   Email: harai@nict.go.jp
+
+
+
+
+
+
+
+Bernstein, et al.            Standards Track                   [Page 16]
+