RFC 7963

RFC 7963: RSVP-TE Extension for Additional Signal Types in G.709 Optical Transport Networks (OTNs) ✨

okay bestie, let's talk about this one 🫶 RFC 7963 is an Informational doc (not Standards Track 💅) from August 2016, published under ISSN 2070-1721. The authors are Z. Ali, A. Bonfanti, and M. Hartley from Cisco Systems, plus F. Zhang from Huawei Technologies. The header doesn't list any Obsoletes or Updates entries, so it isn't replacing or changing another RFC 🌸

Abstract

okay so RFC 4328 and RFC 7139 already give RSVP-TE (the signaling protocol that sets up traffic paths) the tools to control the full set of Optical Transport Network (OTN) features 🦋 but they don't cover the extra Optical channel Data Unit (ODU) containers from G.Sup43, which are ODU1e, ODU3e1, and ODU3e2 🙈 this doc adds new Signal Types for those containers so everything can be signaled properly ✨

---

Status of This Memo

this is not an Internet Standards Track spec, it's just published for info 💜

it's a product of the IETF 🌈 it represents the community's consensus, it got public review, and the IESG approved it for publication. not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the full scoop 🎀

if you want the current status, any errata, or a way to send feedback, go to http://www.rfc-editor.org/info/rfc7963 🔥

Copyright Notice

Copyright (c) 2016 IETF Trust and the people listed as authors. all rights reserved 💅

this doc is covered by BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. read those carefully, bestie, because they spell out your rights and restrictions 📜 any Code Components you pull out of this doc need Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, per that license 🍓

heads up: some material in here may come from IETF Documents or Contributions published before November 10, 2008. the people who control the copyright in some of that stuff might not have given the IETF Trust permission to allow changes outside the IETF Standards Process 😭 so without an adequate license from them, this doc can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. the only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🧚

Table of Contents

1. Introduction ................................................... 3
2. RSVP-TE Extension for Additional Signal Types .................. 3
3. Security Considerations ........................................ 3
4. IANA Considerations ............................................ 3
5. References ..................................................... 4
  5.1. Normative References ....................................... 4
  5.2. Informative References ..................................... 4
Acknowledgments ................................................... 4
Authors' Addresses ................................................ 5

1. Introduction ✨

[RFC7139] updates the parts of the text about the Optical channel Data Unit (ODU) from [RFC4328] 🫶 it adds RSVP-TE extensions so you can control [G.709-v3] in the OTN-TDM SENDER_TSPEC and OTN-TDM FLOWSPEC objects. but it doesn't give Signal Types for the ODU1e, ODU3e1, and ODU3e2 containers from [G.Sup43]. so this doc comes in with the RSVP-TE signaling extensions to support those extra Signal Types 💖

ok real talk, these containers aren't standard data-plane frame formats. they're not defined in ITU-T Recommendations 🙈 they're just some of the intra-domain approaches networks use to carry 10GBASE-R signals over optical transport networks. and as a supplement, [G.Sup43] doesn't guarantee data-plane interoperability for these containers 💀 so keep that in mind, babe.

2. RSVP-TE Extension for Additional Signal Types 🦋

[RFC7139] defines the format of Traffic Parameters in the OTN-TDM SENDER_TSPEC and OTN-TDM FLOWSPEC objects 💅 those Traffic Parameters have a Signal Type field. this doc defines the Signal Types for ODU1e, ODU3e1, and ODU3e2, which are listed in the IANA Considerations section 🌸 they get allocated through the Specification Required policy that [RFC7892] added to the subregistry 🎀

3. Security Considerations 🔥

okay this one is short and sweet 💜 this doc doesn't add any new security issues beyond the ones already covered in [RFC7139] 🫶

4. IANA Considerations 🍓

IANA keeps the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry, and that registry has an "OTN Signal Type" subregistry inside it ✨ IANA added three new allocations for ODU1e, ODU3e1, and ODU3e2 to that subregistry, using the Specification Required policy from [RFC5226] 👑

Value            Type
-----            ----
23               ODU1e  (10Gbps Ethernet [G.Sup43])
26               ODU3e1 (40Gbps Ethernet [G.Sup43])
27               ODU3e2 (40Gbps Ethernet [G.Sup43])

these Signal Types ride in the Traffic Parameters in the OTN-TDM SENDER_TSPEC and OTN-TDM FLOWSPEC objects [RFC7139] 🧚

5. References 📜

5.1. Normative References

[RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, DOI 10.17487/RFC4328, January 2006, http://www.rfc-editor.org/info/rfc4328.

[RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., and K. Pithewan, "GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks", RFC 7139, DOI 10.17487/RFC7139, March 2014, http://www.rfc-editor.org/info/rfc7139.

[RFC7892] Ali, Z., Bonfanti, A., Hartley, M., and F. Zhang, "IANA Allocation Procedures for the GMPLS OTN Signal Type Registry", RFC 7892, DOI 10.17487/RFC7892, May 2016, http://www.rfc-editor.org/info/rfc7892.

5.2. Informative References

[G.709-v3] ITU-T, "Interfaces for the optical transport network", Recommendation G.709/Y.1331, June 2016.

[G.Sup43] ITU-T, "Transport of IEEE 10GBASE-R in optical transport networks (OTN)", Recommendation G.Sup43, February 2011.

[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.

Acknowledgments 💖

the authors want to thank Dieter Beller, Lou Berger, Deborah Brungard, Daniele Ceccarelli, Adrian Farrel, and Sudip Shukla for their comments 🫶✨

Authors' Addresses 🌈

Zafar Ali
Cisco Systems

Email: zali@cisco.com


Antonello Bonfanti
Cisco Systems

Email: abonfant@cisco.com


Matt Hartley
Cisco Systems

Email: mhartley@cisco.com


Fatai Zhang
Huawei Technologies

Email: zhangfatai@huawei.com