Network Working Group H. Long
Internet Draft Huawei Technologies Co., Ltd.
Intended status: Standards Track May 16, 2011
Expires: November 2011
GMPLS Signaling Extension for Bandwidth availability
draft-long-ccamp-gmpls-bandwidth-availability-00.txt
Abstract
Packet switching network usually contains links formed by non-fiber
media, e.g., copper, radio, etc. Some kinds of non-fiber links have
non-fixed bandwidth capacity because they are very sensitive to
external environment. This document describes an extension for GMPLS
RSVP-TE signaling for setting up a LSP in a PSN network which
contains non-fixed bandwidth link by introducing an optional
availability field in GMPLS signaling.
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 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
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on November 16, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Long Expires November 16, 2011 [Page 1]
Internet-Draft GMPLS Extension - Bandwidth Availability May 2011
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents carefully,
as they describe your rights and restrictions with respect to this
document. Code Components extracted from this document must include
Simplified BSD License text as described in Section 4.e of the Trust
Legal Provisions and are provided without warranty as described in
the Simplified BSD License.
Table of Contents
1. Introduction ................................................ 2
2. Extension to RSVP-TE Signaling............................... 3
3. Extension to Routing Protocol................................ 5
4. Security Considerations...................................... 7
5. IANA Considerations ......................................... 7
6. References .................................................. 7
6.1. Normative References.................................... 7
6.2. Informative References.................................. 7
7. Acknowledgments ............................................. 7
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
1. Introduction
The RSVP-TE specification [RFC3209] and GMPLS extensions [RFC3473]
specify the signaling message including the bandwidth request for
setting up a label switching path in a PSN network.
For some networks, it is also necessary to specify the availability
requirement for the bandwidth request. This is because the links can
provide different bandwidth capacity for different availability
requirements. This kind of link is very popular in the access or
backhaul networks.
For example, the radio links may change their interface rates due to
rain, fog, etc. The DSL links may change their interface rates due to
external interference. <Availability, bandwidth> is often used to
describe the bandwidth capacity of the links during network planning.
To set up a LSP across such kind of links, availability information
is required for the nodes to verify bandwidth satisfaction and make
bandwidth reservation. The availability information should be
Long Expires November 16, 2011 [Page 2]
Internet-Draft GMPLS Extension - Bandwidth Availability May 2011
inherited from the availability requirements of the services expected
to be carried on the LSP. Since different service types may need
different availabilities guarantee, multiple <availability,
bandwidth> pairs may be required to be signaled. In addition, for the
routing computation, the availability information should also be
provided with bandwidth resource information.
To fulfill LSP setup by signaling in these scenarios, this document
specifies the following extensions:
o A new SENDER_TSPEC object is defined which includes multiple
bandwidth profiles with different availability. This object is
an extension on the Ethernet SENDER_TSPEC defined by [RFC6003]
which support multiple bandwidth profile TLVs, but limited in
the scope of Ethernet. The extension uses the object genericly,
and amends availability information in the bandwidth profile TLV.
o An extension on ISCD for availability information support in
routing signaling. The extension reuses the reserved field in
the ISCD defined by [RFC4202] and also introduces an optional
availability sub-TLV.
2. Extension to RSVP-TE Signaling
2.1. SENDER_TSPEC Object
The SENDER_TSPEC object (Class-Num = 12) has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (12)| C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Class-Specific Information (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Class-Specific Information: 32 bits
This field indicates the specific information for different C-Type.
Long Expires November 16, 2011 [Page 3]
Internet-Draft GMPLS Extension - Bandwidth Availability May 2011
TLV (Type-Length-Value):
The SENDER_TSPEC object MUST include at least one TLV and MAY
include more than one TLV.
2.1.1. Bandwidth Profile TLV
The Bandwidth Profile TLV has the following format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Profile | Index | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... ... |
~ Traffic Parameters ~
| ... ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Profile: 8 bits
This field is defined as a bit vector of binary flags. The
following flags are defined:
Flag 3 (bit 2): Availability Flag (AF)
When The Flag 3 is set to value 1, there is an availability
sub-TLV included in this Bandwidth Profile TLV. The
availability sub-TLV has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Availability Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (2 octets): TBD
Length (2 octets): 4
Value (4 octets): a 32-bit floating number describes
availability requirement for this bandwidth request. The
value must be less than 1.
Index: 8 bits
Long Expires November 16, 2011 [Page 4]
Internet-Draft GMPLS Extension - Bandwidth Availability May 2011
See [RFC6003] section 4.1.
Traffic Parameters:
This field includes the traffic parameters information. The
format is different for different C-Type.
C-Type = InteServ: See [RFC2210];
C-Type = Ethernet: See [RFC6003];
2.2. FLOWSPEC Object
The FLOWSPEC object (Class-Num = 9, Class-Type = TBD) has the same
format as the Ethernet SENDER_TSPEC object.
2.3. Signaling Process
The sender initiates PATH messages including one or more Bandwidth
Profile TLVs with different availability value in the SENDER_TSPEC
object. Each Bandwidth Profile TLV specifies the portion of bandwidth
request with referred availability requirement.
The receiving nodes check whether it can satisfy the bandwidth
requirement by comparing each bandwidth requirement inside the
SENDER_TSPEC objects with the unallocated link bandwidth resource
with respective availability guarantee.
o If all bandwidth requirements can be satisfied, it should
allocate the bandwidth resource from each unallocated bandwidth
portion for this LSP.
o If at least one bandwidth requirement cannot be satisfied, it
should generate PathErr messages.
3. Extension to Routing Protocol
3.1. Interface Switching Capacity Descriptor
The Interface Switching Capacity Descriptor (ISCD) sub-TLV has the
following format:
Long Expires November 16, 2011 [Page 5]
Internet-Draft GMPLS Extension - Bandwidth Availability May 2011
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | AI | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Switching Capacity Information ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AI: 8 bits
This field is the index of availability sub-TLV for this ISCD
sub-TLV. The
3.2. ISCD Availability sub-TLV
The availability sub-TLV has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Availability Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD;
Length: 8
Index: 8 bits
This field is the index of this availability sub-TLV
Availability Information: 32 bits
This field is a 32-bit IEEE floating point number which
describes the availability guarantee of the switching
capacity in the ISCD object which has the AI value equal to
Index of this sub-TLV. The value must be less than 1.
Long Expires November 16, 2011 [Page 6]
Internet-Draft GMPLS Extension - Bandwidth Availability May 2011
4. Security Considerations
This document does not introduce new security considerations to the
existing GMPLS and OSPF signaling protocols.
5. IANA Considerations
TBD
6. References
6.1. Normative References
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V.,and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4202] Kompella, K. and Rekhter, Y. (Editors), "Routing Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005.
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, October 2005.
[RFC6003] Papadimitriou, D. "Ethernet Traffic Parameters", RFC 6003,
October 2010.
6.2. Informative References
[MCOS] Minei, I., Gan, D., Kompella, K., and X. Li, "Extensions
for Differentiated Services-aware Traffic Engineered
LSPs", Work in Progress, June 2006.
7. Acknowledgments
<Add any acknowledgements>
Long Expires November 16, 2011 [Page 7]
Internet-Draft GMPLS Extension - Bandwidth Availability May 2011
Authors' Addresses
Hao Long
Huawei Technologies Co., Ltd.
Bantian, Longgang District
Shenzhen 518129, P.R.China
Phone: +86-18615778750
Email: longhao@huawei.com
Long Expires November 16, 2011 [Page 8]