draft-hamid-issll-hcap-00.txt Internet Draft Syed, Hamid, Draft-hamid-issll-hcap-00.txt Nortel Networks Y. Bernet, Microsoft July, 2000 Host Capability Negotiation: The RSVP HCAP 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 (1998). All Rights Reserved. 1. Abstract The DCLASS object is proposed in [DCLASS] to represent and carry Diffrentiated Services Code Points (DSCPs) within RSVP messages. The principle use of the DCLASS object is to carry DSCP information between a DS network and upstream nodes that may wish to mark packets with DSCP values. A network element in the DS network determines the value for DSCP which is further carried as a DCLASS object in RSVP RESV message to the sender host. There may be situations where the sender host is not capable or may not wish to mark the packets. The network element, currently, does not have any way to determine whether or not an end host should be provided with a DCLASS in a RSVP RESV message. This is one example where the network element needs to know the host capabilities before making a policy decision. There could be other situations where an advance knowledge of the host capabilities may help the network to provide better policy decisions to the end host. Currently, there is no way for the host to specify its capabilities in a RSVP PATH message. Hamid Expires January, 2001 [Page 1] draft-hamid-issll-hcap-00.txt July, 2000 This draft proposes the HCAP object in the RSVP PATH message that can be used to convey end host's capabilities to the network. It also defines one field in the HCAP object to convey the host capability/willingness for accepting a DCLASS object from the network and marking at the host. 2. Introduction The mechanics of using RSVP [RSVP] signalling and the DCLASS object for requesting and applying the QoS in a differentiated services [DS] network is described fully in [INTDIFF]. It assumes an architecture with RSVP senders and receivers and a differentiated services network somewhere between the sender and the receiver. At least one RSVP aware network element resides in the diff-serv network. This network element interacts with RSVP messages arriving from outside the DS network. If the network element determines that the request represented by the PATH and RESV messages is admissible to the diff-serv network, a desision is made to mark the arriving data packets for this traffic using MF classification, or to request upstream marking of packets with the appropriate DSCPs. If the network element decides the packets to be marked at the sender host for the data traffic, it adds a DCLASS object in the RSVP RESV message to the host. The use and format of DCLASS object is fully specified in [DCLASS]. The decision where the data packets should be marked can be made at the network element through negotiation with the sender host. Section 3 of this draft describes the use of the HCAP object in RSVP PATH message to perform such negotiation between the sender host and the DS netwrok element. 3. Host Capability Negotiation The advance knowledge of the end host's capabilities may help the network to make policy decisions on requests from the hosts. These capabilities can be signaled to the network in the RSVP PATH message. This requires an additional object to be added in the RSVP PATH message. This object called 'HCAP' object can be used as a mechanism for conveying host's capabilities or willingness in RSVP messages. As an example, we will focus on the host marking capability in this document and define a single byte for host marking information to be carried in the HCAP object of RSVP PATH message but the HCAP object is a generic object that can be used to carry any other host capabilities information. The end hosts can be classiffied in two categories: Those capable of marking upstream packets and decide to do so. The other category of hosts either do not have the capability to mark packets or they decide not to mark packets. In either case, the network element need to know the host packet marking capability/willingness. This information can help the network element to decide whether or not a DCLASS object must be added in a RSVP message for the flow. One way to perform this negotiation is to convey the host capability/willingness to the network using the RSVP PATH message. We give examples here to explain the scenarios. The sender host that is ready to mark the upstream traffic based on the DCLASS provided by the network element adds the HCAP object into the PATH message. On receiving the RSVP message, the network element Hamid Expires January, 2001 [Page 2] draft-hamid-issll-hcap-00.txt July, 2000 records the host marking as the PATH state. When the RESV message comes back to the network element, the network element performs the necessary admission control. If the network element determines that the request represented by the PATH and RESV messages is admissible to the diff-serv netwrok, it adds a DCLASS object after consulting the recorded state. It should be noted that how the packets will be marked is a decision goverened by the network policies. The network policy may or may not trust the host marking. Hence, even the network may have supplied the DCLASS object to the end host on request (via HCAP) it may overwrite the marking based on the domain policy. 4. Format of HCAP Object The HCAP object has the following format: 0 | 1 | 2 | 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | C-Num (226) | C-Type=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CAP byte | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CAP byte: 0x01: H_MARK The host marking capability/willingness identifier. If H_MARK bit is reset, the sender host is not able to mark packets If H_MARK bit is set, the sender host is able/willing to mark packets Note: H_MARK is a bit in the CAP (capbility) byte. 5. Deployment Scenarios There are a number of hosts out which do have the marking capability and they even do not depend on a DCLASS object from the network. The marking is based on a default mapping from requested service type to the DSCP. In this section, we will briefly address the deployment scenarios for such hosts which do mark without signaling network about their marking capability. If a host does not provide an HCAP object, then the network edge must be provisioned (or be given policies) as to how it should react. This may be one of: - send a DCLASS object. - install a filter to mark the appropriate flow at the edge. - do both. The problem here is ensuring that the mapping configured in the host matches the allowed mappings configured in the edge router. If there is a mismatch, the edge router will, at best, remark the packets to match its policies (possibly resulting in a treatment different from that expected by the host) or, at worst, mark packets as non-conforming and discard them. The policy may be for a specific host address, for a specific interface, for a specific edge router or for the entire domain. The bottom line is that manual provisioning would be required in the interim until hosts support the HCAP option. Once hosts support the HCAP option, manual provisioning would no longer be required. Hamid Expires January, 2001 [Page 3] draft-hamid-issll-hcap-00.txt July, 2000 6. 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", Internet Draft, June 1999 [DS] An Architecture for Differentiated Services. S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, RFC 2475, December 1998. [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - Functional Specification.", IETF RFC 2205, Sep. 1997. [DCLASS] Bernet, Y., "Format of the RSVP DCLASS Object", IETF , Oct., 1999. 6. Acknowledgments Thanks to Bill Gage, Goran Janevski, Gary Kenward, kwok chan and Louis- Nicolas Hamer for reviewing this draft and providing useful input. 7. Author's Address Syed, Hamid Nortel Networks 100 - Constellation Crescent, Nepean, ON K2G 6J8 Phone: (613) 763-6553 Email: hmsyed@nortelnetworks.com Yoram Bernet Microsoft One Microsoft Way Redmond, WA 98052 Phone: (425) 936-9568 EMail: yoramb@microsoft.com 8. 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 organisations, 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 January, 2001 [Page 4] draft-hamid-issll-hcap-00.txt July, 2000