draft-ietf-issll-rsvp-cap-02.txt   draft-ietf-issll-rsvp-cap-03.txt 
draft-ietf-issll-rsvp-cap-02.txt draft-ietf-issll-rsvp-cap-03.txt
Internet Draft Syed, Hamid Internet Draft Hamid Syed
draft-ietf-issll-rsvp-cap-02.txt Nortel Networks draft-ietf-issll-rsvp-cap-03.txt Nortel Networks
February, 2001 May, 2001
Capability Negotiation: The RSVP CAP Object Capability Negotiation: The RSVP CAP Object
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with
provisions of Section 10 of RFC2026. All provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering
Force (IETF), its areas, and its working groups. Note that other groups Task Force (IETF), its areas, and its working groups. Note that
may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material time. It is inappropriate to use Internet- Drafts as reference
or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
1. Abstract 1. Abstract
The resource reservation protocol [RSVP] is an end-to-end signaling 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 protocol and it can be a useful mechanism to carry the upstream node
network capabilities/willingness to the downstream network/nodes. or network capabilities/willingness to the downstream network/nodes.
This draft proposes a capability negotiation object, CAP object, in the This draft proposes a capability negotiation object, CAP object, in
RSVP PATH message that can be used to convey end host/upstream node the RSVP PATH message that can be used to convey end host/upstream
capabilities to the downstream network/nodes. node capabilities to the downstream network/nodes.
2. Introduction 2. Introduction
In today's heterogenous networking environment, it is important for each In today's heterogeneous networking environment, it is important for
network to have a knowledge of its upstream nodes/network capabilities each network node to have a knowledge of its upstream nodes'
before it can perform any actions to support the QoS requirements of the capabilities before it can perform any actions to support the QoS
requirements of the flows from upstream nodes. The current standards
draft-ietf-issll-rsvp-cap-02.txt February, 2001 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.
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.
The current standards does not provide any way to the end host or
network devices to specify their capabilities to the downstream nodes.
The resource reservation protocol [RSVP] is an end-to-end signaling The resource reservation protocol [RSVP] is an end-to-end signaling
protocol and has already been proposed in different scenarios to support protocol that has already been proposed in different scenarios to
end-to-end QoS [INTDIFF]. It can be a useful signaling mechanism to support end-to-end QoS [INTDIFF]. It can be a useful signaling
carry the upstream node/network capabilities or willingness to the mechanism to carry upstream node capabilities or willingness to
downstream network or nodes. perform certain functions to the downstream nodes.
This draft proposes a capability negotiation object, The RSVP CAP This draft proposes a capability negotiation object, The RSVP CAP
object, in the RSVP PATH message that can be used to convey end object, in the RSVP PATH message that can be used to convey end
host/upstream node capabilities/willingness to the downstream network. host/upstream node capabilities/willingness to the downstream
This is a generic object that can be used to carry any meaningful network. This is a generic object that can be used to carry any
capability information in the RSVP PATH message. meaningful capability information in the RSVP PATH message.
3. Conventions used in this document 3. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-2119]. document are to be interpreted as described in [RFC-2119].
4. Format of CAP Object 4. Format of CAP Object
The CAP object has the following format: The CAP object has the following format:
0 | 1 | 2 | 3 0 | 1 | 2 | 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | C-Num (TBD) | C-Type=1 | | Length | C-Num (TBD) | C-Type=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CAP field | | CAP field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CAP field is defined with full 32 bits in the object. Each bit in The CAP field MUST be defined as a multiple of 32 bits within the
the field can be used for one specific capability representation. 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. Message Processing Rules 5. Capability Definition and Assignment
5.1 Message Generation (RSVP Host) 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.
An RSVP PATH message is created as specified in [RSVP] with following draft-ietf-issll-rsvp-cap-03.txt May, 2001
modifications
1. A capability (CAP) object is created and the CAP field is set to Current bit assignments within the CAP field are defined as follows:
indicate the various capabilities of the end host. Only those bits
are set that represent a specific capability of the end host. The
bits that are unused MUST be left reset
draft-ietf-issll-rsvp-cap-02.txt February, 2001 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An example; 0x01 = D_MARK (DS Marking Capability)
CAP field: MBZ = not used; must be zero.
0x0X: A_Cap 5.1 The DS Marking Capability
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 the capability
Note: A_Cap represents a single capability/willingness of the end 5.1.1 Description
host/upstream network node
2. The CAP Object is inserted in the RSVP message in the appropriate The DCLASS object is proposed in [DCLASS] to represent and carry the
place. 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.
5.2 Message Reception (Downstream Router) 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.
RSVP PATH message is processed at the downstream router as specified in 5.1.2 Field Values
[RSVP] with following modifications.
1. The router records the CAP object as the micro-flow PATH state The D_MARK bit in the CAP field MUST be used to indicate the DiffServ
marking capability/willingness of the upstream nodes as follows.
2. The router modifies the CAP object by setting the CAP field to If D_MARK bit is set to 0, the sender host/upstream node
reflect its own capabilities is not able or not willing to mark packets
5.3 Message Reception (Upstream Router) If D_MARK bit is set to 1, the sender host/upstream node is
able and willing to mark packets.
RSVP RESV message is processed at the upstream router as specified in 5.1.3 Message Processing Rules
[RSVP] with following modifications.
1. The router checks the recorded PATH state for the micro-flow and 5.1.3.1 PATH Message Generation (Upstream Node)
installs any rules required to handle the traffic
2. If the router is not aware of the rules, it SHOULD seek the policy An RSVP PATH message is created by an end host or modified by an
rules from the domain policy server 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 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 6. IANA Considerations
The format of CAP object requires a class number (C-Num) in RSVP The format of CAP object requires a class number (C-Num) in RSVP
message. Moreover, the capabilities defined through the CAP object message that MUST be supplied through IANA.
will be defined in other RFCs and their values will be assigned
through IANA.
7. References 7. References
[INTDIFF], Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., [INTDIFF], Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
Speer, M., Braden, R., Davie, B., Wroclawski, J., "Integrated Services Speer, M., Braden, R., Davie, B., Wroclawski, J., "Integrated
Operation over Diffserv Networks", RFC 2998, November 2000 Services Operation over Diffserv Networks", RFC 2998, November 2000
draft-ietf-issll-rsvp-cap-02.txt February, 2001 draft-ietf-issll-rsvp-cap-03.txt May, 2001
[RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) -
Functional Specification.", IETF RFC 2205, Sep. 1997. Functional Specification.", IETF RFC 2205, Sep. 1997.
[RFC-2119] S. Bradner, "keywords for use in RFCs to Indicate Requirement [RFC-2119] S. Bradner, "keywords for use in RFCs to Indicate
Levels", RFC 2119 (BCP), IETF, March 1997. Requirement Levels", RFC 2119 (BCP), IETF, March 1997.
[DCLASS] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
November 2000.
8. Acknowledgments 8. Acknowledgments
Thanks to Yoram Bernet and other ISSLL WG members for providing useful Thanks to Yoram Bernet and other ISSLL WG members for providing
comments to make this one happen. Special thanks to Bill Gage for useful input to make this one happen. Special thanks to Bill Gage for
reviewing this draft reviewing the draft
9. Author's Address 9. Author's Address
Syed, Hamid Syed, Hamid
Nortel Networks Nortel Networks
100 - Constellation Crescent, 100 - Constellation Crescent,
Nepean, ON K2G 6J8 Nepean, ON K2G 6J8
Phone: (613) 763-6553 Phone: (613) 763-6553
Email: hmsyed@nortelnetworks.com Email: hmsyed@nortelnetworks.com
skipping to change at page 4, line 39 skipping to change at page 5, line 42
"Copyright (C) The Internet Society (date). All Rights Reserved. "Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organisations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
draft-ietf-issll-rsvp-cap-02.txt February, 2001 draft-ietf-issll-rsvp-cap-03.txt May, 2001
 End of changes. 39 change blocks. 
83 lines changed or deleted 156 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/