draft-ietf-ccamp-ospf-availability-extension-13.txt   rfc8330.txt 
Network Working Group H. Long, M.Ye
Internet Draft Huawei Technologies Co., Ltd
Intended status: Standards Track G. Mirsky
ZTE
A.D'Alessandro
Telecom Italia S.p.A
H. Shah
Ciena
Expires: June 2018 December 5, 2017
OSPF-Traffic Engineering Link Availability Extension for Links with Internet Engineering Task Force (IETF) H. Long
Variable Discrete Bandwidth Request for Comments: 8330 M. Ye
draft-ietf-ccamp-ospf-availability-extension-13.txt Category: Standards Track Huawei Technologies Co., Ltd.
ISSN: 2070-1721 G. Mirsky
ZTE
A. D'Alessandro
Telecom Italia S.p.A.
H. Shah
Ciena
February 2018
OSPF Traffic Engineering (OSPF-TE) Link Availability Extension
for Links with Variable Discrete Bandwidth
Abstract Abstract
A network may contain links with variable discrete bandwidth, e.g., A network may contain links with variable discrete bandwidth, e.g.,
copper, radio, etc. The bandwidth of such links may change microwave and copper. The bandwidth of such links may change
discretely in reaction to changing external environment. discretely in response to a changing external environment. The word
Availability is typically used for describing such links during "availability" is typically used to describe such links during
network planning. This document defines a new type of the network planning. This document defines a new type of Generalized
Generalized Switching Capability-specific information (SCSI) TLV to Switching Capability-Specific Information (SCSI) TLV to extend the
extend the Generalized Multi-Protocol Label Switching (GMPLS) Open Generalized Multiprotocol Label Switching (GMPLS) Open Shortest Path
Shortest Path First (OSPF) routing protocol. The extension can be First (OSPF) routing protocol. The extension can be used for route
used for route computation in a network that contains links with computation in a network that contains links with variable discrete
variable discrete bandwidth. Note, this document only covers the bandwidth. Note that this document only covers the mechanisms by
mechanisms by which the availability information is distributed. The which the availability information is distributed. The mechanisms by
mechanisms by which availability information of a link is determined which availability information of a link is determined and the use of
and the use of the distributed information for route computation are the distributed information for route computation are outside the
outside the scope of this document. It is intended that technology- scope of this document. It is intended that technology-specific
specific documents will reference this document to describe specific documents will reference this document to describe specific uses.
uses.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six Status of This Memo
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html (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 7841.
This Internet-Draft will expire on June 5, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8330.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ................................................ 3 1. Introduction ....................................................3
2. Acronyms .................................................... 3 1.1. Conventions Used in This Document ..........................3
3. Overview .................................................... 4 2. Abbreviations ...................................................4
4. TE Metric Extension to OSPF-TE............................... 4 3. Overview ........................................................4
4.1. Availability SCSI-TLV................................... 4 4. TE Metric Extension to OSPF-TE ..................................5
4.2. Processing Procedures................................... 5 4.1. Availability SCSI-TLV ......................................5
5. Security Considerations...................................... 6 4.2. Processing Procedures ......................................6
6. IANA Considerations ......................................... 6 5. Security Considerations .........................................6
7. References .................................................. 7 6. IANA Considerations .............................................7
7.1. Normative References.................................... 7 7. References ......................................................7
7.2. Informative References.................................. 7 7.1. Normative References .......................................7
8. Acknowledgments ............................................. 8 7.2. Informative References .....................................8
Acknowledgments ...................................................10
Authors' Addresses ................................................10
1. Introduction
Some data-plane technologies, e.g., microwave and copper, allow
seamless changes of maximum physical bandwidth through a set of known
discrete values. The parameter "availability", as described in
[G.827], [F.1703], and [P.530], is often used to describe the link
capacity. The availability is a time scale, representing a
proportion of the operating time that the requested bandwidth is
ensured. To set up a Label Switched Path (LSP) across these links,
availability information is required by the nodes to verify the
bandwidth before making a bandwidth reservation. Assigning different
availability classes over such links provides for more efficient
planning of link capacity to support different types of services.
The link availability information will be determined by the operator
and is statically configured. It will usually be determined from the
availability requirements of the services expected to be carried on
the LSP. For example, voice service usually needs "five nines"
availability, while non-real-time services may adequately perform at
four or three nines availability. For the route computation, both
the availability information and the bandwidth resource information
are needed. Since different service types may need different
availability guarantees, multiple <availability, bandwidth> pairs may
be required to be associated with a link.
In this document, a new type of Generalized SCSI-TLV, the
Availability SCSI-TLV, is defined. It is intended that technology-
specific documents will reference this document to describe specific
uses. The signaling extension to support links with variable
discrete bandwidth is defined in [RSVP-TE-Availability].
1.1. Conventions Used in This Document
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED","MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1. Introduction 2. Abbreviations
Some data plane technologies, e.g., microwave, and copper, allow
seamless change of maximum physical bandwidth through a set of known
discrete values. The parameter, availability, as described in
[G.827], [F.1703] and [P.530] is often used to describe the link
capacity. The availability is a time scale, representing a proportion
of the operating time that the requested bandwidth is ensured. To
set up an LSP across these links, availability information is
required by the nodes to verify the bandwidth before making a
bandwidth reservation. Assigning different availability classes
over such links provides for a more efficient planning of link
capacity to support different types of services. The link
availability information will be determined by the operator and
statically configured. It will usually be determined from the
availability requirements of the services expected to be carried on
the LSP. For example, voice service usually needs "five nines"
availability, while non-real time services may adequately perform at
four or three nines availability. For the route computation, both
the availability information and the bandwidth resource information
are needed. Since different service types may need different
availability guarantees, multiple <availability, bandwidth> pairs
may be required to be associated with a link.
In this document, a new type of the Generalized SCSI TLV,
Availability TLV is defined. It is intended that technology-specific
documents will reference this document to describe specific uses.
The signaling extension to support links with discrete bandwidth is
defined in [I-D. ietf-ccamp-rsvp-te-bandwidth-availability].
2. Acronyms The following abbreviations are used in this document:
The following acronyms are used in this draft: GMPLS Generalized Multiprotocol Label Switching
GMPLS Generalized Multi-Protocol Label Switching ISCD Interface Switching Capability Descriptor
LSA Link State Advertisement LSA Link State Advertisement
ISCD Interface Switching Capability Descriptor
LSP Label Switched Path LSP Label Switched Path
OSPF Open Shortest Path First OSPF Open Shortest Path First
PSN Packet Switched Network SCSI Switching Capability-Specific Information
SCSI Switching Capability-specific information
SNR Signal-to-noise Ratio
SONET-SDH Synchronous Optical Network - Synchronous Digital
Hierarchy
SPF Shortest Path First SPF Shortest Path First
TE Traffic Engineering TE Traffic Engineering
TLV Type Length Value TLV Type-Length-Value
3. Overview 3. Overview
A node which has link(s) with variable bandwidth attached should A node that has link(s) with variable discrete bandwidth attached
include < availability, bandwidth> information list in its OSPF should include an <availability, bandwidth> information list in its
Traffic Engineering (TE) LSA messages. The list provides the mapping OSPF-TE LSA messages. The list provides the mapping between the link
between the link nominal bandwidth and its availability level. This nominal bandwidth and its availability level. This information is
information is used for path calculation by the node(s). The setup used for path calculation by the node(s). The setup of an LSP
of a Label Switched Path requires this information to be flooded in requires this information to be flooded in the network and used by
the network and used by the nodes or the PCE for the path the nodes or the PCE for the path computation. In this document, a
computation. In this document, a new type of the Generalized SCSI new type of Generalized SCSI-TLV, the Availability SCSI-TLV, is
TLV, Availability TLV is defined. The computed path can then be defined. The computed path can then be provisioned via the signaling
provisioned via the signaling protocol [I-D. ietf-ccamp-rsvp-te- protocol [RSVP-TE-Availability].
bandwidth-availability].
Note, the mechanisms described in this document only distribute Note: The mechanisms described in this document only distribute
availability information. The methods for measuring the information availability information. The methods for measuring the information
or using the information for route computation are outside the scope or using the information for route computation are outside the scope
of this document. of this document.
4. TE Metric Extension to OSPF-TE 4. TE Metric Extension to OSPF-TE
4.1. Availability SCSI-TLV 4.1. Availability SCSI-TLV
The Generalized SCSI is defined in [RFC8258]. The Availability TLV The Generalized SCSI is defined in [RFC8258]. This document defines
defined in this document is a new type of Generalized SCSI-TLV. The a new type of Generalized SCSI-TLV called the Availability SCSI-TLV.
Availability SCSI-TLV can be included for one or more times. The The Availability SCSI-TLV can be included one or more times. It has
Availability SCSI-TLV has the following format: the following format:
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Availability level | | Availability level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Bandwidth at Availability level n | | LSP Bandwidth at Availability level n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 0x0001, 16 bits.
Length: 2 octets, 16 bits. Type: 0x000A, 16 bits
Availability level: 32 bits Length: 2 octets (16 bits)
This field is a binary32-format floating point number as defined by Availability level: 32 bits
[IEEE754-2008]. The bytes are transmitted in network order; that is,
the byte containing the sign bit is transmitted first. This field
describes the decimal value of availability guarantee of the
switching capability in the Interface Switching Capability
Descriptor (ISCD) [RFC4202] object. The value MUST be less than 1.
The Availability level is usually expressed in the value of
0.99/0.999/0.9999/0.99999.
LSP Bandwidth at Availability level n: 32 bits This field is a binary32-format floating-point number as
defined by [IEEE754-2008]. The bytes are transmitted in
network order; that is, the byte containing the sign bit is
transmitted first. This field describes the decimal value of
the availability guarantee of the Switching Capability in the
Interface Switching Capability Descriptor object [RFC4202].
The value MUST be less than 1. The Availability level field is
usually expressed as the value 0.99/0.999/0.9999/0.99999.
This field is a 32-bit IEEE floating point number as defined by LSP Bandwidth at Availability level n: 32 bits
[IEEE754-2008]. The bytes are transmitted in network order; that is,
the byte containing the sign bit is transmitted first. This field
describes the LSP Bandwidth for the Availability level represented
in the Availability field. The units are bytes per second.
4.2. Processing Procedures This field is a 32-bit IEEE floating-point number as defined by
[IEEE754-2008]. The bytes are transmitted in network order;
that is, the byte containing the sign bit is transmitted first.
This field describes the LSP bandwidth for the availability
level represented in the Availability level field. The units
are bytes per second.
The ISCD allows routing protocols such as OSPF to carry technology 4.2. Processing Procedures
specific information in the Switching Capability-specific
information (SCSI) field, see [RFC4203]. A node advertising an The ISCD allows routing protocols such as OSPF to carry technology-
interface with a Switching Capability which supports variable specific information in the "Switching Capability-specific
bandwidth attached SHOULD contain one or more Availability SCSI-TLVs information" field; see [RFC4203]. A node advertising an interface
in its OSPF TE LSA messages. Each Availability SCSI-TLV provides the with a Switching Capability that supports variable discrete bandwidth
attached SHOULD contain one or more Availability SCSI-TLVs in its
OSPF-TE LSA messages. Each Availability SCSI-TLV provides
information about how much bandwidth a link can support for a information about how much bandwidth a link can support for a
specified availability. This information may be used for path specified availability. This information may be used for path
calculation by the node(s). calculation by the node(s).
The Availability SCSI-TLV MUST NOT be sent in ISCDs with Switching The Availability SCSI-TLV MUST NOT be sent in ISCDs with Switching
Capability field values that have not been defined to support the Capability field values that have not been defined to support the
Availability SCSI-TLV. Non-supporting nodes would see such as a Availability SCSI-TLV. Non-supporting nodes would see such an
malformed ISCD/LSA. ISCD/LSA as malformed.
Absence of the Availability SCSI-TLV in an ISCD containing Switching The absence of the Availability SCSI-TLV in an ISCD containing
Capability field values that have been defined to support the Switching Capability field values that have been defined to support
Availability SCSI-TLV, SHALL be interpreted as representing fixed- the Availability SCSI-TLV SHALL be interpreted as representing the
bandwidth link with the highest availability value. fixed-bandwidth link with the highest availability value.
Only one Availability SCSI-TLV for the specific availability level Only one Availability SCSI-TLV for the specific availability level
SHOULD be sent. If multiple are present, the Availability SCSI-TLV SHOULD be sent. If multiple TLVs are present, the Availability
with the lowest bandwidth value SHALL be processed. If an SCSI-TLV with the lowest bandwidth value SHALL be processed. If an
Availability SCSI-TLV with an invalid value (e.g., large than 1) is Availability SCSI-TLV with an invalid value (e.g., larger than 1) is
received, the Availability SCSI-TLV will be ignored. received, the Availability SCSI-TLV will be ignored.
5. Security Considerations 5. Security Considerations
This document specifies the contents of Opaque LSAs in OSPFv2. This document specifies the contents of Opaque LSAs in OSPFv2.
Tampering with GMPLS TE LSAs may have an effect on traffic Tampering with GMPLS-TE LSAs may have an effect on TE computations.
engineering computations. [RFC3630] suggests mechanisms such as [RFC3630] suggests such mechanisms as the mechanism described in
[RFC2154] to protect the transmission of this information, and those [RFC2154] to protect the transmission of this information, and those
or other mechanisms should be used to secure and/or authenticate the or other mechanisms should be used to secure and/or authenticate the
information carried in the Opaque LSAs. An analysis of the security information carried in the Opaque LSAs. An analysis of the security
of OSPF is provided in [RFC6863] and applies to the extensions to of OSPF is provided in [RFC6863] and applies to the OSPF extension
OSPF as described in this document. Any new mechanisms developed to defined in this document. Any new mechanisms developed to protect
protect the transmission of information carried in Opaque LSAs will the transmission of information carried in Opaque LSAs will also
also automatically protect the extensions defined in this document. automatically protect the extension defined in this document.
Please refer to [RFC5920] for details on security threats; defensive Please refer to [RFC5920] for details on security threats; defensive
techniques; monitoring, detection, and reporting of security techniques; monitoring, detection, and reporting of security attacks;
attacks; and requirements. and requirements.
6. IANA Considerations 6. IANA Considerations
This document introduces a new type for availability of the This document introduces a new type of Generalized SCSI-TLV
Generalized SCSI-TLV of the TE Link TLV in the TE Opaque LSA for (Availability) that is carried in the OSPF-TE LSA messages.
OSPF v2. Technology-specific documents will reference this document Technology-specific documents will reference this document to
to describe specific use of this Availability SCSI-TLV. describe the specific use of this Availability SCSI-TLV.
IANA has created a registry called the "Generalized SCSI (Switching IANA created a registry called the "Generalized SCSI (Switching
Capability Specific Information) TLVs Types" registry. The registry Capability Specific Information) TLV Types" registry [RFC8258]. The
is needed to be updated to include the Availability SCSI-TLV. This registry has been updated to include the following Availability
document proposes a suggested value for the Availability SCSI-TLV; SCSI-TLV:
it is requested that the suggested value be granted by IANA.
Note (Please REMOVE this note before publication): the registry will Type Description Switching Type Reference
be created by [RFC8258]. The requested value should be added to it ------ ------------ -------------- ---------
when it is created. 0x000A Availability 5, 52 RFC 8330
Type Description Reference New switching types are required in order to use the Availability
SCSI-TLV. IANA has registered the following in the "Switching Types"
registry:
--- ------------------ ----------- Value Name Reference
----- -------------------------- ---------
5 PSC with GSCSI support RFC 8330
52 L2SC with GSCSI support RFC 8330
0x01 Availability [This ID] 7. References
7. References 7.1. Normative References
7.1. Normative References [IEEE754-2008]
IEEE, "IEEE Standard for Floating-Point Arithmetic",
IEEE 754-2008, DOI 10.1109/IEEESTD.2008.4610935.
[RFC8258] Ceccarelli, D. and Berger, L., "Generalized Routing [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Interface Switching Capability Descriptor Switching Requirement Levels", BCP 14, RFC 2119,
Capability Specific Information", RFC 8258, October, 2017. DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4202] Kompella, K. and Rekhter, Y. (Editors), "Routing [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol Label Extensions in Support of Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 4202, October 2005. Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202,
October 2005, <https://www.rfc-editor.org/info/rfc4202>.
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
in Support of Generalized Multi-Protocol Label Switching in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, October 2005. (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
<https://www.rfc-editor.org/info/rfc4203>.
[IEEE754-2008] IEEE standards, "IEEE Standard for Floating-Point [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
Arithmetic", IEEE Standard 754, August 2008 RFC 2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References [RFC8258] Ceccarelli, D. and L. Berger, "Generalized SCSI: A Generic
Structure for Interface Switching Capability Descriptor
(ISCD) Switching Capability Specific Information (SCSI)",
RFC 8258, DOI 10.17487/RFC8258, October 2017,
<https://www.rfc-editor.org/info/rfc8258>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 7.2. Informative References
Requirement Levels", RFC 2119, March 1997.
[RFC2154] Murphy, S., Badger, M., Wellington, B., "OSPF with Digital [F.1703] International Telecommunication Union, "Availability
Signatures", RFC2154, June 1997. objectives for real digital fixed wireless links used in
27 500 km hypothetical reference paths and connections",
ITU-R Recommendation F.1703-0, January 2005,
<https://www.itu.int/rec/R-REC-F.1703-0-200501-I/en>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [G.827] International Telecommunication Union, "Availability
(TE) Extensions to OSPF Version 2", RFC 3630, September performance parameters and objectives for end-to-end
2003. international constant bit-rate digital paths", ITU-T
Recommendation G.827, September 2003,
<https://www.itu.int/rec/T-REC-G.827/en>.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [P.530] International Telecommunication Union, "Propagation data
Networks", RFC 5920, July 2010. and prediction methods required for the design of
terrestrial line-of-sight systems", ITU-R
Recommendation P.530-17, December 2017,
<https://www.itu.int/rec/R-REC-P.530/en>.
[RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with
According to the Keying and Authentication for Routing Digital Signatures", RFC 2154, DOI 10.17487/RFC2154,
Protocols (KARP) Design Guide", RFC 6863, March 2013. June 1997, <https://www.rfc-editor.org/info/rfc2154>.
[G.827] ITU-T Recommendation, "Availability performance parameters [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
and objectives for end-to-end international constant bit- (TE) Extensions to OSPF Version 2", RFC 3630,
rate digital paths", September, 2003. DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[F.1703] ITU-R Recommendation, "Availability objectives for real [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
digital fixed wireless links used in 27 500 km Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
hypothetical reference paths and connections", January, <https://www.rfc-editor.org/info/rfc5920>.
2005.
[P.530] ITU-R Recommendation," Propagation data and prediction [RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security
methods required for the design of terrestrial line-of- According to the Keying and Authentication for Routing
sight systems", February, 2012 Protocols (KARP) Design Guide", RFC 6863,
DOI 10.17487/RFC6863, March 2013,
<https://www.rfc-editor.org/info/rfc6863>.
[I-D. ietf-ccamp-rsvp-te-bandwidth-availability] H., Long, M., Ye, [RSVP-TE-Availability]
Mirsky, G., Alessandro, A., Shah, H., "Ethernet Traffic Long, H., Ye, M., Mirsky, G., D'Alessandro, A., and H.
Parameters with Availability Information", Work in Shah, "Ethernet Traffic Parameters with Availability
Progress, August, 2017 Information", Work in Progress, draft-ietf-ccamp-rsvp-te-
bandwidth-availability-08, January 2018.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC Acknowledgments
2119 Key Words", RFC 8174, May 2017.
8. Acknowledgments The authors would like to thank Acee Lindem, Daniele Ceccarelli, and
Lou Berger for their comments on the document.
The authors would like to thank Acee Lindem, Daniele Ceccarelli, Lou Authors' Addresses
Berger for their comments on the document.
Authors' Addresses
Hao Long Hao Long
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
No.1899, Xiyuan Avenue, Hi-tech Western District No. 1899, Xiyuan Avenue, Hi-tech Western District
Chengdu 611731, P.R.China Chengdu 611731
China
Phone: +86-18615778750 Phone: +86-18615778750
Email: longhao@huawei.com Email: longhao@huawei.com
Min Ye Min Ye
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
No.1899, Xiyuan Avenue, Hi-tech Western District No. 1899, Xiyuan Avenue, Hi-tech Western District
Chengdu 611731, P.R.China Chengdu 611731
China
Email: amy.yemin@huawei.com Email: amy.yemin@huawei.com
Greg Mirsky Greg Mirsky
ZTE ZTE
Email: gregimirsky@gmail.com Email: gregimirsky@gmail.com
Alessandro D'Alessandro Alessandro D'Alessandro
Telecom Italia S.p.A Telecom Italia S.p.A.
Email: alessandro.dalessandro@telecomitalia.it Email: alessandro.dalessandro@telecomitalia.it
Himanshu Shah Himanshu Shah
Ciena Corp. Ciena Corp.
3939 North First Street 3939 North First Street
San Jose, CA 95134 San Jose, CA 95134
US United States of America
Email: hshah@ciena.com Email: hshah@ciena.com
 End of changes. 72 change blocks. 
253 lines changed or deleted 267 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/