draft-ietf-ccamp-ospf-availability-extension-07.txt | draft-ietf-ccamp-ospf-availability-extension-08.txt | |||
---|---|---|---|---|
Network Working Group H. Long, M.Ye | Network Working Group H. Long, M.Ye | |||
Internet Draft Huawei Technologies Co., Ltd | Internet Draft Huawei Technologies Co., Ltd | |||
Intended status: Standards Track G. Mirsky | Intended status: Standards Track G. Mirsky | |||
Ericsson | Individual | |||
A.D'Alessandro | A.D'Alessandro | |||
Telecom Italia S.p.A | Telecom Italia S.p.A | |||
H. Shah | H. Shah | |||
Ciena | Ciena | |||
Expires: April 2017 October 8, 2016 | Expires: April 2017 October 24, 2016 | |||
OSPF-TE Link Availability Extension for Links with Variable Discrete | OSPF-TE Link Availability Extension for Links with Variable Discrete | |||
Bandwidth | Bandwidth | |||
draft-ietf-ccamp-ospf-availability-extension-07.txt | draft-ietf-ccamp-ospf-availability-extension-08.txt | |||
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 | copper, radio, etc. The bandwidth of such links may change | |||
discretely in reaction to changing external environment. | discretely in reaction to changing external environment. | |||
Availability is typically used for describing such links during | Availability is typically used for describing such links during | |||
network planning. This document introduces an optional ISCD | network planning. This document introduces an optional Interface | |||
Availability sub-TLV to extend the Generalized Multi-Protocol Label | Switching Capability Descriptor (ISCD) Availability sub-TLV to | |||
Switching (GMPLS) Open Shortest Path First (OSPF) routing protocol. | extend the Generalized Multi-Protocol Label Switching (GMPLS) Open | |||
This extension can be used for route computation in a network that | Shortest Path First (OSPF) routing protocol. This extension can be | |||
contains links with variable discrete bandwidth. Note, this document | used for route computation in a network that contains links with | |||
only covers the mechanisms by which the availability information is | variable discrete bandwidth. Note, this document only covers the | |||
distributed. The mechanisms by which availability information of a | mechanisms by which the availability information is distributed. The | |||
link is determined and the use of the distributed information for | mechanisms by which availability information of a link is determined | |||
route computation are outside the scope of this document. | and the use of the distributed information for route computation are | |||
outside the scope of this document. It is intended that technology- | ||||
specific documents will reference this document to describe specific | ||||
uses. | ||||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
skipping to change at page 2, line 13 ¶ | skipping to change at page 2, line 16 ¶ | |||
months and may be updated, replaced, or obsoleted by other documents | months and may be updated, replaced, or obsoleted by other documents | |||
at any time. It is inappropriate to use Internet-Drafts as | at any time. It is inappropriate to use Internet-Drafts as | |||
reference material or to cite them other than as "work in progress." | reference material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html | http://www.ietf.org/shadow.html | |||
This Internet-Draft will expire on April 8, 2016. | This Internet-Draft will expire on April 24, 2016. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2016 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 | (http://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 | |||
skipping to change at page 2, line 37 ¶ | skipping to change at page 2, line 40 ¶ | |||
Section 4.e of the Trust Legal Provisions and are provided without | Section 4.e of the Trust Legal Provisions and are provided without | |||
warranty as described in the Simplified BSD License. | warranty as described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction ................................................ 3 | 1. Introduction ................................................ 3 | |||
2. Overview .................................................... 4 | 2. Overview .................................................... 4 | |||
3. Extension to OSPF Routing Protocol........................... 4 | 3. Extension to OSPF Routing Protocol........................... 4 | |||
3.1. ISCD Availability sub-TLV............................... 4 | 3.1. ISCD Availability sub-TLV............................... 4 | |||
3.2. Signaling Process....................................... 5 | 3.2. Signaling Process....................................... 5 | |||
4. Security Considerations...................................... 5 | 4. Security Considerations...................................... 6 | |||
5. IANA Considerations ......................................... 6 | 5. IANA Considerations ......................................... 6 | |||
6. References .................................................. 6 | 6. References .................................................. 7 | |||
6.1. Normative References.................................... 6 | 6.1. Normative References.................................... 7 | |||
6.2. Informative References.................................. 7 | 6.2. Informative References.................................. 7 | |||
7. Acknowledgments ............................................. 8 | 7. Acknowledgments ............................................. 8 | |||
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", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC-2119 [RFC2119]. | document are to be interpreted as described in RFC-2119 [RFC2119]. | |||
The following acronyms are used in this draft: | The following acronyms are used in this draft: | |||
GMPLS Generalized Multi-Protocol Label Switching | GMPLS Generalized Multi-Protocol Label Switching | |||
LSA Link State Advertisement | LSA Link State Advertisement | |||
skipping to change at page 3, line 11 ¶ | skipping to change at page 3, line 14 ¶ | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC-2119 [RFC2119]. | document are to be interpreted as described in RFC-2119 [RFC2119]. | |||
The following acronyms are used in this draft: | The following acronyms are used in this draft: | |||
GMPLS Generalized Multi-Protocol Label Switching | GMPLS Generalized Multi-Protocol Label Switching | |||
LSA Link State Advertisement | LSA Link State Advertisement | |||
ISCD Interface Switching Capacity Descriptor | 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 | PSN Packet Switched Network | |||
SNR Signal-to-noise Ratio | SNR Signal-to-noise Ratio | |||
SONET-SDH Synchronous Optical Network - Synchronous Digital | SONET-SDH Synchronous Optical Network -- Synchronous Digital | |||
Hierarchy | Hierarchy | |||
SPF Shortest Path First | SPF Shortest Path First | |||
TE Traffic Engineering | ||||
TLV Type Length Value | ||||
1. Introduction | 1. Introduction | |||
Some data plane technologies, e.g., microwave, and copper, allow | Some data plane technologies, e.g., microwave, and copper, allow | |||
seamless change of maximum physical bandwidth through a set of known | seamless change of maximum physical bandwidth through a set of known | |||
discrete values. The parameter, availability, as described in | discrete values. The parameter, availability, as described in | |||
[G.827], [F.1703] and [P.530] is often used to describe the link | [G.827], [F.1703] and [P.530] is often used to describe the link | |||
capacity. The availability is a time scale, representing a proportion | capacity. The availability is a time scale, representing a proportion | |||
of the operating time that the requested bandwidth is ensured. To | of the operating time that the requested bandwidth is ensured. To | |||
set up an LSP across these links, availability information is | set up an LSP across these links, availability information is | |||
required by the nodes to verify the bandwidth before making a | required by the nodes to verify the bandwidth before making a | |||
skipping to change at page 4, line 5 ¶ | skipping to change at page 4, line 12 ¶ | |||
statically configured. It will usually be determined from the | statically configured. It will usually be determined from the | |||
availability requirements of the services expected to be carried on | availability requirements of the services expected to be carried on | |||
the LSP. For example, voice service usually needs ''five nines'' | the LSP. For example, voice service usually needs ''five nines'' | |||
availability, while non-real time services may adequately perform at | availability, while non-real time services may adequately perform at | |||
four or three nines availability. For the route computation, both | four or three nines availability. For the route computation, both | |||
the availability information and the bandwidth resource information | the availability information and the bandwidth resource information | |||
are needed. Since different service types may need different | are needed. Since different service types may need different | |||
availability guarantees, multiple <availability, bandwidth> pairs | availability guarantees, multiple <availability, bandwidth> pairs | |||
may be required to be associated with a link. | may be required to be associated with a link. | |||
In this document, an extension on Interface Switching Capacity | In this document, an extension on Interface Switching Capability | |||
Descriptor (ISCD) [RFC4202] for availability information is defined. | Descriptor (ISCD) [RFC4202] for availability information is defined. | |||
The signaling extension to support links with discrete bandwidth is | It is intended that technology-specific documents will reference | |||
defined in [ETPAI]. | this document to describe specific uses. The signaling extension to | |||
support links with discrete bandwidth is defined in [ETPAI]. | ||||
2. Overview | 2. Overview | |||
A node which has link(s) with variable bandwidth attached should | A node which has link(s) with variable bandwidth attached should | |||
include a < availability, bandwidth> information list in its OSPF TE | include a< availability, bandwidth> information list in its OSPF | |||
LSA messages. The list provides the mapping between the link nominal | Traffic Engineering (TE) LSA messages. The list provides the mapping | |||
bandwidth and its availability level. This information is used for | between the link nominal bandwidth and its availability level. This | |||
path calculation by the node(s).The setup of a Label Switched Path | information is used for path calculation by the node(s).The setup of | |||
requires this information to be flooded in the network and used by | a Label Switched Path requires this information to be flooded in the | |||
the nodes or the PCE for the path computation. In this document, an | network and used by the nodes or the PCE for the path computation. | |||
extension to Interface Switching Capacity Descriptor (ISCD) [RFC4202] | In this document, an extension to Interface Switching Capability | |||
for availability information is defined. The computed path can then | Descriptor (ISCD) [RFC4202] for availability information is defined. | |||
be provisioned via the signaling protocol[ETPAI]. | The computed path can then be provisioned via the signaling protocol | |||
[ETPAI]. | ||||
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. | |||
3. TE Metric Extension to OSPF-TE | 3. TE Metric Extension to OSPF-TE | |||
3.1. ISCD Availability sub-TLV | 3.1. ISCD Availability sub-TLV | |||
skipping to change at page 4, line 47 ¶ | skipping to change at page 5, line 14 ¶ | |||
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: TBA by IANA, suggested value is 0x01, 16 bits; | Type: TBA by IANA, suggested value is 0x01, 16 bits. | |||
Length: A 16 bits field that expresses the length of the TLV in | ||||
bytes; | ||||
Availability level: 32 bits | Length: A 16 bits field that expresses the length of the TLV in | |||
bytes. | ||||
This field is a 32-bit IEEE floating point number which | Availability level: 32 bits | |||
describes the decimal value of availability guarantee of the | ||||
switching capability in the ISCD 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 32-bit IEEE floating point number which describes | |||
the decimal value of availability guarantee of the switching | ||||
capability in the ISCD 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. | ||||
This field is a 32-bit IEEE floating point number which | LSP Bandwidth at Availability level n: 32 bits | |||
describes the LSP Bandwidth for the Availability level | ||||
represented in the Availability field. The units are bytes | This field is a 32-bit IEEE floating point number which describes | |||
per second. | the LSP Bandwidth for the Availability level represented in the | |||
Availability field. The units are bytes per second. | ||||
3.2. Processing Procedures | 3.2. Processing Procedures | |||
A node which has link(s) with variable bandwidth attached SHOULD | A node advertising an interface with a Switching Capability which | |||
contain one or more ISCD Availability sub-TLVs in its OSPF TE LSA | supports variable bandwidth attached SHOULD contain one or more ISCD | |||
messages. Each ISCD Availability sub-TLV provides the information | Availability sub-TLVs in its OSPF TE LSA messages. Each ISCD | |||
about how much bandwidth a link can support for a specified | Availability sub-TLV provides the information about how much | |||
availability. This information SHOULD be used for path calculation | bandwidth a link can support for a specified availability. This | |||
by the node(s). | information MAY be used for path calculation by the node(s). | |||
A node that does not support the ISCD Availability sub-TLV SHOULD | The ISCD Availability sub-TLV MUST NOT be sent in ISCDs with | |||
ignore ISCD Availability sub-TLV but it SHOULD be included in LSAs | Switching Capability field values that have not been defined to | |||
sent to OSPF neighbors [RFC3630]. If a node who supports ISCD | support the ISCD Availability sub-TLV. Non-supporting nodes would | |||
Availability sub-TLVs does not receive the TLV, it SHOULD assume | see such as a malformed ISCD/LSA. | |||
that the link is with fixed bandwidth, and the availability can be | ||||
interpreted as the highest availability value, e.g., five nines. | Absence of the ISCD Availability sub-TLV in an ISCD containing | |||
It's not allowed to send multiple ISCD Availability sub-TLVs for the | Switching Capability field values that have been defined to support | |||
same availability level. | the ISCD Availability sub-TLV, SHALL be interpreted as representing | |||
fixed-bandwidth link with the highest availability value. | ||||
Only one ISCD Availability sub-TLVs for the specific availability | ||||
level SHOULD be sent. If multiple are present, only the first ISCD | ||||
Availability sub-TLV for an availability level carried in the same | ||||
ISCD SHALL be processed. | ||||
4. Security Considerations | 4. Security Considerations | |||
This document does not introduce security issues beyond those | This document does not introduce security issues beyond those | |||
discussed in [RFC4203]. As with [RFC4203], it specifies the content | discussed in [RFC4203]. As with [RFC4203], it specifies the content | |||
of an Opaque LSAs in OSPFv2. As Opaque LSAs are not used for | of an Opaque LSAs in OSPFv2. As Opaque LSAs are not used for | |||
Shortest Path First (SPF) computation or normal routing, the | Shortest Path First (SPF) computation or normal routing, the | |||
extensions specified here have no direct effect on IP routing. | extensions specified here have no direct effect on IP routing. | |||
Tampering with GMPLS TE LSAs may have an impact on the ability to | Tampering with GMPLS TE LSAs may have an impact on the ability to | |||
set up connections in the underlying data plane network. As the | set up connections in the underlying data plane network. As the | |||
additional availability information may represent information that | additional availability information may represent information that | |||
an operator may wish to keep private, consideration should be given | an operator may wish to keep private, consideration should be given | |||
to securing this information.[RFC3630] notes that the security | to securing this information. [RFC3630] notes that the security | |||
mechanisms described in [RFC2328] apply to Opaque LSAs carried in | mechanisms described in [RFC2328] apply to Opaque LSAs carried in | |||
OSPFv2. An analysis of the security of OSPF is provided in [RFC6863] | OSPFv2. An analysis of the security of OSPF is provided in [RFC6863] | |||
and applies to the extensions to OSPF as described in this document. | and applies to the extensions to OSPF as described in this document. | |||
Any new mechanisms developed to protect the transmission of | Any new mechanisms developed to protect the transmission of | |||
information carried in Opaque LSAs will also automatically protect | information carried in Opaque LSAs will also automatically protect | |||
the extensions defined in this document. | the extensions 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 attacks; | techniques; monitoring, detection, and reporting of security attacks; | |||
and requirements. | and requirements. | |||
5. IANA Considerations | 5. IANA Considerations | |||
This document introduces an Availability sub-TLV of the ISCD sub-TLV | This document introduces an Availability sub-TLV of the ISCD sub-TLV | |||
of the TE Link TLV in the TE Opaque LSA for OSPF v2. IANA is | of the TE Link TLV in the TE Opaque LSA for OSPF v2. Technology- | |||
requested to create a new sub-registry, the ''Types for sub-TLV of | specific documents will reference this document to describe specific | |||
Interface Switching Capability Descriptor'' registry under the "Open | use of this Availability sub-TLV. IANA is requested to create a new | |||
Shortest Path First (OSPF) Traffic Engineering TLVs" registry, see | sub-registry, the ''Types for sub-TLV of Interface Switching | |||
Capability Descriptor'' registry under the "Open Shortest Path First | ||||
(OSPF) Traffic Engineering TLVs" registry, see | ||||
http://www.iana.org/assignments/ospf-traffic-eng-tlvs. | http://www.iana.org/assignments/ospf-traffic-eng-tlvs. | |||
This document proposes a suggested value for the Availability sub- | This document proposes a suggested value for the Availability sub- | |||
TLV; it is requested that the suggested value be granted by IANA. | TLV; it is requested that the suggested value be granted by IANA. | |||
Type Description Reference | Type Description Reference | |||
--- ------------------ ----------- | --- ------------------ ----------- | |||
0 Reserved [This ID] | 0 Reserved [This ID] | |||
skipping to change at page 8, line 28 ¶ | skipping to change at page 9, line 20 ¶ | |||
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, P.R.China | |||
Email: amy.yemin@huawei.com | Email: amy.yemin@huawei.com | |||
Greg Mirsky | Greg Mirsky | |||
Ericsson | Individual | |||
Email: gregory.mirsky@ericsson.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 | |||
End of changes. 25 change blocks. | ||||
66 lines changed or deleted | 82 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |