draft-ietf-tsvwg-intserv-multiple-tspec-01.txt   draft-ietf-tsvwg-intserv-multiple-tspec-02.txt 
Network WG James Polk Network WG James Polk
Internet-Draft Subha Dhesikan Internet-Draft Subha Dhesikan
Expires: September 12, 2012 Cisco Systems Expires: August 25, 2013 Cisco Systems
Intended Status: Standards Track (PS) March 12, 2012 Intended Status: Standards Track (PS) February 25, 2013
Updates: RFC 2205, 2210, & 4495 (if published as an RFC) Updates: RFC 2205, 2210, & 4495 (if published as an RFC)
Integrated Services (IntServ) Extension to Allow Signaling of Multiple Integrated Services (IntServ) Extension to Allow Signaling of Multiple
Traffic Specifications and Multiple Flow Specifications in RSVPv1 Traffic Specifications and Multiple Flow Specifications in RSVPv1
draft-ietf-tsvwg-intserv-multiple-tspec-01 draft-ietf-tsvwg-intserv-multiple-tspec-02
Abstract Abstract
This document defines extensions to Integrated Services (IntServ) This document defines extensions to Integrated Services (IntServ)
allowing multiple traffic specifications and multiple flow allowing multiple traffic specifications and multiple flow
specifications to be conveyed in the same Resource Reservation specifications to be conveyed in the same Resource Reservation
Protocol (RSVPv1) reservation message exchange. This ability helps Protocol (RSVPv1) reservation message exchange. This ability helps
optimize an agreeable bandwidth through a network between endpoints optimize an agreeable bandwidth through a network between endpoints
in a single round trip. in a single round trip.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on Sept 12, 2012. This Internet-Draft will expire on August 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2013 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 of the Proposal for including multiple TSPECs and 2. Overview of the Proposal for including multiple TSPECs and
FLOWSPECs . . . . . . . . . . . . 6 FLOWSPECs . . . . . . . . . . . . 6
3. Multi_TSPEC and MULTI_FLOWSPEC Solution . . . . . . . . . . . 8 3. MULTI_TSPEC and MULTI_FLOWSPEC Solution . . . . . . . . . . . 8
3.1 New MULTI_TSPEC and MULTI-RSPEC Parameters . . . . . . . 9 3.1 New MULTI_TSPEC and MULTI-RSPEC Parameters . . . . . . . 9
3.2 Multiple TSPEC in a PATH Message . . . . . . . . . . . . 9 3.2 Multiple TSPEC in a PATH Message . . . . . . . . . . . . 9
3.3 Multiple FLOWSPEC for Controlled Load Service . . . . . . 12 3.3 Multiple FLOWSPEC for Controlled Load Service . . . . . . 12
3.4 Multiple FLOWSPEC for Guaranteed Service . . . . . . . . 14 3.4 Multiple FLOWSPEC for Guaranteed Service . . . . . . . . 14
4. Rules of Usage . . . . . . . . . . . . . . . . . . . . . . . 17 4. Rules of Usage . . . . . . . . . . . . . . . . . . . . . . . 17
4.1 Backward Compatibility . . . . . . . . . . . . . . . . . 17 4.1 Backward Compatibility . . . . . . . . . . . . . . . . . 17
4.2 Applies to Only a Single Session . . . . . . . . . . . . 17 4.2 Applies to Only a Single Session . . . . . . . . . . . . 17
4.3 No Special Error Handling for PATH Message . . . . . . . 17 4.3 No Special Error Handling for PATH Message . . . . . . . 17
4.4 Preference Order to be Maintained . . . . . . . . . . . 18 4.4 Preference Order to be Maintained . . . . . . . . . . . 18
4.5 Bandwidth Reduction in Downstream Routers . . . . . . . 18 4.5 Bandwidth Reduction in Downstream Routers . . . . . . . 18
skipping to change at page 8, line 28 skipping to change at page 8, line 28
NOTE: it is important to emphasize here that including more than NOTE: it is important to emphasize here that including more than
one FLOWSPEC in the RESV message does not cause more than one one FLOWSPEC in the RESV message does not cause more than one
FLOWSPEC to be granted. This document requires that the FLOWSPEC to be granted. This document requires that the
receiver arrange these multiple FLOWSPECs in the order of receiver arrange these multiple FLOWSPECs in the order of
preference according to the order remaining from the preference according to the order remaining from the
MULTI_TSPECs in the PATH message. The benefit of this MULTI_TSPECs in the PATH message. The benefit of this
arrangement is that RSVP does not have to process the rest of arrangement is that RSVP does not have to process the rest of
the FLOWSPEC if it can admit the first one. the FLOWSPEC if it can admit the first one.
3. Multi_TSPEC and MULTI_FLOWSPEC Solution 3. MULTI_TSPEC and MULTI_FLOWSPEC Solution
For the Sender Descriptor within the PATH message, the original For the Sender Descriptor within the PATH message, the original
TSPEC remains where it is, and is untouched by this IntServ TSPEC remains where it is, and is untouched by this IntServ
extension. What is new is the use of a new <MULTI_TSPEC> object extension. What is new is the use of a new <MULTI_TSPEC> object
inside the sender descriptor as shown here: inside the sender descriptor as shown here:
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ] [ <MULTI_TSPEC> ] [ <ADSPEC> ] [ <MULTI_TSPEC> ]
^^^^^^^^^^^ ^^^^^^^^^^^
skipping to change at page 21, line 47 skipping to change at page 21, line 47
bandwidth of an accepted reservation with one of the TSPECs that bandwidth of an accepted reservation with one of the TSPECs that
were not accepted by the network when the reservation was first were not accepted by the network when the reservation was first
installed. This SHOULD NOT occur too regularly. This document installed. This SHOULD NOT occur too regularly. This document
currently offers no guidance on the frequency of this bump request currently offers no guidance on the frequency of this bump request
for a rejected TSPEC from the PATH. for a rejected TSPEC from the PATH.
4.10 Known Open Issues 4.10 Known Open Issues
Here are the know open issues within this document: Here are the know open issues within this document:
o Both the idea of MULTI_RSPEC and MULTI_FLOWSPEC need to be
fleshed out, and IANA registered.
o Need to ensure the cap on the number of TSPECs and FLOWSPECs is o Need to ensure the cap on the number of TSPECs and FLOWSPECs is
viable, yet controlled. viable, yet controlled.
5. Security considerations 5. Security considerations
The security considerations for this document do not exceed what is The security considerations for this document do not exceed what is
already in RFC 2205 (RESV) or RFC 2210 (IntServ), as nothing in already in RFC 2205 (RESV) or RFC 2210 (IntServ), as nothing in
either of those documents prevent a node from requesting a lot of either of those documents prevent a node from requesting a lot of
bandwidth in a single TSPEC. This document merely reduces the bandwidth in a single TSPEC. This document merely reduces the
signaling traffic load on the network by allowing many requests that signaling traffic load on the network by allowing many requests that
skipping to change at page 23, line 12 skipping to change at page 23, line 12
"Admission Control "Admission Control
Failure" Failure"
Error Subcode meaning Reference Error Subcode meaning Reference
------------- ----------------------------------------- --------- ------------- ----------------------------------------- ---------
6 = MULTI_TSPEC bandwidth unavailable [RFCXXXX] 6 = MULTI_TSPEC bandwidth unavailable [RFCXXXX]
7. Acknowledgments 7. Acknowledgments
The authors wish to thank Fred Baker, Joe Touch, Bruce Davie, Dave The authors wish to thank Fred Baker, Joe Touch, Bruce Davie, Dave
Oran, Ashok Narayanan, Lou Berger, Lars Eggert, Arun Kudur and Janet Oran, Ashok Narayanan, Lou Berger, Lars Eggert, Arun Kudur, Ken
Gunn for their helpful comments and guidance in this effort. Carlberg and Janet Gunn for their helpful comments and guidance in
this effort.
And to Francois Le Faucheur, who provided text in this version. And to Francois Le Faucheur, who provided text in this version.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997 Requirement Levels", RFC 2119, March 1997
skipping to change at page 26, line 17 skipping to change at page 26, line 17
enhancement be made in a way that is backward compatible. Therefore, enhancement be made in a way that is backward compatible. Therefore,
option #1 and option #2 has been discarded in favor of option #3, option #1 and option #2 has been discarded in favor of option #3,
which had WG consensus in a recent IETF meeting. which had WG consensus in a recent IETF meeting.
Option #3: This option has the advantage of being backwards Option #3: This option has the advantage of being backwards
compatible with existing implementations of [RFC2205] and [RFC2210], compatible with existing implementations of [RFC2205] and [RFC2210],
as the multiple TSPECs and FLOWSPECs are inserted as optional as the multiple TSPECs and FLOWSPECs are inserted as optional
objects and such objects do not need to be processed, especially if objects and such objects do not need to be processed, especially if
they are not understood. they are not understood.
Option#3 applies to the FLOWSPEC contained in the RESV message as Option #3 applies to the FLOWSPEC contained in the RESV message as
well. In this option, the original SENDER_TSPEC and the FLOWSPEC are well. In this option, the original SENDER_TSPEC and the FLOWSPEC are
left untouched, allowing routers not supporting this extension to be left untouched, allowing routers not supporting this extension to be
able to process the PATH and the RESV message without issue. Two new able to process the PATH and the RESV message without issue. Two new
additional objects are defined in this document. They are the additional objects are defined in this document. They are the
MULTI_TSPEC and the MULTI_FLOWSPEC for the PATH and the RESV MULTI_TSPEC and the MULTI_FLOWSPEC for the PATH and the RESV
message, respectively. The additional TSPECs (in the new MULTI_TSPEC message, respectively. The additional TSPECs (in the new MULTI_TSPEC
Object) are included in the PATH and the additional FLOWSPECS (in Object) are included in the PATH and the additional FLOWSPECS (in
the new MULTI_FLOWSPEC Object) are included in the RESV message as the new MULTI_FLOWSPEC Object) are included in the RESV message as
new (optional) objects. These additional objects will have a class new (optional) objects. These additional objects will have a class
number of 11bbbbbb, allowing older routers to ignore the object(s) number of 11bbbbbb, allowing older routers to ignore the object(s)
 End of changes. 9 change blocks. 
13 lines changed or deleted 11 lines changed or added

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