RFC relevance of resource

As per Relevance of the word resource, we have this rfc below:

Network Working Group Y.
Request for Comments: 2997
Category: Standards Track A.
Allegro
B.
Cisco
November 2000

Specification of the Null Service

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

Copyright

Copyright (C) The Internet Society (2000). All Rights Reserved

In the typical Resource Reservation Protocol (RSVP)/Intserv model
applications request a specific Intserv service type and quantify
resources required for that service. For certain applications,
determination of service parameters is best left to the discretion
the network administrator. For example, ERP applications are
mission critical and require some form of prioritized service,
cannot readily specify their resource requirements. To serve
applications, we introduce the notion of the 'Null Service'.
Null Service allows applications to identify themselves to
Quality of Service (QoS) policy agents, using RSVP signaling
However, it does not require them to specify resource requirements
QoS policy agents in the network respond by applying QoS
appropriate for the application (as determined by the
administrator). This mode of RSVP usage is particularly
to networks that combine differentiated service (diffserv)
mechanisms with RSVP signaling [intdiff]. In this environment,
policy agents may direct the signaled application's traffic to
particular diffserv class of service

Bernet, et al. Standards Track [Page 1]

RFC 2997 Specification of Null Service Type November 2000

1.

Using standard RSVP/Intserv signaling, applications running on
issue requests for network resources by communicating the
information to network devices

1. A requested service level (Guaranteed or Controlled Load).
2. The quantity of resources required at that service level
3. Classification information by which the network can
specific traffic (filterspec).
4. Policy/identity information indicating the user and/or
application for which resources are required

In response, standard RSVP aware network nodes choose to admit
deny a resource request. The decision is based on the
of resources along the relevant path and on policies.
define the resources that may be granted to specific users and/
applications. When a resource request is admitted, network
install classifiers that are used to recognize the admitted
and policers that are used to assure that the traffic remains
the limits of the resources requested

The Guaranteed and Controlled Load Intserv services are not
for certain applications that are unable to (or choose not to)
the resources they require from the network. Diffserv services
better suited for this type of application. Nodes in a
network are typically provisioned to classify arriving packets
some small number of behavior aggregates (BAs) [diffarch].
is handled on a per-BA basis. This provisioning tends to be 'top
down' with respect to end-user traffic flows in the sense that
is no signaling between hosts and the network. Instead, the
administrator uses a combination of heuristics, measurement
experience to provision the network devices to handle
traffic, with no deterministic knowledge of the volume of
that will arrive at any specific node

In applying diffserv mechanisms to manage application traffic
network administrators are faced with two challenges

1. Provisioning - network administrators need to anticipate
volume of traffic likely to arrive at each network node for
diffserv BA. If the volume of traffic arriving is likely
exceed the capacity available for the BA claimed, the
administrator has the choice of increasing the capacity for
BA, reducing the volume of traffic claiming the BA,
compromising service to all traffic arriving for the BA

Bernet, et al. Standards Track [Page 2]

RFC 2997 Specification of Null Service Type November 2000

2. Classification - diffserv nodes classify traffic to user and/
application, based on the diff-serv codepoint (DSCP) in
packet's IP header or based on other fields in the packet's
header (source/destination address/port and protocol). The
method of classification is referred to as MF classification
This method of classification may be unreliable and imposes
management burden

By using RSVP signaling, the management of application traffic
diffserv networks can be significantly facilitated. (Note
RSVP/diffserv interoperability has been discussed previously in
context of the Guaranteed and Controlled Load Intserv services.)
This document focuses on RSVP/diffserv interoperability in
context of the Null Service

2. Operational

In the proposed mechanism, the RSVP sender offers the new
type, 'Null Service Type' in the ADSPEC that is included with
PATH message. A new Tspec corresponding to the new service type
added to the SENDER_TSPEC. In addition, the RSVP sender
typically include with the PATH message policy objects
the user, application and sub application ID [identity, application].

(Note that at this time, the new Tspec is defined only to carry
maximum packet size parameter (M), for the purpose of
fragmentation. No other parameters are defined.)

Network nodes receiving these PATH messages interpret the
type to indicate that the application is requesting no
service type or quantifiable resources. Instead, network
manage the traffic flow based on the requesting user, the
application and the type of application sub-flow

This mechanism offers significant advantages over a pure
network. At the very least, it informs each network node which
be affected by the traffic flow (and which is interested
intercepting the signaling) of

1. The demand for resources in terms of number of flows of
particular type traversing the node
2. The binding between classification information and user
application and sub-application

Bernet, et al. Standards Track [Page 3]

RFC 2997 Specification of Null Service Type November 2000

This information is particularly useful to policy enforcement
and policy decision points (PEPs and PDPs). The
administrator can configure these elements of the policy
system to apply appropriate policy based on the identity of the user
the application and the specific sub application ID

PEPs and PDPs may be configured to return an RSVP RESV message to
sender. The returned RESV message may include a DCLASS
[dclass]. The DCLASS object instructs the sender to mark packets
the corresponding flow with a specific DSCP (or set of DSCPs).
mechanism allows PEP/PDPs to affect the volume of traffic arriving
a node for any given BA. It enables the PEP/PDP to do so based
sophisticated policies

