draft-ietf-ccamp-rsvp-te-bandwidth-availability-10.txt   draft-ietf-ccamp-rsvp-te-bandwidth-availability-11.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: March 2019 September 27, 2018 Expires: April 2019 October 22, 2018
Ethernet Traffic Parameters with Availability Information Ethernet Traffic Parameters with Availability Information
draft-ietf-ccamp-rsvp-te-bandwidth-availability-10.txt draft-ietf-ccamp-rsvp-te-bandwidth-availability-11.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 March 27, 2019. This Internet-Draft will expire on April 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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 (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 5, line 38 skipping to change at page 5, line 38
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
The source node initiates PATH messages which carry a number of The source node initiates a PATH message which may carry a number of
bandwidth request information, including one or more Ethernet bandwidth request information, including one or more Ethernet
Bandwidth Profile TLVs and one or more Availability TLVs. Each Bandwidth Profile TLVs and one or more Availability TLVs. Each
Ethernet Bandwidth Profile TLV corresponds to an availability Ethernet Bandwidth Profile TLV corresponds to an availability
parameter in the Availability TLV. parameter in the Availability TLV.
The intermediate and destination nodes check whether they can The intermediate and destination nodes check whether they can
satisfy the bandwidth requirements by comparing each bandwidth satisfy the bandwidth requirements by comparing each bandwidth
requirement inside the SENDER_TSPEC objects with the remaining link requirement inside the SENDER_TSPEC objects with the remaining link
sub-bandwidth resource with respective availability guarantee on the sub-bandwidth resource with respective availability guarantee on the
local link when received the PATH message. local link when the PATH message is received.
o If all <bandwidth, availability> requirements can be o When all <bandwidth, availability> requirements can be
satisfied (the requested bandwidth under each availability satisfied (the requested bandwidth under each availability
parameter is smaller than or equal to the remaining bandwidth parameter is smaller than or equal to the remaining bandwidth
under the corresponding availability parameter on its local under the corresponding availability parameter on its local
link), it SHOULD reserve the bandwidth resource from each link), it SHOULD reserve the bandwidth resource from each
remaining sub-bandwidth portion on its local link to set up remaining sub-bandwidth portion on its local link to set up
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 If at least one <bandwidth, availability> requirement cannot o When at least one <bandwidth, availability> requirement
be satisfied, it SHOULD generate PathErr message with the error cannot be satisfied, it SHOULD generate PathErr message with
code "Admission Control Error" and the error value "Requested the error code "Admission Control Error" and the error value
Bandwidth Unavailable" (see [RFC2205]). "Requested Bandwidth Unavailable" (see [RFC2205]).
If two LSPs request for the bandwidth with the same availability When two LSPs request bandwidth with the same availability
requirement, a way to resolve the contention is comparing the node requirement, contention SHOULD/MUST be resolved by comparing the
ID, the node with the higher node ID will win the contention. More node IDs, with the LSP with the higher node ID being assigned the
details can be found in [RFC3473]. reservation. This is consistent with general contention resolution
mechanism provided in section 3.2 of [RFC3473].
If 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
control plane. control plane.
 End of changes. 9 change blocks. 
15 lines changed or deleted 16 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/