draft-ietf-issll-rsvp-cap-03.txt Internet Draft Hamid Syed draft-ietf-issll-rsvp-cap-03.txt Nortel Networks May, 2001 Capability Negotiation: The RSVP CAP Object Status of this Memo This document is an Internet-Draft and is in full conformance with All provisions of Section 10 of RFC2026. 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. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. 1. Abstract The resource reservation protocol [RSVP] is an end-to-end signaling protocol and it can be a useful mechanism to carry the upstream node or network capabilities/willingness to the downstream network/nodes. This draft proposes a capability negotiation object, CAP object, in the RSVP PATH message that can be used to convey end host/upstream node capabilities to the downstream network/nodes. 2. Introduction In today's heterogeneous networking environment, it is important for each network node to have a knowledge of its upstream nodes' capabilities before it can perform any actions to support the QoS requirements of the flows from upstream nodes. The current standards Hamid Expires November, 2001 [Page 1] draft-ietf-issll-rsvp-cap-03.txt May, 2001 do not provide any way for the end host or upstream network nodes to specify their capabilities to the downstream nodes. Without this capability, network operators are forced to statically configure the behavior of downstream nodes. The resource reservation protocol [RSVP] is an end-to-end signaling protocol that has already been proposed in different scenarios to support end-to-end QoS [INTDIFF]. It can be a useful signaling mechanism to carry upstream node capabilities or willingness to perform certain functions to the downstream nodes. This draft proposes a capability negotiation object, The RSVP CAP object, in the RSVP PATH message that can be used to convey end host/upstream node capabilities/willingness to the downstream network. This is a generic object that can be used to carry any meaningful capability information in the RSVP PATH message. 3. 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]. 4. Format of CAP Object The CAP object has the following format: 0 | 1 | 2 | 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | C-Num (TBD) | C-Type=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CAP field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The CAP field MUST be defined as a multiple of 32 bits within the object. Each capability MUST be defined using one or more bits within the CAP field. The associated processing rules specific to each capability MUST be explained in a separate section within this document. No limitation is imposed on the number of bits in the CAP field for the capability representation. Any unused bits in the CAP field (i.e. bits that are not assigned to capabilities defined by this document) SHOULD be set to zero by upstream originators of the CAP object and MUST be ignored by downstream receivers. 5. Capability Definition and Assignment This section captures the definition of required capabilities to be carried by the capability negotiation (CAP) object in the RSVP PATH message. Each subsection is targeted to define one capability, the definition of necessary bit assignments and an explanation of the processing rules for each capability. Hamid Expires November, 2001 [Page 2] draft-ietf-issll-rsvp-cap-03.txt May, 2001 Current bit assignments within the CAP field are defined as follows: 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 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ |D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0x01 = D_MARK (DS Marking Capability) MBZ = not used; must be zero. 5.1 The DS Marking Capability 5.1.1 Description The DCLASS object is proposed in [DCLASS] to represent and carry the Differentiated Services Code Point (DSCP) to be used by an upstream node in an Intserv/Diffserv network [INTDIFF]. A network element in the DS network determines the value for DSCP which is carried as a DCLASS object in RSVP RESV message to the sender host or upstream node. The amount of traffic processing at the downstream network node depends on whether or not an upstream node marks the bearer packets with the DSCP. An advance knowledge of the upstream node's marking capability would allow intelligent decisions to be made at the downstream nodes in terms of determining the necessary bearer traffic treatment rules to be installed at the network node. The RSVP capability negotiation object SHOULD be used to carry the upstream node's marking capability to the downstream nodes in the DS network. A detailed explanation of how the DS marking capability negotiation helps determining the differentiated services packet treatment rules should be captured in a separate explanatory draft. 5.1.2 Field Values The D_MARK bit in the CAP field MUST be used to indicate the DiffServ marking capability/willingness of the upstream nodes as follows. If D_MARK bit is set to 0, the sender host/upstream node is not able or not willing to mark packets If D_MARK bit is set to 1, the sender host/upstream node is able and willing to mark packets. 5.1.3 Message Processing Rules 5.1.3.1 PATH Message Generation (Upstream Node) An RSVP PATH message is created by an end host or modified by an RSVP-aware router as specified in [RSVP] with the following modifications. 1. A capability (CAP) object is created and the D_MARK bit in the CAP field is set to indicate the marking capability or willingness for packet marking of the network node. Hamid Expires November, 2001 [Page 3] draft-ietf-issll-rsvp-cap-03.txt May, 2001 D_MARK MUST be set to 1 if the network node is willing and capable of packet marking. D_MARK MUST be set to 0 if the network node either is not capable or it is not willing to mark the packets for the requested flow. 2. The CAP Object is inserted in the RSVP message in the appropriate place. 5.1.3.2 PATH Message Reception (Downstream Router) RSVP PATH message is processed as specified in [RSVP] with following modifications at the downstream RSVP-enabled router in a DS domain. 1. The router MUST record the status of the D_MARK bit as part of the micro-flow PATH state. If a CAP object is not included in the PATH message, the router MUST assume the D_MARK value is zero. 2. The router MUST set the D_MARK bit in the CAP object to reflect its own marking capability for the downstream nodes. 5.1.3.3 RESV Message Reception (Downstream Router) RSVP RESV message is processed as specified in [RSVP] with following modifications at the downstream RSVP-enabled router in a DS domain. 1. The router MUST check the recorded PATH state for the micro-flow and install the necessary treatment rules required to handle the traffic in a DS network. 2. If the upstream node has specified its packet marking willingness by setting the D_MARK bit, the router MUST install configuration rules required for receiving and forwarding DS marked packets from the upstream node. The router MAY insert a DCLASS object into the RESV message to indicate the DSCP to be used by the upstream node for this micro-flow. 3. If the upstream node is not willing or capable of packet marking, the router MUST install the packet classification, marking and packet forwarding rules for the downstream traffic. 4. If the router is not aware of the rules, it SHOULD seek the policy rules from the domain policy server. 6. IANA Considerations The format of CAP object requires a class number (C-Num) in RSVP message that MUST be supplied through IANA. 7. References [INTDIFF], Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J., "Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000 Hamid Expires November, 2001 [Page 4] draft-ietf-issll-rsvp-cap-03.txt May, 2001 [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - Functional Specification.", IETF RFC 2205, Sep. 1997. [RFC-2119] S. Bradner, "keywords for use in RFCs to Indicate Requirement Levels", RFC 2119 (BCP), IETF, March 1997. [DCLASS] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000. 8. Acknowledgments Thanks to Yoram Bernet and other ISSLL WG members for providing useful input to make this one happen. Special thanks to Bill Gage for reviewing the draft 9. Author's Address Syed, Hamid Nortel Networks 100 - Constellation Crescent, Nepean, ON K2G 6J8 Phone: (613) 763-6553 Email: hmsyed@nortelnetworks.com 10. Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Hamid Expires November, 2001 [Page 5] draft-ietf-issll-rsvp-cap-03.txt May, 2001