diff options
Diffstat (limited to 'doc/rfc/rfc7689.txt')
| -rw-r--r-- | doc/rfc/rfc7689.txt | 899 |
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] + |