3.1 Operational

3.1.1 Scalability

In any network in which per-flow signaling is used, it is wise
consider scalability concerns. The Null Service encourages
for a broader set of applications than that which would otherwise
signaled for. However, RSVP signaling does not, in general,
a significant amount of traffic relative to the actual data
associated with the session. In addition, the Null Service does
encourage every application to signal. It should be used
applications that are considered mission critical or needing
management by network administrators

Perhaps of more concern is the impact on processing resources
network nodes that process the signaling messages. When
this issue, it's important to point out that it is not necessary
process the signaling messages at each network node. In fact,
combination of RSVP signaling with diff-serv networks may
significant benefits even when the RSVP messages are processed
at certain key nodes (such as boundaries between network domains
first-hop routers, PEPs or any subset of these). Individual
should be enabled or disabled for RSVP processing at the
of the network administrator. See [intdiff] for a discussion of
impact of RSVP signaling on diff-serv networks

In any case, per-flow state is not necessarily required, even
nodes that apply per-flow processing

Bernet, et al. Standards Track [Page 4]

RFC 2997 Specification of Null Service Type November 2000

2.1.2 Policy Enforcement in Legacy

Network nodes that adhere to the RSVP spec should transparently
signaling messages for the Null Service. As such, it is possible
introduce a small number of PEPs that are enabled for Null
into a legacy network and to realize the benefits described in
document

2.1.3 Combining Existing Intserv Services with the Null

This document does not preclude applications from offering both
quantitative Intserv service (Guaranteed or Controlled Load)and
Null Service, at the same time. An example of such an
would be a telephony application that benefits from the
Service but is able to adapt to a less strict service.
advertising its support for both, the application enables
policy to decide which service type to provide

3. Signaling

3.1 ADSPEC

The RSVP sender constructs an initial RSVP ADSPEC object
the Null Service Type. Since there are no service
parameters associated with this service type, the associated
fragment is empty and contains only the header word. Network
may or may not supply valid values for bandwidth and latency
parameters. As such, they may use the unknown values defined
[RFC2216].

The ADSPEC is added to the RSVP PATH message created at the sender

3.2 RSVP SENDER_TSPEC

An additional Tspec is defined to correspond to the Null Service.
only the Null Service is offered in the ADSPEC, then this is the
Tspec included in the SENDER_TSPEC object. If guaranteed
controlled load services are also offered in the ADSPEC, then the
Tspec is appended following the standard Intserv token-bucket
[RFC2210].

3.3 RSVP FLOWSPEC

Receivers may respond to PATH messages by generating an RSVP
message including a FLOWSPEC object. The FLOWSPEC object
specify that it is requesting the Null Service. It is possible that
in the future, a specific Rspec may be defined to correspond to
new service type

Bernet, et al. Standards Track [Page 5]

RFC 2997 Specification of Null Service Type November 2000

4. Detailed Message

4.1 Standard ADSPEC

A standard RSVP ADSPEC object is described in [RFC2210]. It
a message header and a default general parameters fragment
Following the default general parameters fragment are fragments
each supported service type

4.2 ADSPEC for Null Service

The Null Service ADSPEC includes the message header and the
general parameters fragment, followed by a single fragment
the Null Service. The new fragment introduced for the Null
is formatted as follows

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 (a) |x| Reserved | 0 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

a - indicates Null Service (6).
x - is the break-bit
b - indicates zero words in addition to the header

Bernet, et al. Standards Track [Page 6]

RFC 2997 Specification of Null Service Type November 2000

A complete ADSPEC supporting only the Null Service is
below

