idnits 2.17.1 draft-ietf-issll-rsvp-cap-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 24 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 13 instances of lines with control characters in the document. ** The abstract seems to contain references ([RSVP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2998 (ref. 'INTDIFF') Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 draft-ietf-issll-rsvp-cap-02.txt 3 Internet Draft Syed, Hamid 4 draft-ietf-issll-rsvp-cap-02.txt Nortel Networks 6 February, 2001 8 Capability Negotiation: The RSVP CAP Object 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Distribution of this memo is unlimited. 31 Copyright Notice 33 Copyright (C) The Internet Society (2001). All Rights Reserved. 35 1. Abstract 37 The resource reservation protocol [RSVP] is an end-to-end signaling 38 protocol and it can be a useful mechanism to carry the upstream node or 39 network capabilities/willingness to the downstream network/nodes. 41 This draft proposes a capability negotiation object, CAP object, in the 42 RSVP PATH message that can be used to convey end host/upstream node 43 capabilities to the downstream network/nodes. 45 2. Introduction 47 In today's heterogenous networking environment, it is important for each 48 network to have a knowledge of its upstream nodes/network capabilities 49 before it can perform any actions to support the QoS requirements of the 51 draft-ietf-issll-rsvp-cap-02.txt February, 2001 53 flows from upstream networks. Such an advance information would help the 54 network operator to configure the network according to the expected 55 nature of traffic that the network devices have to process and route. 56 The current standards does not provide any way to the end host or 57 network devices to specify their capabilities to the downstream nodes. 58 The resource reservation protocol [RSVP] is an end-to-end signaling 59 protocol and has already been proposed in different scenarios to support 60 end-to-end QoS [INTDIFF]. It can be a useful signaling mechanism to 61 carry the upstream node/network capabilities or willingness to the 62 downstream network or nodes. 64 This draft proposes a capability negotiation object, The RSVP CAP 65 object, in the RSVP PATH message that can be used to convey end 66 host/upstream node capabilities/willingness to the downstream network. 67 This is a generic object that can be used to carry any meaningful 68 capability information in the RSVP PATH message. 70 3. Conventions used in this document 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC-2119]. 76 4. Format of CAP Object 78 The CAP object has the following format: 80 0 | 1 | 2 | 3 81 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 82 | Length | C-Num (TBD) | C-Type=1 | 83 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 84 | CAP field | 85 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 87 The CAP field is defined with full 32 bits in the object. Each bit in 88 the field can be used for one specific capability representation. 90 5. Message Processing Rules 92 5.1 Message Generation (RSVP Host) 94 An RSVP PATH message is created as specified in [RSVP] with following 95 modifications 97 1. A capability (CAP) object is created and the CAP field is set to 98 indicate the various capabilities of the end host. Only those bits 99 are set that represent a specific capability of the end host. The 100 bits that are unused MUST be left reset 102 draft-ietf-issll-rsvp-cap-02.txt February, 2001 104 An example; 105 CAP field: 107 0x0X: A_Cap 108 The host/node capability/willingness identifier. 109 If A_Cap bit is reset, the sender host/upstream node 110 does not have the capability 111 If A_Cap bit is set, the sender host/upstream node does 112 have the capability 114 Note: A_Cap represents a single capability/willingness of the end 115 host/upstream network node 117 2. The CAP Object is inserted in the RSVP message in the appropriate 118 place. 120 5.2 Message Reception (Downstream Router) 122 RSVP PATH message is processed at the downstream router as specified in 123 [RSVP] with following modifications. 125 1. The router records the CAP object as the micro-flow PATH state 127 2. The router modifies the CAP object by setting the CAP field to 128 reflect its own capabilities 130 5.3 Message Reception (Upstream Router) 132 RSVP RESV message is processed at the upstream router as specified in 133 [RSVP] with following modifications. 135 1. The router checks the recorded PATH state for the micro-flow and 136 installs any rules required to handle the traffic 138 2. If the router is not aware of the rules, it SHOULD seek the policy 139 rules from the domain policy server 141 6. IANA Considerations 143 The format of CAP object requires a class number (C-Num) in RSVP 144 message. Moreover, the capabilities defined through the CAP object 145 will be defined in other RFCs and their values will be assigned 146 through IANA. 148 7. References 150 [INTDIFF], Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., 151 Speer, M., Braden, R., Davie, B., Wroclawski, J., "Integrated Services 152 Operation over Diffserv Networks", RFC 2998, November 2000 154 draft-ietf-issll-rsvp-cap-02.txt February, 2001 156 [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - 157 Functional Specification.", IETF RFC 2205, Sep. 1997. 159 [RFC-2119] S. Bradner, "keywords for use in RFCs to Indicate Requirement 160 Levels", RFC 2119 (BCP), IETF, March 1997. 162 8. Acknowledgments 164 Thanks to Yoram Bernet and other ISSLL WG members for providing useful 165 comments to make this one happen. Special thanks to Bill Gage for 166 reviewing this draft 168 9. Author's Address 170 Syed, Hamid 171 Nortel Networks 172 100 - Constellation Crescent, 173 Nepean, ON K2G 6J8 174 Phone: (613) 763-6553 175 Email: hmsyed@nortelnetworks.com 177 10. Full Copyright Statement 179 "Copyright (C) The Internet Society (date). All Rights Reserved. 180 This document and translations of it may be copied and furnished to 181 others, and derivative works that comment on or otherwise explain it 182 or assist in its implementation may be prepared, copied, published 183 and distributed, in whole or in part, without restriction of any 184 kind, provided that the above copyright notice and this paragraph 185 are included on all such copies and derivative works. However, this 186 document itself may not be modified in any way, such as by removing 187 the copyright notice or references to the Internet Society or other 188 Internet organisations, except as needed for the purpose of 189 developing Internet standards in which case the procedures for 190 copyrights defined in the Internet Standards process must be 191 followed, or as required to translate it into languages other than 192 English. 194 The limited permissions granted above are perpetual and will not be 195 revoked by the Internet Society or its successors or assigns. 197 This document and the information contained herein is provided on an 198 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 199 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 200 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 201 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 202 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 204 draft-ietf-issll-rsvp-cap-02.txt February, 2001