draft-ietf-issll-rsvp-cap-02.txt					    draft-ietf-issll-rsvp-cap-03.txt

Internet Draft                                                 Syed,                                                    Hamid
draft-ietf-issll-rsvp-cap-02.txt Syed
draft-ietf-issll-rsvp-cap-03.txt			     Nortel Networks

                                			    February,

                                			           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
   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.

   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 heterogenous heterogeneous networking environment, it is important for
   each network node to have a knowledge of its upstream nodes/network nodes'
   capabilities before it can perform any actions to support the QoS
   requirements of the

   draft-ietf-issll-rsvp-cap-02.txt	                     February, 2001 flows from upstream networks. Such an advance information would help the
   network operator to configure the network according to the expected
   nature of traffic that the network devices have to process and route. nodes. The current standards does

   draft-ietf-issll-rsvp-cap-03.txt	                          May, 2001

   do not provide any way to for the end host or upstream network devices 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 and that has already been proposed in different scenarios to
   support end-to-end QoS [INTDIFF]. It can be a useful signaling
   mechanism to carry the upstream node/network node capabilities or willingness to
   perform certain functions to the downstream network or 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 is MUST be defined with full as a multiple of 32 bits in within the
   object. Each bit in
   the field can capability MUST be used for defined using one or more bits within
   the CAP field. The associated processing rules specific to each
   capability representation.

5. Message Processing Rules

5.1 Message Generation (RSVP Host)

   An RSVP PATH message is created as specified MUST be explained in [RSVP] with following
   modifications

     1. A capability (CAP) object a separate section within this
   document. No limitation is created and imposed on the number of bits in the CAP
   field is set to
        indicate for the various capabilities of capability representation. Any unused bits in the end host. Only those CAP
   field (i.e. bits that are not assigned to capabilities defined by
   this document) SHOULD be set that represent a specific capability to zero by upstream originators of the end host. The
        bits that are unused
   CAP object and MUST be left reset

   draft-ietf-issll-rsvp-cap-02.txt	                     February, 2001

        An example;
          CAP field:

	  0x0X: A_Cap
		The host/node capability/willingness identifier.
		If A_Cap bit is reset, the sender host/upstream node
                does not have the capability
		If A_Cap bit is set, the sender host/upstream node does
                have ignored by downstream receivers.

5. Capability Definition and Assignment

   This section captures the capability

          Note: A_Cap represents a single capability/willingness definition of required capabilities to be
   carried by the end
                host/upstream network node

     2. The CAP Object is inserted in the RSVP message capability negotiation (CAP) object in the appropriate
        place.

5.2 Message Reception (Downstream Router) RSVP PATH message
   message. Each subsection is processed at the downstream router as specified in
   [RSVP] with following modifications.

     1. The router records targeted to define one capability, the CAP object as
   definition of necessary bit assignments and an explanation of the micro-flow PATH state

     2. The router modifies
   processing rules for each capability.

   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 setting 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.

   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 capabilities

5.3 marking capability for the downstream nodes.

5.1.3.3 RESV Message Reception (Upstream (Downstream Router)

   RSVP RESV message is processed at the upstream router as specified in [RSVP] with following modifications.
   modifications at the downstream RSVP-enabled router in a DS domain.

     1. The router checks MUST check the recorded PATH state for the
         micro-flow and
        installs any 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 server.

6. IANA Considerations

   The format of CAP object requires a class number (C-Num) in RSVP
   message. Moreover, the capabilities defined through the CAP object
   will be defined in other RFCs and their values will
   message that MUST be assigned 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

   draft-ietf-issll-rsvp-cap-02.txt	                     February,

   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
   comments input to make this one happen. Special thanks to Bill Gage for
   reviewing this 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 organisations, 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.

   draft-ietf-issll-rsvp-cap-02.txt	                   February,

   draft-ietf-issll-rsvp-cap-03.txt	                          May, 2001