draft-ietf-ccamp-ospf-availability-extension-03.txt   draft-ietf-ccamp-ospf-availability-extension-04.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 Ericsson
A.D'Alessandro A.D'Alessandro
Telecom Italia S.p.A Telecom Italia S.p.A
H. Shah H. Shah
Ciena Ciena
Expires: April 13, 2016 October 16, 2015 Expires: August 2016 February 19, 2016
OSPF Routing Extension for Links with Variable Discrete Bandwidth OSPF Routing Extension for Links with Variable Discrete Bandwidth
draft-ietf-ccamp-ospf-availability-extension-03.txt draft-ietf-ccamp-ospf-availability-extension-04.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 ISCD
Availability sub-TLV in OSPF routing protocol. This extension can be Availability sub-TLV in OSPF routing protocol. This extension can be
used for route computation in a network that contains links with used for route computation in a network that contains links with
variable discrete bandwidth. variable discrete bandwidth.
Status of this Memo Status of this Memo
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
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 13, 2016. This Internet-Draft will expire on August 19, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
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 .................................................... 3 2. Overview .................................................... 3
3. Extension to OSPF Routing Protocol........................... 4 3. Extension to OSPF Routing Protocol........................... 4
3.1. Interface Switching Capacity Descriptor................. 4 3.1. ISCD Availability sub-TLV............................... 4
3.2. ISCD Availability sub-TLV............................... 4 3.2. Signaling Process....................................... 5
3.3. Signaling Process....................................... 5
4. Security Considerations...................................... 5 4. Security Considerations...................................... 5
5. IANA Considerations ......................................... 5 5. IANA Considerations ......................................... 5
6. References .................................................. 5 6. References .................................................. 5
6.1. Normative References.................................... 5 6.1. Normative References.................................... 5
6.2. Informative References.................................. 6 6.2. Informative References.................................. 6
7. Acknowledgments ............................................. 6 7. Acknowledgments ............................................. 6
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",
skipping to change at page 3, line 22 skipping to change at page 3, line 22
known discrete values. The parameter availability [G.827, F.1703, known discrete values. The parameter availability [G.827, F.1703,
P.530] is often used to describe the link capacity during network P.530] is often used to describe the link capacity during network
planning. The availability is a time scale that the requested planning. The availability is a time scale that the requested
bandwidth is ensured. Assigning different availability classes to bandwidth is ensured. Assigning different availability classes to
different types of service over such kind of links provides more different types of service over such kind of links provides more
efficient planning of link capacity. To set up an LSP across these efficient planning of link capacity. To set up an LSP across these
links, availability information is required for the nodes to verify links, availability information is required for the nodes to verify
bandwidth satisfaction and make bandwidth reservation. The bandwidth satisfaction and make bandwidth reservation. The
availability information should be inherited from the availability availability information should be inherited from the availability
requirements of the services expected to be carried on the LSP. For requirements of the services expected to be carried on the LSP. For
example, voice service usually needs "five nines" availability, example, voice service usually needs ''five nines'' availability,
while non-real time services may adequately perform at four or three while non-real time services may adequately perform at four or three
nines availability. Since different service types may need different nines availability. Since different service types may need different
availabilities guarantees, multiple <availability, bandwidth> pairs availabilities guarantees, multiple <availability, bandwidth> pairs
may be required when signaling. The signaling extension for links may be required when signaling. The signaling extension for links
with discrete bandwidth is defined in [ASTE]. with discrete bandwidth is defined in [ASTE].
For the route computation, the availability information should be For the route computation, the availability information should be
provided along with bandwidth resource information. In this document, provided along with bandwidth resource information. In this document,
an extension on Interface Switching Capacity Descriptor (ISCD) an extension on Interface Switching Capacity Descriptor (ISCD)
[RFC4202] for availability information is defined to support in [RFC4202] for availability information is defined to support in
skipping to change at page 4, line 13 skipping to change at page 4, line 13
to get know about the network topology, calculate out an LSP route to get know about the network topology, calculate out an LSP route
based on the network topology and send the calculated LSP route to based on the network topology and send the calculated LSP route to
signaling to initiate a PATH/RESV message for setting up the LSP. signaling to initiate a PATH/RESV message for setting up the LSP.
Availability information is required to carry in the signaling Availability information is required to carry in the signaling
message to better utilize the link bandwidth. The signaling message to better utilize the link bandwidth. The signaling
extension for availability can be found in [ASTE]. extension for availability can be found in [ASTE].
3. Extension to OSPF Routing Protocol 3. Extension to OSPF Routing Protocol
3.1. Interface Switching Capacity Descriptor 3.1. ISCD Availability sub-TLV
The Interface Switching Capacity Descriptor (ISCD) sub-TLV is The Interface Switching Capacity Descriptor (ISCD) sub-TLV is
defined in Section 1.4 of [RFC 4203]. defined in Section 1.4 of [RFC 4203]. The ISCD Availability sub-TLV
is defined in this document as a sub-TLV of ISCD. The Switching
3.2. ISCD Availability sub-TLV Capability specific information field of ISCD MAY include one or
more ISCD Availability sub-TLV(s). The ISCD Availability sub-TLV has
The Switching Capability field MAY be PSC-1, LSC. The Switching the following format:
Capability specific information field MAY include one or more ISCD
Availability sub-TLV(s). The ISCD Availability sub-TLV has 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 5 skipping to change at page 5, line 5
switching capacity in the ISCD object which has the AI value switching capacity in the ISCD object which has the AI value
equal to Index of this sub-TLV. The value MUST be less than equal to Index of this sub-TLV. The value MUST be less than
1. 1.
LSP Bandwidth at Availability level n: 32 bits LSP Bandwidth at Availability level n: 32 bits
This field is a 32-bit IEEE floating point number which This field is a 32-bit IEEE floating point number which
describes the LSP Bandwidth at a certain Availability level describes the LSP Bandwidth at a certain Availability level
which was described in the Availability field. which was described in the Availability field.
3.3. Signaling Process 3.2. Signaling Process
A node which has link(s) with variable bandwidth attached SHOULD A node which has link(s) with variable bandwidth attached SHOULD
contain one or more ISCD Availability sub-TLVs in its OSPF TE LSA contain one or more ISCD Availability sub-TLVs in its OSPF TE LSA
messages. Each ISCD Availability sub-TLV provides the information messages. Each ISCD Availability sub-TLV provides the information
about how much bandwidth a link can support for a specified about how much bandwidth a link can support for a specified
availability. This information SHOULD be used for path calculation availability. This information SHOULD be used for path calculation
by the node(s). by the node(s).
A node that doesn't support ISCD Availability sub-TLV SHOULD ignore A node that doesn't support ISCD Availability sub-TLV SHOULD ignore
ISCD Availability sub-TLV. ISCD Availability sub-TLV.
skipping to change at page 5, line 47 skipping to change at page 5, line 47
6. References 6. References
6.1. Normative References 6.1. Normative References
[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, October 2005.
[ASTE] H., Long, M., Ye, Mirsky, G., Alessandro, A., Shah, H., [ASTE] H., Long, M., Ye, Mirsky, G., Alessandro, A., Shah, H.,
"Ethernet Traffic Parameters with Availability ''Ethernet Traffic Parameters with Availability
Information", Work in Progress, June, 2015 Information'', Work in Progress, June, 2015
6.2. Informative References 6.2. Informative References
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated [RFC2210] Wroclawski, J., ''The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997. Services'', RFC 2210, September 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., ''Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997 Requirement Levels'', RFC 2119, March 1997
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V.,and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP V.,and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4202] Kompella, K. and Rekhter, Y. (Editors), "Routing [RFC4202] Kompella, K. and Rekhter, Y. (Editors), ''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, October 2005.
[MCOS] Minei, I., Gan, D., Kompella, K., and X. Li, "Extensions [MCOS] Minei, I., Gan, D., Kompella, K., and X. Li, "Extensions
for Differentiated Services-aware Traffic Engineered for Differentiated Services-aware Traffic Engineered
LSPs", Work in Progress, June 2006. LSPs", Work in Progress, June 2006.
[G.827] ITU-T Recommendation, "Availability performance parameters [G.827] ITU-T Recommendation, ''Availability performance parameters
and objectives for end-to-end international constant bit- and objectives for end-to-end international constant bit-
rate digital paths", September, 2003. rate digital paths'', September, 2003.
[F.1703] ITU-R Recommendation, "Availability objectives for real [F.1703] ITU-R Recommendation, ''Availability objectives for real
digital fixed wireless links used in 27 500 km digital fixed wireless links used in 27 500 km
hypothetical reference paths and connections", January, hypothetical reference paths and connections'', January,
2005. 2005.
[P.530] ITU-R Recommendation," Propagation data and prediction [P.530] ITU-R Recommendation,'' Propagation data and prediction
methods required for the design of terrestrial line-of- methods required for the design of terrestrial line-of-
sight systems", February, 2012 sight systems'', February, 2012
[EN 302 217] ETSI standard, "Fixed Radio Systems; Characteristics [EN 302 217] ETSI standard, ''Fixed Radio Systems; Characteristics
and requirements for point-to-point equipment and and requirements for point-to-point equipment and
antennas", April, 2009 antennas'', April, 2009
7. Acknowledgments 7. Acknowledgments
The authors would like to thank Lou Berger for his comments on the The authors would like to thank Lou Berger for his comments on the
document. document.
Authors' Addresses Authors' Addresses
Hao Long Hao Long
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
 End of changes. 22 change blocks. 
34 lines changed or deleted 30 lines changed or added

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