RFC 7689
Signaling Extensions for Wavelength Switched Optical Networks
RFC 7689: Signaling Extensions for Wavelength Switched Optical Networks 🌈
Okay bestie, here's the title block tea ☕. This is RFC 7689 from the IETF, a Standards Track doc published in November 2015 (ISSN 2070-1721) ✨. The editors are G. Bernstein (Ed., Grotto Networking) and Y. Lee (Ed., Huawei), with co-authors S. Xu (NICT), G. Martinelli (Cisco), and H. Harai (NICT) 🫶. The title block doesn't list anything it obsoletes or updates, so it's standing on its own 💅.
Abstract 🦋
So this doc adds GMPLS signaling extensions for controlling Wavelength Switched Optical Networks (WSONs) 🔥. They're useful in WSONs when (a) optional processing, like regeneration, has to be set up to happen at specific nodes along a path, (b) equipment has to be configured to accept an optical signal with specific attributes, or (c) equipment has to be configured to output an optical signal with specific attributes. It also gives mechanisms that support distributed wavelength assignment with a choice of distributed wavelength assignment algorithms 💖.
Status of This Memo 📜
This is an Internet Standards Track document 🎀.
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check out Section 2 of RFC 5741 ✨.
For the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7689 🌸.
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) as in effect on the date of publication of this document. Please read these documents carefully, because 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 they're 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 ................................................161. Introduction ✨
So this doc adds GMPLS signaling extensions for controlling WSONs 🌈. The fundamental extensions let you do simultaneous bidirectional wavelength assignment, and the more advanced extensions support the networks described in [RFC6163]. Those networks have connections that need input, output, and general signal processing capabilities configured at a node along a Label Switched Path (LSP) 🦋.
These extensions build on earlier work for controlling lambda and G.709-based networks 💅.
Related docs are [RFC7446], which gives a high-level information model, and [RFC7581], which gives common encodings that can apply to other protocol extensions, like routing 🫶.
2. Terminology 📖
CWDM: Coarse Wavelength Division Multiplexing 🌸.
DWDM: Dense Wavelength Division Multiplexing 🌸.
ROADM: Reconfigurable Optical Add/Drop Multiplexer. It's a reduced port count wavelength selective switching element with ingress and egress line side ports, plus add/drop side ports 💖.
RWA: Routing and Wavelength Assignment 🧚.
Wavelength Conversion/Converters: This is the process of converting an information bearing optical signal centered at a given frequency (wavelength) into one with "equivalent" content centered at a different wavelength. It can happen through an optical-electronic-optical (OEO) process or through a strictly optical process ⚡.
WDM: Wavelength Division Multiplexing 🌈.
Wavelength Switched Optical Networks (WSONs): These are WDM-based optical networks where switching is done selectively based on the frequency of an optical signal 👑.
AWG: Arrayed Waveguide Grating 🎀.
OXC: Optical Cross-Connect 🍓.
Optical Transmitter: A device that has both a laser, tuned to a certain wavelength, and electronic components that turn electronic signals into optical signals 🔥.
Optical Receiver: A device that has both optical and electronic components. It detects optical signals and turns them into electronic signals 💜.
Optical Transponder: A device that has both an optical transmitter and an optical receiver 🦋.
Optical End Node: This is the end of a wavelength (optical lambdas) lightpath in the data plane. It may be equipped with optical/electronic devices, like wavelength multiplexers/demultiplexers (e.g., AWG) and optical transponders, which are used to transmit or terminate the optical signals for data transmission 🌸.
FEC: Forward Error Correction. FEC is a digital signal processing technique used to boost data reliability by adding redundant data, called error correcting code, before data is transmitted or stored. It lets the receiver correct errors without a reverse channel to ask for 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 on top of what existing GMPLS signaling mechanisms already give us 🧚.
3.1. WSON Signal Characterization 🦋
WSON signaling needs to convey enough information about the signal to let the systems along the path figure out compatibility and do any required local configuration 🔥. Examples of those systems are intermediate nodes (ROADMs, OXCs, wavelength converters, regenerators, OEO switches, etc.), links (WDM systems), and end systems (detectors, demodulators, etc.). The details of local configuration processes are out of scope for this doc 🙈.
From [RFC6163], we get this list of WSON signal characteristics 📋:
- Optical tributary signal class (modulation format).
- FEC: whether forward error correction is used in the digital stream and what type of error correcting code is used.
- Center frequency (wavelength).
- Bit rate.
- G-PID: General Protocol Identifier for the information format.
The first three items can change as a WSON signal goes through a network with regenerators, OEO switches, or wavelength converters 🌈. These parameters are summed up in the Optical Interface Class defined in [RFC7446], and the assumption is that a class always includes signal compatibility information ✨. GMPLS signaling already has the ability to control wavelength conversion, plus the ability to share client signal type information (G-PID) 💅. Bit rate is also a standard GMPLS signaling traffic parameter. It's called bandwidth encoding in [RFC3471] 💖.
3.2. Per-Node Processing Configuration 🎀
Besides setting a node along an LSP to input or output a signal with specific attributes, we may need to tell the node to do specific processing on the signal at a particular node, like 3R regeneration 🦋. [RFC6163] talked about three types of processing 🌸:
- (A) Regeneration (possibly different types)
- (B) Fault and Performance Monitoring
- (C) Attribute Conversion
The extensions here cover how to configure these types of processing at nodes along an LSP 🫶.
3.3. Bidirectional WSON LSPs 🔁
WSON signaling can support LSP setup that's consistent with the wavelength continuity constraint for bidirectional connections 💜. These cases need to be supported separately 🧚:
- (a) Where the same wavelength is used for both upstream and downstream directions.
- (b) Where different wavelengths are used for both upstream and downstream directions.
This document will look at existing GMPLS bidirectional solutions based on the WSON case 🌈.
3.4. Distributed Wavelength Assignment Selection Method 👑
WSON signaling can support selecting a specific distributed wavelength assignment method 🔥.
This is useful when equipment fails, for example, where fast provisioning for quick recovery is critical to protect carriers and users from system loss 😭. It needs efficient signaling that supports distributed wavelength assignment, especially when the wavelength assignment capability isn't available 🫶.
As [RFC6163] discusses, there are different computational approaches for wavelength assignment 🦋. One method is distributed wavelength assignment. This feature would let you specify a particular approach when more than one is implemented in the systems along the path ✨.
3.5. Optical Impairments 🌸
This document doesn't address signaling information related to optical impairments 🙈.
4. WSON Signal Traffic Parameters, Attributes, and Processing ✨
Okay so, as [RFC6163] explains, single-channel optical signals in WSONs are called "optical tributary signals" 🦋 and they come in a bunch of classes based on modulation format and bit rate. WSONs are pretty transparent to the signals they carry, but to keep different network devices and end systems compatible with each other, it can matter a lot to include key lightpath characteristics as traffic parameters in signaling [RFC6163]. Main character energy 💅
LSPs signaled through the extensions in this document MUST apply the following signaling parameters:
- Switching Capability = WSON-LSC [RFC7688]
- Encoding Type = Lambda [RFC3471]
- Label Format = as defined in [RFC6205]
[RFC6205] defines the label format as applicable to LSC capable devices. 🌸
4.1. Traffic Parameters for Optical Tributary Signals
Okay, so in [RFC3471] we see that the G-PID (client signal type) and the bit rate (byte rate) of the signals are defined as parameters. Then in [RFC3473] they get carried in the Generalized Label Request object and the RSVP SENDER_TSPEC/FLOWSPEC objects, respectively. Iconic routing 🧚
4.2. WSON Processing Hop Attribute TLV
Section 3.1 gives the requirements for signaling to a node along an LSP what kind of processing to do on an optical signal, and how that node should configure itself to accept or transmit an optical signal with particular attributes. 🎀
So to target a specific node, this section defines a WSON Processing Hop Attribute TLV 👑. This TLV is encoded as an attributes TLV (see [RFC5420]). It gets carried in the ERO and RRO Hop Attributes subobjects and processed according to the procedures 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each field means 🫶:
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.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]. Don't mess with the order, bestie 🙈
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's 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 ResourceBlockInfo sub-TLVs that are present 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:
- The 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.
- In the case of unidirectional LSPs, only one ResourceBlockInfo sub-TLV SHALL be processed, and the I and O bits can be safely ignored.
- 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.
- 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]. Not a vibe, so don't do it 💀
A ResourceBlockInfo sub-TLV can be constructed by a node and added to an ERO Hop Attributes subobject so that downstream nodes (transit and egress) can process it. 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 (following the rules above and in [RFC7570]), the node allocates the indicated resources, e.g., the selected regeneration pool, for the LSP. The node SHOULD also 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 gets 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 that's constrained to use the same lambda in both directions. 💜
To indicate the wavelength assignment directionality and the wavelength assignment method, the WavelengthSelection sub-TLV is carried in the WSON Processing Hop Attribute TLV defined above.
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 go like this 📝. 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).
A WavelengthSelection sub-TLV can be constructed by a node and added to an ERO Hop Attributes subobject so that downstream nodes (transit and egress) can process it. 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. The node SHOULD also 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 🔥
Okay, serious moment, bestie 😭 This document is built on the mechanisms defined in [RFC3473], and it only differs in the specific information communicated. The extra 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. Stay safe out there 🛡️💜
6. IANA Considerations ✨
Okay bestie, IANA is the friendly registry keeper of the internet, and this is where the new stuff gets written down so nobody picks the same numbers 🧚. 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
TLVIANA also made a brand new registry called "Sub-TLV Types for WSON Processing Hop Attribute TLV" 🎀, located at <http://www.iana.org/assignments/rsvp-te-parameters>. These entries got added:
Value Sub-TLV Type Reference
0 Reserved RFC 7689
1 ResourceBlockInfo RFC 7689
2 WavelengthSelection RFC 7689All assignments are to be performed via Standards Action or Specification Required policies as defined in [RFC5226]. Standards Action and Specification Required are the two approval routes, so no random vibes-based assignments 💅.
IANA created one more registry, "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 UnassignedAll 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 🔥. That's the rule for keeping the policy trail clean.
Last but not least, IANA 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 76897. References
7.1. Normative References
These are the must-read docs, the ones the spec leans on hardcore 📚.
[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>.
[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
These ones are the background reading, nice to know but not required 🌸.
[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>.Acknowledgments 💜
The authors wanna give a big shoutout to Lou Berger, Cyril Margaria, and Xian Zhang for their comments and suggestions 🫶.
Contributors 🌈
These people helped write the spec, so they get their flowers 🌷:
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.ukAuthors' Addresses 🦋
And here are the authors, the main brains behind all of this 🧠✨:
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📦 where this page comes from
- ietf: rfc7689 2015-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms