Internet Draft
Internet Draft Nitsan Elfassy
File: draft-nitsan-cops-rsvp-proxy-00.txt Dinesh Dutt
Expiration Date: April 2000 Cisco Systems
October 1999
COPS Extensions for RSVP Receiver Proxy Support
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.
Abstract
This document proposes an extension to [COPS-RSVP] and [COPS]
documents needed to support RSVP Receiver Proxy [RSVP-PROXY] and the
Null Service Type [NULL-SERV].
Elfassy, Dutt [Page 1]
COPS extensions for RSVP Receiver Proxy support June 1999
Table of contents
1. Introduction ...................................................3
2. Functionality Required To Support RSVP Receiver Proxy...........3
2.1. Device Capabilities..........................................3
2.2. Role Combinations............................................4
2.3. Additional Decision Information..............................4
2.4. Path forwarding policy.......................................5
3. COPS Objects Used To Communicate The Additional Information.....5
4. Definitions of the New Objects..................................5
4.1. PEP Capabilities.............................................5
4.2. Role Combination.............................................7
5. Communicating Additional Decisions In DEC Message...............9
5.1. Policy Information to be included in the returned Resv.......9
6. Illustrative Example............................................9
7. Compatibility With Existing RSVP COPS Implementations..........10
7. References ....................................................11
8. Intellectual Property Considerations ..........................11
9. Author Information ............................................11
10. Full Copyright Statement .....................................12
Terminology
o RSVP: Resource ReSerVation Protocol.
o COPS: Common Open Policy Service.
o DSCP: DiffServ Code Point.
o Metering: the process of measuring the temporal properties (e.g.,
rate) of a traffic stream selected by a classifier. The
instantaneous state of this process may be used to affect the
operation of a marker, shaper, or dropper, and/or may be used for
accounting and measurement purposes.
o Policing: the process of discarding packets (by a dropper) within
a traffic stream in accordance with the state of a corresponding
meter enforcing a traffic profile.
o Traffic conditioning: control functions performed to enforce
rules specified in a TCA, including metering, marking, shaping,
and policing.
o Microflow: A single instance of an application-to-application
flow of packets which is identified by source address, source
port, destination address, destination port and protocol id.
Elfassy, Dutt [Page 2]
COPS extensions for RSVP Receiver Proxy support June 1999
1. Introduction
RSVP Receiver Proxy [RSVP-PROXY] defines an extension to the RSVP
message processing mainly designed to operate in conjunction with the
Null Service Type [NULL-SERV]. Null Service type is a new service type
proposed for use with RSVP to support applications which cannot
quantify their resource requirements. The determination of resource
requirements for these applications is left to the discretion of the
network administrator.
The extension proposes that an intermediate router/switch receiving
an RSVP Path message terminate the Path message instead of forwarding
it all the way to the end destination. This router generates a proxy
Resv message and sends it upstream. This originated Resv follows the
same rules as any Resv message.
Existing COPS support for RSVP does not contain mechanisms to support
this new functionality proposed by RSVP Receiver Proxy. This document
proposes extensions to enable the use of COPS with RSVP Receiver
Proxy.
2. Functionality Required to support RSVP Receiver Proxy
This section describes the nature of the additional information that
needs to be exchanged between the PDP and the PEP to support RSVP
Receiver Proxy and the Null Service Type.
2.1. Device capabilities
RSVP requires that network nodes be capable of reserving resources to
support bandwidth allocation. These devices must also be capable of
enforcing the traffic to the specified bandwidth - specified via TSPEC
- such that they do not use more than their share of resources.
Traffic exceeding the specified TSPEC is dropped. The bandwidth
allocation and enforcement needs to be supported per each outgoing
interface. For example, a multicast flow going out two separate
interfaces, could have different resource requirements.
There are other capabilities such as marking that a device may or may
not support. In order for the PDP to inform a PEP to enforce a
decision, it would be useful for the PDP to know the capabilities of
the PEP.
Elfassy, Dutt [Page 3]
COPS extensions for RSVP Receiver Proxy support June 1999
The device capabilities of interest follow.
2.1.1. Support for RSVP Receiver Proxy
Current IntServ capable nodes do not support the additional
functionality specified by RSVP Receiver Proxy. Before the PDP can
send a decision which uses this functionality, it is necessary for the
PDP to know if the device supports it.
2.1.2. Support for Marking
This capability defines whether a node can mark packets and also the
manner in which it can mark, using DSCP or only IP Precedence.
2.1.3. Support for Resource Reservation and Enforcement
This defines the ability of a node to reserve resources and enforce
it. It also specifies whether the node can provide this functionality
per each outgoing interface or only per input interface. The
enforcement is accomplished using a meter and a policer.
2.2. Role Combinations
With the Null service type, the QoS assigned to a flow is upto the
discretion of the network administrator. The network administrator may
decide to use DiffServ to assign a QoS to the flow. The drafts related
to provisioning of QoS policy in a DiffServ environment ([COPS-PR],
[PIB]) specify that each interface has a set of roles associated with
it. A role is simply a string that is associated with an interface and
is used to group together interfaces that need to share a QoS
policy. Each interface can have many roles. A "role combination" is
an unordered set of roles.
Specifying the role combination associated with the ingress and egress
interface associated with the Path message provides for consistency
and compatbility with DiffServ policy.
2.3. Additional Decision Information
According to the new RSVP Receiver Proxy behavior, the RSVP Path
message is not forwarded further. The node terminating the Path will
instead originate the corresponding Resv message. This decision needs
to be communicated to the PEP for a Path message.
It is the PDP that decides what policy objects need to be in the Resv
message. The PDP needs to communicate these objects to the PEP.
Elfassy, Dutt [Page 4]
COPS extensions for RSVP Receiver Proxy support June 1999
3. COPS Objects Used To Communicate The Additional Information
The proposed extension defines new objects that are contained in the
existing COPS objects. The objects used are:
o Stateless Decision object
o Client SI Named object
o Policy Data object [POL-EXT]
o DCLASS object [DCLASS]
Further explanation is provided in the following sections.
4. Definitions of the New Objects
4.1. PEP Capabilities
This section defines the objects used to communicate the RSVP-related
device capabilities.
The container object used to communicate the Client capabilities is a
Policy Data Object. The capability information is implemented as
policy elements [POL-EXT].
The definitions of the new policy elements follow.
4.1.1 RSVP_PROXY_SUPPORT policy element
This policy element indicates if the PEP supports RSVP Receiver
Proxy. This policy element MAY be sent in the Client Open message (in
a POLICY DATA object that itself is encapsulated in COPS ClientSI
Named object).
If the Client does not add the RSVP_PROXY_SUPPORT in the Client Open
message, the PDP assumes that the PEP does not support RSVP Receiver
Proxy.
+-------------+-------------+-------------+--------------------+
| Length = 8 | P-Type = RSVP_PROXY_SUPPORT |
+------+------+-------------+-------------+--------------------+
| Flags | /// Reserved /// |
+------+------+-------------+-------------+--------------------+
Length: 16 bits
The overall length of the policy element, in octets. Equals 8.
P-Type: 16 bits
RSVP_PROXY_SUPPORT policy element, as registered with IANA.
Elfassy, Dutt [Page 5]
COPS extensions for RSVP Receiver Proxy support June 1999
flags: 16 bits
The currently supported flags are:
0x00 - RSVP Receiver Proxy not supported
0x01 - RSVP Receiver Proxy supported
4.1.2. POLICING_SUPPORT policy element definition
This policy element indicates if the device supports metering and
policing.
This policy element MAY be sent in REQ message or in the Client Open
message. In case of the REQ message, the object is carried in a Named
ClientSI Object following the Signaled ClientSI object that carries
the RSVP message objects.
If the Client Open or REQ message does not contain the
POLICING_SUPPORT policy element, the PDP assumes the PEP supports both
input and output policing (the PEP could be running older code which
does not define this object).
+-------------+-------------+-------------+--------------------+
| Length = 8 | P-Type = POLICING_SUPPORT |
+------+------+-------------+-------------+--------------------+
| Flags | /// reserved //// |
+------+------+-------------+-------------+--------------------+
Length: 16 bits
The overall length of the policy element, in octets. Equals 8.
P-Type: 16 bits
POLICING_SUPPORT policy element, as registered with IANA.
flags: 16 bits
The currently supported flags are:
0x0 - No policing supported
0x1 - Only input-based policing
0x2 - Only output-based policing
0x3 - Both input and output-based policing
4.1.3. MARKING_SUPPORT policy element
This policy element indicates the marking capabilities of the PEP.
Marking is defined as setting the ToS byte of a packet based on some
defined rules.
This policy element MAY be sent in COPS REQ message or in the Client
Open message. When the Client-Open or REQ message does not contain
this element the PDP assumes the PEP has no marking capabilities.
Elfassy, Dutt [Page 6]
COPS extensions for RSVP Receiver Proxy support June 1999
+-------------+-------------+-------------+--------------------+
| Length = 8 | P-Type = MARKING_SUPPORT |
+------+------+-------------+-------------+--------------------+
| Flags | /// reserved //// |
+------+------+-------------+-------------+--------------------+
Length: 16 bits
The overall length of the policy element, in octets. Equals 8.
P-Type: 16 bits
MARKING_SUPPORT policy element, as registered with IANA.
flags: 16 bits
The currently supported flags are:
0x0 - No Marking supported
0x1 - Only IP Precedence Marking
0x2 - DSCP based Marking
4.2. Role-Combination
As specified in section 2.2, it may also be useful add the
role-combinations assigned to the ingress and egress interfaces as
part of the information communicated to the PDP. Two new objects have
been defined to carry this information.
The role-combination objects MAY be present in the REQ Message. The
Named Client Specific Information Object (ClientSI Named) which
carries the POLICY-DATA object also carries the role combination
objects.
There are two role-combination objects defined, IN_ROLE_COMB and
OUT_ROLE_COMB.
4.2.1. In Interface Role-Combination policy element
The format of In Interface Role Combination policy element is as
follows:
+-------------+-------------+-------------+-------------+
| Length (variable) | P-Type = IN_ROLE_COMB |
+------+------+-------------+-------------+-------------+
| IN Role Combination |
+------+------+-------------+-------------+-------------+
| ......... |
+------+------+-------------+-------------+-------------+
Elfassy, Dutt [Page 7]
COPS extensions for RSVP Receiver Proxy support June 1999
Length: 16 bits
This is the overall length of the policy element, in octets.
If the length in octets does not fall on a 32-bit word boundary,
padding must be added to the end of the object so that it is
aligned to the next 32-bit boundary.
P-Type: 16 bits
IN_ROLE_COMB policy element, as registered with IANA.
IN Role Combination: Role Combination string.
Role Combination is a display string as defined in [PIB].
IN_ROLE_COMB policy element MAY appear only once in the Policy Data
object. If this element is absent in the REQ message, the PDP can
assume a default IN Role-Combination. It is up to the PDP to figure
out that default.
4.2.2. Out Interface Role Combination
The format of Out Interface Role Combination policy element is as
follows:
+-------------+-------------+-------------+-------------+
| Length (variable) | P-Type = OUT_ROLE_COMB |
+------+------+-------------+-------------+-------------+
| OUT Role Combination |
+------+------+-------------+-------------+-------------+
| ....... |
+------+------+-------------+-------------+-------------+
Length: 16 bits
This is the overall length of the policy element, in octets.
If the length in octets does not fall on a 32-bit word boundary,
padding must be added to the end of the object so that it is
aligned to the next 32-bit boundary.
P-Type: 16 bits
OUT_ROLE_COMB policy element, as registered with IANA.
OUT Role Combination: Role Combination string.
OUT_ROLE_COMB policy element MAY appear only once in the Policy
Data object. In the absence of this element in the REQ message,
the PDP may assume a default OUT Role-Combination, which makes
it a policy decision.
Elfassy, Dutt [Page 8]
COPS extensions for RSVP Receiver Proxy support June 1999
5. Communicating Additional Decisions In DEC Message
The current COPS for RSVP draft [COPS-RSVP] allows for the possibility
of multiple context groups (section 3.6). We extend the use of
multiple context groups to include the decision to originate a proxy
Resv message.
When the PDP gets a Path IN context REQ message, it returns back a DEC
message with a context group for the Path IN context, as specified in
[COPS-RSVP]. In order to instruct the PEP to originate Resv, the PDP
will add another context group for Resv OUT context.
Appearance of Resv OUT Decision context group in a DEC message sent
for Path IN context, MUST be interpreted by the PEP as an instruction
to install Resv state and originate a Resv upstream back to the
previous hop defined in the Path message.
When Path IN context is "bundled" in the same REQ message with other
contexts, the following rule applies:
The DEC message sent for this REQ MAY include a single Resv OUT
Context Group and the PEP MUST take it as an extension to the
Path IN Context Group.
5.1. Policy Information to be included in the returned Resv
The DEC message described in the previous section will include all the
information to be sent back to the Sender inside the Resv. The
container object for this information is the Replacement Decision
object under the Resv OUT context group added to the DEC message.
Among the objects that may populate the Replacement Decision object
are Policy Data Object(s), DCLASS object and TSPEC object.
6. Illustrative Example
(Modified example from "COPS usage for RSVP" IETF draft). This
section illustrates the steps in using COPS for controlling a
unicast RSVP Receiver Proxy flow.
h1 ----> R1
|
|
h1 <-----+
Figure 1: Single PEP View
Assume that the PEP, R1 has two interfaces (if1, if2). Sender h1
sends to some receiver r1. R1 is a PEP along the path which supports
RSVP Receiver Proxy. Let if1 be the interface on which h1 is
connected to R1 and if2 be the outgoing interface associated with
the receiver r1.
Elfassy, Dutt [Page 9]
COPS extensions for RSVP Receiver Proxy support June 1999
A. A Path message arrives from h1:
PEP --> PDP REQ :=
PDP --> PEP DEC :=
The decision message instructs the PEP to accept the Path message
in, originate a Resv and to not forward the Path further.
7. Compatibility With Existing RSVP COPS Implementations
In order to inter-operate with existing RSVP COPS clients, the PDP
must treat a Client-Open received with no capability objects
specified as a device which does not support RSVP Receiver Proxy and
send decisions which match the existing standard [COPS-RSVP]. The
assumption made here is that clients which support the functionality
detailed in this draft will also support the RSVP Receiver Proxy
functionality.
If a PEP supporting RSVP Receiver Proxy talks to an older PDP, the PDP
will ignore the capability objects sent. It will therefore treat all
incoming messages as quantitative service type objects.
8. Security Considerations
This Section is TBD
9. References
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin
S., "Resource Reservation Protocol (RSVP) Version 1
Functional Specification", IETF RFC 2205, Proposed
Standard, September 1997.
[RFC2210] J. Wroclawski, "The Use of RSVP with IETF Integrated
Services," September 1997.
[RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4
Elfassy, Dutt [Page 10]
COPS extensions for RSVP Receiver Proxy support June 1999
[RSVP-PROXY] Gai S., Dutt D., Elfassy N., Bernet Y., RSVP Receiver
Proxy, , October 1999.
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R.,
Sastry, A., "The COPS (Common Open Policy Service)
Protocol", IETF , February
1999.
[COPS-RSVP] Jim Boyle, Ron Cohen, David Durham, Shai Herzog, Raju
Rajan, Arun Sastry, "COPS usage for RSVP," , June 14, 1999
[POL-EXT] Shai Herzog, "RSVP Extensions for Policy Control,"
Internet Draft., < draft-ietf-rap-rsvp-ext-06.txt>, April
1999.
[COPS-PR] Reichmeyer F., Kwok Ho Chan, Durham D., Yavatkar R.,
Gai S., McCloghrie K., Herzog S., Smith A. "COPS Usage for
Policy Provisioning", draft-sgai-cops-provisioning-00.txt,
February 1999.
[DCLASS] Bernet, Y., "Usage and Format of the DCLASS Object With
RSVP Signalling", ,
August 1999.
[NULL-SERV] Yoram Bernet, Andrew Smith, Bruce Davie, "Specification of
the Null Service Type",
<draft-ietf-issll-nullservice-00.txt>, September 1999.
[PIB] M. Fine, K. McCloghrie et. al, "An Initial Policy
Information Base For COPS-PR Clients and Servers",
February 1999.
10. Intellectual Property Considerations
The IETF is being notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
11. Author Information
Nitsan Elfassy
Cisco Systems, Inc.
4 Maskit St, P.O.Box 12497
Herzelia Pituach 46766,
Israel
Phone: +972 9 970 0066
email: nitsan@cisco.com
Elfassy, Dutt [Page 11]
COPS extensions for RSVP Receiver Proxy support June 1999
Dinesh Dutt
Cisco Systems, Inc.
170 Tasman Dr.
San Jose, CA 95134-1706
Phone: (408) 527-0955
email: ddutt@cisco.com
12. Full Copyright Statement
Copyright (C) The Internet Society (1997). 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.
Elfassy, Dutt [Page 12]