Movatterモバイル変換


[0]ホーム

URL:


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

PROPOSED STANDARD
Internet Engineering Task Force (IETF)                 G. Bernstein, Ed.Request for Comments: 7689                             Grotto NetworkingCategory: Standards Track                                          S. XuISSN: 2070-1721                                                     NICT                                                             Y. Lee, Ed.                                                                  Huawei                                                           G. Martinelli                                                                   Cisco                                                                H. Harai                                                                    NICT                                                           November 2015Signaling Extensions for Wavelength Switched Optical NetworksAbstract   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 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/rfc7689.Bernstein, et al.            Standards Track                    [Page 1]

RFC 7689                WSON Signaling Extensions          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 ....................................................32. Terminology .....................................................32.1. Conventions Used in This Document ..........................43. Requirements for WSON Signaling .................................43.1. WSON Signal Characterization ...............................43.2. Per-Node Processing Configuration ..........................53.3. Bidirectional WSON LSPs ....................................53.4. Distributed Wavelength Assignment Selection Method .........63.5. Optical Impairments ........................................64. WSON Signal Traffic Parameters, Attributes, and Processing ......64.1. Traffic Parameters for Optical Tributary Signals ...........74.2. WSON Processing Hop Attribute TLV ..........................74.2.1. ResourceBlockInfo Sub-TLV ...........................84.2.2. WavelengthSelection Sub-TLV .........................95. Security Considerations ........................................116. IANA Considerations ............................................117. References .....................................................137.1. Normative References ......................................137.2. Informative References ....................................14   Acknowledgments ...................................................15   Contributors ......................................................15   Author's Addresses ................................................16Bernstein, et al.            Standards Track                    [Page 2]

RFC 7689                WSON Signaling Extensions          November 20151.  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, wavelengthBernstein, 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 directionsBernstein, 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 20154.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 TLVSection 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 inSection 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           YesRFC 7689         Processing         Hop         Attribute         TLVBernstein, 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                ReservedRFC 7689   1                ResourceBlockInfoRFC 7689   2                WavelengthSelectionRFC 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             unspecifiedRFC 7689   1             First-FitRFC 7689   2             RandomRFC 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 valueRFC 7689   108                Unsupported Wavelength Assignment                      valueRFC 76897.  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>.   [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",RFC3471, 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",RFC6205, 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",RFC7581, 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 2015Acknowledgments   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.ukBernstein, et al.            Standards Track                   [Page 15]

RFC 7689                WSON Signaling Extensions          November 2015Authors' 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.jpBernstein, et al.            Standards Track                   [Page 16]

[8]ページ先頭

©2009-2026 Movatter.jp