Internet DRAFT - draft-hamid-issll-hcap
draft-hamid-issll-hcap
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 <draft-ietf-isll-dclass-01.txt>, 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
