idnits 2.17.1 draft-ietf-issll-rsvp-cap-03.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 == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 4) being 64 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 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 is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 12 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 == Line 201 has weird spacing: '...red for recei...' -- 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 (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 draft-ietf-issll-rsvp-cap-03.txt 3 Internet Draft Hamid Syed 4 draft-ietf-issll-rsvp-cap-03.txt Nortel Networks 6 May, 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 13 All provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Distribution of this memo is unlimited. 32 Copyright Notice 34 Copyright (C) The Internet Society (2001). All Rights Reserved. 36 1. Abstract 38 The resource reservation protocol [RSVP] is an end-to-end signaling 39 protocol and it can be a useful mechanism to carry the upstream node 40 or network capabilities/willingness to the downstream network/nodes. 42 This draft proposes a capability negotiation object, CAP object, in 43 the RSVP PATH message that can be used to convey end host/upstream 44 node capabilities to the downstream network/nodes. 46 2. Introduction 48 In today's heterogeneous networking environment, it is important for 49 each network node to have a knowledge of its upstream nodes' 50 capabilities before it can perform any actions to support the QoS 51 requirements of the flows from upstream nodes. The current standards 53 draft-ietf-issll-rsvp-cap-03.txt May, 2001 55 do not provide any way for the end host or upstream network nodes to 56 specify their capabilities to the downstream nodes. Without this 57 capability, network operators are forced to statically configure the 58 behavior of downstream nodes. 60 The resource reservation protocol [RSVP] is an end-to-end signaling 61 protocol that has already been proposed in different scenarios to 62 support end-to-end QoS [INTDIFF]. It can be a useful signaling 63 mechanism to carry upstream node capabilities or willingness to 64 perform certain functions to the downstream nodes. 66 This draft proposes a capability negotiation object, The RSVP CAP 67 object, in the RSVP PATH message that can be used to convey end 68 host/upstream node capabilities/willingness to the downstream 69 network. This is a generic object that can be used to carry any 70 meaningful capability information in the RSVP PATH message. 72 3. Conventions used in this document 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC-2119]. 78 4. Format of CAP Object 80 The CAP object has the following format: 82 0 | 1 | 2 | 3 83 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 84 | Length | C-Num (TBD) | C-Type=1 | 85 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 86 | CAP field | 87 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 The CAP field MUST be defined as a multiple of 32 bits within the 90 object. Each capability MUST be defined using one or more bits within 91 the CAP field. The associated processing rules specific to each 92 capability MUST be explained in a separate section within this 93 document. No limitation is imposed on the number of bits in the CAP 94 field for the capability representation. Any unused bits in the CAP 95 field (i.e. bits that are not assigned to capabilities defined by 96 this document) SHOULD be set to zero by upstream originators of the 97 CAP object and MUST be ignored by downstream receivers. 99 5. Capability Definition and Assignment 101 This section captures the definition of required capabilities to be 102 carried by the capability negotiation (CAP) object in the RSVP PATH 103 message. Each subsection is targeted to define one capability, the 104 definition of necessary bit assignments and an explanation of the 105 processing rules for each capability. 107 draft-ietf-issll-rsvp-cap-03.txt May, 2001 109 Current bit assignments within the CAP field are defined as follows: 111 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 112 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | MBZ |D| 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 0x01 = D_MARK (DS Marking Capability) 118 MBZ = not used; must be zero. 120 5.1 The DS Marking Capability 122 5.1.1 Description 124 The DCLASS object is proposed in [DCLASS] to represent and carry the 125 Differentiated Services Code Point (DSCP) to be used by an upstream 126 node in an Intserv/Diffserv network [INTDIFF]. A network element in 127 the DS network determines the value for DSCP which is carried as a 128 DCLASS object in RSVP RESV message to the sender host or upstream 129 node. The amount of traffic processing at the downstream network 130 node depends on whether or not an upstream node marks the bearer 131 packets with the DSCP. An advance knowledge of the upstream node's 132 marking capability would allow intelligent decisions to be made at 133 the downstream nodes in terms of determining the necessary bearer 134 traffic treatment rules to be installed at the network node. 136 The RSVP capability negotiation object SHOULD be used to carry the 137 upstream node's marking capability to the downstream nodes in the DS 138 network. A detailed explanation of how the DS marking capability 139 negotiation helps determining the differentiated services packet 140 treatment rules should be captured in a separate explanatory draft. 142 5.1.2 Field Values 144 The D_MARK bit in the CAP field MUST be used to indicate the DiffServ 145 marking capability/willingness of the upstream nodes as follows. 147 If D_MARK bit is set to 0, the sender host/upstream node 148 is not able or not willing to mark packets 150 If D_MARK bit is set to 1, the sender host/upstream node is 151 able and willing to mark packets. 153 5.1.3 Message Processing Rules 155 5.1.3.1 PATH Message Generation (Upstream Node) 157 An RSVP PATH message is created by an end host or modified by an 158 RSVP-aware router as specified in [RSVP] with the following 159 modifications. 161 1. A capability (CAP) object is created and the D_MARK bit in the 162 CAP field is set to indicate the marking capability or 163 willingness for packet marking of the network node. 165 draft-ietf-issll-rsvp-cap-03.txt May, 2001 167 D_MARK MUST be set to 1 if the network node is willing and 168 capable of packet marking. 170 D_MARK MUST be set to 0 if the network node either is not 171 capable or it is not willing to mark the packets for the 172 requested flow. 174 2. The CAP Object is inserted in the RSVP message in the 175 appropriate place. 177 5.1.3.2 PATH Message Reception (Downstream Router) 179 RSVP PATH message is processed as specified in [RSVP] with following 180 modifications at the downstream RSVP-enabled router in a DS domain. 182 1. The router MUST record the status of the D_MARK bit as part of 183 the micro-flow PATH state. If a CAP object is not included in 184 the PATH message, the router MUST assume the D_MARK value is 185 zero. 187 2. The router MUST set the D_MARK bit in the CAP object to reflect 188 its own marking capability for the downstream nodes. 190 5.1.3.3 RESV Message Reception (Downstream Router) 192 RSVP RESV message is processed as specified in [RSVP] with following 193 modifications at the downstream RSVP-enabled router in a DS domain. 195 1. The router MUST check the recorded PATH state for the 196 micro-flow and install the necessary treatment rules required 197 to handle the traffic in a DS network. 199 2. If the upstream node has specified its packet marking 200 willingness by setting the D_MARK bit, the router MUST install 201 configuration rules required for receiving and forwarding DS 202 marked packets from the upstream node. The router MAY insert a 203 DCLASS object into the RESV message to indicate the DSCP to be 204 used by the upstream node for this micro-flow. 206 3. If the upstream node is not willing or capable of packet 207 marking, the router MUST install the packet classification, 208 marking and packet forwarding rules for the downstream traffic. 210 4. If the router is not aware of the rules, it SHOULD seek the 211 policy rules from the domain policy server. 213 6. IANA Considerations 215 The format of CAP object requires a class number (C-Num) in RSVP 216 message that MUST be supplied through IANA. 218 7. References 220 [INTDIFF], Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., 221 Speer, M., Braden, R., Davie, B., Wroclawski, J., "Integrated 222 Services Operation over Diffserv Networks", RFC 2998, November 2000 224 draft-ietf-issll-rsvp-cap-03.txt May, 2001 226 [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - 227 Functional Specification.", IETF RFC 2205, Sep. 1997. 229 [RFC-2119] S. Bradner, "keywords for use in RFCs to Indicate 230 Requirement Levels", RFC 2119 (BCP), IETF, March 1997. 232 [DCLASS] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, 233 November 2000. 235 8. Acknowledgments 237 Thanks to Yoram Bernet and other ISSLL WG members for providing 238 useful input to make this one happen. Special thanks to Bill Gage for 239 reviewing the draft 241 9. Author's Address 243 Syed, Hamid 244 Nortel Networks 245 100 - Constellation Crescent, 246 Nepean, ON K2G 6J8 247 Phone: (613) 763-6553 248 Email: hmsyed@nortelnetworks.com 250 10. Full Copyright Statement 252 "Copyright (C) The Internet Society (date). All Rights Reserved. 253 This document and translations of it may be copied and furnished to 254 others, and derivative works that comment on or otherwise explain it 255 or assist in its implementation may be prepared, copied, published 256 and distributed, in whole or in part, without restriction of any 257 kind, provided that the above copyright notice and this paragraph 258 are included on all such copies and derivative works. However, this 259 document itself may not be modified in any way, such as by removing 260 the copyright notice or references to the Internet Society or other 261 Internet organizations, except as needed for the purpose of 262 developing Internet standards in which case the procedures for 263 copyrights defined in the Internet Standards process must be 264 followed, or as required to translate it into languages other than 265 English. 267 The limited permissions granted above are perpetual and will not be 268 revoked by the Internet Society or its successors or assigns. 270 This document and the information contained herein is provided on an 271 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 272 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 273 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 274 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 275 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 277 draft-ietf-issll-rsvp-cap-03.txt May, 2001