31 24 23 16 15 8 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | Reserved | Msg length -1 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 1 (c) |x| Reserved | 8 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 4 (e) | (f) | 1 (g) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | IS hop cnt (32-bit unsigned) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | 6 (h) | (i) | 1 (j) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Path b/w estimate (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | 8 (k) | (l) | 1 (m) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Minimum path latency (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | 10 (n) | (o) | 1 (p) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 | Composed MTU (32-bit unsigned) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11 | 6 (q) |x| Reserved | 0 (r) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Word 1: Message Header
(a) - Message header and version
(b) - Message length (10 words not including header

Words 2-10: Default general characterization
(c) - Per-Service header, service number 1 (Default
Parameters
(x) - Global Break bit (NON_IS_HOP general parameter 2)
(d) - Length of General Parameters data block (8 words
(e) - Parameter ID, parameter 4 (NUMBER_OF_IS_HOPS
parameter
(f) - Parameter 4 flag
(g) - Parameter 4 length, 1 word not including
(h) - Parameter ID, parameter 6 (AVAILABLE_PATH_BANDWIDTH
parameter
(i) - Parameter 6 flag
(j) - Parameter 6 length, 1 word not including
(k) - Parameter ID, parameter 8 (MINIMUM_PATH_LATENCY
parameter
(l) - Parameter 8 flag

Bernet, et al. Standards Track [Page 7]

RFC 2997 Specification of Null Service Type November 2000

(m) - Parameter 8 length, 1 word not including
(n) - Parameter ID, parameter 10 (PATH_MTU general parameter
(o) - Parameter 10 flag
(p) - Parameter 10 length, 1 word not including

Word 11: Null Service

(q) - Per-Service header, service number 6 (Null
(x) - Break bit for Null
(r) - Length (0) of per-service data not including header word

Note that the standard rules for parsing ADSPEC service
ensure that the ADSPEC will not be rejected by legacy
elements. Specifically, these rules state that a network
encountering a per-service data header which it does not
should set bit 23 (the break-bit) to indicate that the service is
supported and should use the length field from the header to
over the rest of the fragment

Also note that it is likely that it will not be possible for hosts
network nodes to generate meaningful values for words 5 and/or 7
(bandwidth estimates and path latency), due to the nature of
service. In this case, the unknown values from [RFC2216] should
used

4.3 SENDER_TSPEC Object

The following Tspec is defined to correspond to the Null Service

31 24 23 16 15 8 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 6 (a) |0| Reserved | 2 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 128 (c) | 0 (d) | 1 (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Word 1: Service
(a) - Service number 6 (Null Service
(b) - Length of per-service data, 2 words not including per-

Word 2-3:
(c) - Parameter ID, parameter 128 (Null Service TSpec
(d) - Parameter 128 flags (none set
(e) - Parameter 128 length, 1 words not including parameter

Bernet, et al. Standards Track [Page 8]

RFC 2997 Specification of Null Service Type November 2000

Note that the illustration above does not include the standard
SENDER_TSPEC object header, nor does it include the sub-object
(which indicates the message format version number and length),
defined in RFC 2205 and RFC 2210, respectively

In the case that only the Null Service is advertised in the ADSPEC
the Tspec above would be appended immediately after the SENDER_
object header and sub-object header. In the case that
service types are advertised, requiring the token bucket
Tspec defined in RFC2210, the Tspec above would be appended
the token bucket Tspec, which would in turn follow the object
and sub-object header

4.4 FLOWSPEC Object

The format of an RSVP FLOWSPEC object originating at a
requesting the Null Service is shown below. The value of 6 in
per-service header (field (c), below) indicates that Null Service
being requested

31 24 23 16 15 8 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | reserved | 3 (b) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 6 (c) |0| Reserved | 2 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 128 (e) | 0 (f) | 1 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(a) - Message format version number (0)
(b) - Overall length (3 words not including header
(c) - Service header, service number 6 (Null
(d) - Length of data, 2 words not including per-service
(e) - Parameter ID, parameter 128 (Null Service TSpec
(f) - Parameter 128 flags (none set
(g) - Parameter 128 length, 1 words not including parameter

4.5 DCLASS Object

DCLASS objects may be included in RESV messages. For
regarding the DCLASS object format, see [dclass].

5. Security

The message formatting and usage rules described in this note
no new security issues beyond standard RSVP

Bernet, et al. Standards Track [Page 9]

RFC 2997 Specification of Null Service Type November 2000

6.

[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S
Jamin, "Resource Reservation Protocol (RSVP) -
1 Functional Specification", RFC 2205, September 1997.

[RFC2216] Shenker, S. and J. Wroclawski, "Network Element
Control Service Specification Template", RFC 2216,
September 1997.

[RFC2210] Wroclawski, J., "The Use of RSVP with IETF
Services", RFC 2210, September 1997.

[intdiff] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang
L., Nichols, K., Speer, M., Braden, B. and B. Davie, "
Framework for Integrated Services Operation
Diffserv Networks", RFC 2998, November 2000.

[diffarch] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z
and W. Weiss, "An Architecture for
Services", RFC 2475, December 1998.

[identity] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore
T., Herzog, S., "Identity Representation for RSVP",
2752, January 2000.

[application] Bernet, Y., "Application and Sub Application
Policy Objects for Use with RSVP", RFC 2872, June 2000.

[dclass] Bernet, Y., "Format of the RSVP DCLASS Object",
2996, November 2000.

7.

We thank Fred Baker, Dinesh Dutt, Nitsan Elfassy, John Schnizlein
Ramesh Pabbati and Sanjay Kaniyar for their comments on this memo

Bernet, et al. Standards Track [Page 10]

RFC 2997 Specification of Null Service Type November 2000

8. Authors'

Yoram

One Microsoft
Redmond, WA 98052

Phone: +1 (425) 936-9568
EMail: Yoramb@microsoft.

Andrew
Allegro
6399 San Ignacio Ave
San Jose, CA 95119,

FAX: +1 415 345 1827
Email: andrew@allegronetworks.

Bruce
Cisco
250 Apollo
Chelmsford, MA 01824

Phone: +1 (978)-244-8000
EMail: bsd@cisco.

Bernet, et al. Standards Track [Page 11]

RFC 2997 Specification of Null Service Type November 2000

9. Full Copyright

Copyright (C) The Internet Society (2000). All Rights Reserved

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Funding for the RFC Editor function is currently provided by
Internet Society

Bernet, et al. Standards Track [Page 12]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX