draft-ietf-ccamp-rsvp-te-bandwidth-availability-11.txt   draft-ietf-ccamp-rsvp-te-bandwidth-availability-12.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
ZTE ZTE
A.D'Alessandro A.D'Alessandro
Telecom Italia S.p.A Telecom Italia S.p.A
H. Shah H. Shah
Ciena Ciena
Expires: April 2019 October 22, 2018 Expires: July 2019 January 2, 2019
Ethernet Traffic Parameters with Availability Information Ethernet Traffic Parameters with Availability Information
draft-ietf-ccamp-rsvp-te-bandwidth-availability-11.txt draft-ietf-ccamp-rsvp-te-bandwidth-availability-12.txt
Abstract Abstract
A packet switching network may contain links with variable bandwidth, A packet switching network may contain links with variable bandwidth,
e.g., copper, radio, etc. The bandwidth of such links is sensitive e.g., copper, radio, etc. The bandwidth of such links is sensitive
to external environment. Availability is typically used for to external environment. Availability is typically used for
describing the link during network planning. This document describing the link during network planning. This document
introduces an optional Availability TLV in Resource ReSerVation introduces an optional Availability TLV in Resource ReSerVation
Protocol - Traffic Engineer (RSVP-TE) signaling. This extension can Protocol - Traffic Engineer (RSVP-TE) signaling. This extension can
be used to set up a Generalized Multi-Protocol Label Switching be used to set up a Generalized Multi-Protocol Label Switching
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 22, 2019. This Internet-Draft will expire on July 2, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 3, line 21 skipping to change at page 3, line 21
specify the signaling message including the bandwidth request for specify the signaling message including the bandwidth request for
setting up a Label Switched Path in a packet switching network. setting up a Label Switched Path in a packet switching network.
Some data communication technologies allow seamless change of Some data communication technologies allow seamless change of
maximum physical bandwidth through a set of known discrete values. maximum physical bandwidth through a set of known discrete values.
The parameter availability [G.827], [F.1703], [P.530] is often used The parameter availability [G.827], [F.1703], [P.530] is often used
to describe the link capacity during network planning. The to describe the link capacity during network planning. The
availability is a time scale, which is a proportion of the operating availability is a time scale, which is a proportion of the operating
time that the requested bandwidth is ensured. A more detailed time that the requested bandwidth is ensured. A more detailed
example on the bandwidth availability can be found in Appendix A. example on the bandwidth availability can be found in Appendix A.
Assigning different availability classes to different types of Assigning different bandwidth availability classes to different
service over such kind of links provides more efficient planning of types of service over such kind of links provides more efficient
link capacity. To set up an LSP across these links, availability planning of link capacity. To set up an LSP across these links,
information is required for the nodes to verify bandwidth bandwidth availability information is required for the nodes to
satisfaction and make bandwidth reservation. The availability verify bandwidth satisfaction and make bandwidth reservation. The
information should be inherited from the availability requirements bandwidth availability information should be inherited from the
of the services expected to be carried on the LSP. For example, bandwidth availability requirements of the services expected to be
voice service usually needs "five nines" availability, while non- carried on the LSP. For example, voice service usually needs "five
real time services may adequately perform at four or three nines nines" bandwidth availability, while non-real time services may
availability. Since different service types may need different adequately perform at four or three nines bandwidth availability.
availabilities guarantees, multiple <availability, bandwidth> pairs Since different service types may need different availabilities
may be required when signaling. guarantees, multiple <availability, bandwidth> pairs may be required
when signaling.
If the availability requirement is not specified in the signaling If the bandwidth availability requirement is not specified in the
message, the bandwidth will be reserved as the highest availability. signaling message, the bandwidth will be reserved as the highest
For example, the bandwidth with 99.999% availability of a link is bandwidth availability. For example, the bandwidth with 99.999%
100 Mbps; the bandwidth with 99.99% availability is 200 Mbps. When a availability of a link is 100 Mbps; the bandwidth with 99.99%
video application requests for 120 Mbps without availability availability is 200 Mbps. When a video application requests for 120
requirement, the system will consider the request as 120 Mbps with Mbps without bandwidth availability requirement, the system will
99.999% availability, while the available bandwidth with 99.999% consider the request as 120 Mbps with 99.999% bandwidth availability,
availability is only 100 Mbps, therefore the LSP path cannot be set while the available bandwidth with 99.999% bandwidth availability is
up. But in fact, video application doesn't need 99.999% availability; only 100 Mbps, therefore the LSP path cannot be set up. But in fact,
99.99% availability is enough. In this case, the LSP could be set up video application doesn't need 99.999% bandwidth availability; 99.99%
if availability is specified in the signaling message. bandwidth availability is enough. In this case, the LSP could be set
up if bandwidth availability is specified in the signaling message.
To fulfill LSP setup by signaling in these scenarios, this document To fulfill LSP setup by signaling in these scenarios, this document
specifies an Availability TLV. The Availability TLV can be specifies an Availability TLV. The Availability TLV can be
applicable to any kind of physical links with variable discrete applicable to any kind of physical links with variable discrete
bandwidth, such as microwave or DSL. Multiple Availability TLVs bandwidth, such as microwave or DSL. Multiple Availability TLVs
together with multiple Ethernet Bandwidth Profiles can be carried by together with multiple Ethernet Bandwidth Profiles can be carried by
the Ethernet SENDER_TSPEC object [RFC6003]. Since the Ethernet the Ethernet SENDER_TSPEC object [RFC6003]. Since the Ethernet
FLOWSPEC object has the same format as the Ethernet SENDER_TSPEC FLOWSPEC object has the same format as the Ethernet SENDER_TSPEC
object [RFC6003], the Availability TLV can also be carried by the object [RFC6003], the Availability TLV can also be carried by the
Ethernet FLOWSPEC object. Ethernet FLOWSPEC object.
skipping to change at page 5, line 17 skipping to change at page 5, line 17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index | Reserved | | Index | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Availability | | Availability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Availability TLV Figure 1: Availability TLV
Index (1 octet): Index (1 octet):
The Availability TLV MUST come along with Ethernet Bandwidth When the Availability TLV is included, it MUST be present along
Profile TLV. If the bandwidth requirements in the multiple with the Ethernet Bandwidth Profile TLV. If the bandwidth
Ethernet Bandwidth Profile TLVs have different Availability requirements in the multiple Ethernet Bandwidth Profile TLVs have
requirements, multiple Availability TLVs SHOULD be carried. In different Availability requirements, multiple Availability TLVs
such a case, the Availability TLV has one to one correspondence SHOULD be carried. In such a case, the Availability TLV has one to
with Ethernet Bandwidth Profile TLV by having the same value of one correspondence with Ethernet Bandwidth Profile TLV by having
Index field. If all the bandwidth requirements in the Ethernet the same value of Index field. If all the bandwidth requirements
Bandwidth Profile have the same Availability requirement, one in the Ethernet Bandwidth Profile have the same Availability
Availability TLV SHOULD be carried. In this case, the Index field requirement, one Availability TLV SHOULD be carried. In this case,
is set to 0. the Index field is set to 0.
Reserved (3 octets): These bits SHOULD be set to zero when sent Reserved (3 octets): These bits SHOULD be set to zero when sent
and MUST be ignored when received. and MUST be ignored when received.
Availability (4 octets): a 32-bit floating number describes the Availability (4 octets): a 32-bit floating number describes the
decimal value of availability requirement for this bandwidth decimal value of availability requirement for this bandwidth
request. The value MUST be less than 1and is usually expressed in request. The value MUST be less than 1and is usually expressed in
the value of 0.99/0.999/0.9999/0.99999. the value of 0.99/0.999/0.9999/0.99999.
3.2. Signaling Process 3.2. Signaling Process
skipping to change at page 6, line 21 skipping to change at page 6, line 21
this LSP. Optionally, the higher availability bandwidth can be this LSP. Optionally, the higher availability bandwidth can be
allocated to lower availability request when the lower allocated to lower availability request when the lower
availability bandwidth cannot satisfy the request. availability bandwidth cannot satisfy the request.
o When at least one <bandwidth, availability> requirement o When at least one <bandwidth, availability> requirement
cannot be satisfied, it SHOULD generate PathErr message with cannot be satisfied, it SHOULD generate PathErr message with
the error code "Admission Control Error" and the error value the error code "Admission Control Error" and the error value
"Requested Bandwidth Unavailable" (see [RFC2205]). "Requested Bandwidth Unavailable" (see [RFC2205]).
When two LSPs request bandwidth with the same availability When two LSPs request bandwidth with the same availability
requirement, contention SHOULD/MUST be resolved by comparing the requirement, contention MUST be resolved by comparing the node IDs,
node IDs, with the LSP with the higher node ID being assigned the with the LSP with the higher node ID being assigned the reservation.
reservation. This is consistent with general contention resolution This is consistent with general contention resolution mechanism
mechanism provided in section 3.2 of [RFC3473]. provided in section 3.2 of [RFC3473].
When a node does not support Availability TLV, it SHOULD generate When a node does not support Availability TLV, it SHOULD generate
PathErr message with the error code "Extended Class-Type Error" and PathErr message with the error code "Extended Class-Type Error" and
the error value "Class-Type mismatch" (see [RFC2205]). the error value "Class-Type mismatch" (see [RFC2205]).
4. Security Considerations 4. Security Considerations
This document does not introduce new security considerations to the This document does not introduce new security considerations to the
existing RSVP-TE signaling protocol. [RFC5920] provides an overview existing RSVP-TE signaling protocol. [RFC5920] provides an overview
of security vulnerabilities and protection mechanisms for the GMPLS of security vulnerabilities and protection mechanisms for the GMPLS
 End of changes. 8 change blocks. 
41 lines changed or deleted 43 lines changed or added

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