diff options
Diffstat (limited to 'doc/rfc/rfc2997.txt')
| -rw-r--r-- | doc/rfc/rfc2997.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc2997.txt b/doc/rfc/rfc2997.txt new file mode 100644 index 0000000..cfb7f0a --- /dev/null +++ b/doc/rfc/rfc2997.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group Y. Bernet +Request for Comments: 2997 Microsoft +Category: Standards Track A. Smith + Allegro Networks + B. Davie + Cisco Systems + November 2000 + + + Specification of the Null Service Type + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + In the typical Resource Reservation Protocol (RSVP)/Intserv model, + applications request a specific Intserv service type and quantify the + resources required for that service. For certain applications, the + determination of service parameters is best left to the discretion of + the network administrator. For example, ERP applications are often + mission critical and require some form of prioritized service, but + cannot readily specify their resource requirements. To serve such + applications, we introduce the notion of the 'Null Service'. The + Null Service allows applications to identify themselves to network + 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 policies + appropriate for the application (as determined by the network + administrator). This mode of RSVP usage is particularly applicable + to networks that combine differentiated service (diffserv) QoS + mechanisms with RSVP signaling [intdiff]. In this environment, QoS + policy agents may direct the signaled application's traffic to a + particular diffserv class of service. + + + + + + + + +Bernet, et al. Standards Track [Page 1] + +RFC 2997 Specification of Null Service Type November 2000 + + +1. Motivation + + Using standard RSVP/Intserv signaling, applications running on hosts + issue requests for network resources by communicating the following + 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 recognize + specific traffic (filterspec). + 4. Policy/identity information indicating the user and/or the + application for which resources are required. + + In response, standard RSVP aware network nodes choose to admit or + deny a resource request. The decision is based on the availability + of resources along the relevant path and on policies. Policies + define the resources that may be granted to specific users and/or + applications. When a resource request is admitted, network nodes + install classifiers that are used to recognize the admitted traffic + and policers that are used to assure that the traffic remains within + the limits of the resources requested. + + The Guaranteed and Controlled Load Intserv services are not suitable + for certain applications that are unable to (or choose not to)specify + the resources they require from the network. Diffserv services are + better suited for this type of application. Nodes in a diffserv + network are typically provisioned to classify arriving packets to + some small number of behavior aggregates (BAs) [diffarch]. Traffic + 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 there + is no signaling between hosts and the network. Instead, the network + administrator uses a combination of heuristics, measurement and + experience to provision the network devices to handle aggregated + traffic, with no deterministic knowledge of the volume of traffic + 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 the + volume of traffic likely to arrive at each network node for each + diffserv BA. If the volume of traffic arriving is likely to + exceed the capacity available for the BA claimed, the network + administrator has the choice of increasing the capacity for the + BA, reducing the volume of traffic claiming the BA, or + 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/or + application, based on the diff-serv codepoint (DSCP) in each + packet's IP header or based on other fields in the packet's IP + header (source/destination address/port and protocol). The latter + method of classification is referred to as MF classification. + This method of classification may be unreliable and imposes a + management burden. + + By using RSVP signaling, the management of application traffic in + diffserv networks can be significantly facilitated. (Note that + RSVP/diffserv interoperability has been discussed previously in the + context of the Guaranteed and Controlled Load Intserv services.) + This document focuses on RSVP/diffserv interoperability in the + context of the Null Service. + +2. Operational Overview + + In the proposed mechanism, the RSVP sender offers the new service + type, 'Null Service Type' in the ADSPEC that is included with the + PATH message. A new Tspec corresponding to the new service type is + added to the SENDER_TSPEC. In addition, the RSVP sender will + typically include with the PATH message policy objects identifying + the user, application and sub application ID [identity, application]. + + (Note that at this time, the new Tspec is defined only to carry the + maximum packet size parameter (M), for the purpose of avoiding + fragmentation. No other parameters are defined.) + + Network nodes receiving these PATH messages interpret the service + type to indicate that the application is requesting no specific + service type or quantifiable resources. Instead, network nodes + manage the traffic flow based on the requesting user, the requesting + application and the type of application sub-flow. + + This mechanism offers significant advantages over a pure diffserv + network. At the very least, it informs each network node which would + be affected by the traffic flow (and which is interested in + intercepting the signaling) of: + + 1. The demand for resources in terms of number of flows of a + 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 points + and policy decision points (PEPs and PDPs). The network + administrator can configure these elements of the policy management + 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 the + sender. The returned RESV message may include a DCLASS object + [dclass]. The DCLASS object instructs the sender to mark packets on + the corresponding flow with a specific DSCP (or set of DSCPs). This + mechanism allows PEP/PDPs to affect the volume of traffic arriving at + a node for any given BA. It enables the PEP/PDP to do so based on + sophisticated policies. + +3.1 Operational Notes + +3.1.1 Scalability Issues + + In any network in which per-flow signaling is used, it is wise to + consider scalability concerns. The Null Service encourages signaling + for a broader set of applications than that which would otherwise be + signaled for. However, RSVP signaling does not, in general, generate + a significant amount of traffic relative to the actual data traffic + associated with the session. In addition, the Null Service does not + encourage every application to signal. It should be used by + applications that are considered mission critical or needing QoS + management by network administrators. + + Perhaps of more concern is the impact on processing resources at + network nodes that process the signaling messages. When considering + this issue, it's important to point out that it is not necessary to + process the signaling messages at each network node. In fact, the + combination of RSVP signaling with diff-serv networks may afford + significant benefits even when the RSVP messages are processed only + at certain key nodes (such as boundaries between network domains, + first-hop routers, PEPs or any subset of these). Individual nodes + should be enabled or disabled for RSVP processing at the discretion + of the network administrator. See [intdiff] for a discussion of the + impact of RSVP signaling on diff-serv networks. + + In any case, per-flow state is not necessarily required, even in + 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 Networks + + Network nodes that adhere to the RSVP spec should transparently pass + signaling messages for the Null Service. As such, it is possible to + introduce a small number of PEPs that are enabled for Null Service + into a legacy network and to realize the benefits described in this + document. + +2.1.3 Combining Existing Intserv Services with the Null Service + + This document does not preclude applications from offering both a + quantitative Intserv service (Guaranteed or Controlled Load)and the + Null Service, at the same time. An example of such an application + would be a telephony application that benefits from the Guaranteed + Service but is able to adapt to a less strict service. By + advertising its support for both, the application enables network + policy to decide which service type to provide. + +3. Signaling Details + +3.1 ADSPEC Generation + + The RSVP sender constructs an initial RSVP ADSPEC object specifying + the Null Service Type. Since there are no service specific + parameters associated with this service type, the associated ADSPEC + fragment is empty and contains only the header word. Network nodes + may or may not supply valid values for bandwidth and latency general + parameters. As such, they may use the unknown values defined in + [RFC2216]. + + The ADSPEC is added to the RSVP PATH message created at the sender. + +3.2 RSVP SENDER_TSPEC Object + + An additional Tspec is defined to correspond to the Null Service. If + only the Null Service is offered in the ADSPEC, then this is the only + Tspec included in the SENDER_TSPEC object. If guaranteed or + controlled load services are also offered in the ADSPEC, then the new + Tspec is appended following the standard Intserv token-bucket Tspec + [RFC2210]. + +3.3 RSVP FLOWSPEC Object + + Receivers may respond to PATH messages by generating an RSVP RESV + message including a FLOWSPEC object. The FLOWSPEC object should + specify that it is requesting the Null Service. It is possible that, + in the future, a specific Rspec may be defined to correspond to the + new service type. + + + +Bernet, et al. Standards Track [Page 5] + +RFC 2997 Specification of Null Service Type November 2000 + + +4. Detailed Message Formats + +4.1 Standard ADSPEC Format + + A standard RSVP ADSPEC object is described in [RFC2210]. It includes + a message header and a default general parameters fragment. + Following the default general parameters fragment are fragments for + each supported service type. + +4.2 ADSPEC for Null Service Type + + The Null Service ADSPEC includes the message header and the default + general parameters fragment, followed by a single fragment denoting + the Null Service. The new fragment introduced for the Null Service + 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 illustrated + 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 number + (b) - Message length (10 words not including header) + + Words 2-10: Default general characterization parameters + (c) - Per-Service header, service number 1 (Default General + 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 general + parameter) + (f) - Parameter 4 flag byte + (g) - Parameter 4 length, 1 word not including header + (h) - Parameter ID, parameter 6 (AVAILABLE_PATH_BANDWIDTH general + parameter) + (i) - Parameter 6 flag byte + (j) - Parameter 6 length, 1 word not including header + (k) - Parameter ID, parameter 8 (MINIMUM_PATH_LATENCY general + parameter) + (l) - Parameter 8 flag byte + + + +Bernet, et al. Standards Track [Page 7] + +RFC 2997 Specification of Null Service Type November 2000 + + + (m) - Parameter 8 length, 1 word not including header + (n) - Parameter ID, parameter 10 (PATH_MTU general parameter) + (o) - Parameter 10 flag byte + (p) - Parameter 10 length, 1 word not including header + + Word 11: Null Service parameters + + (q) - Per-Service header, service number 6 (Null) + (x) - Break bit for Null Service + (r) - Length (0) of per-service data not including header word. + + Note that the standard rules for parsing ADSPEC service fragments + ensure that the ADSPEC will not be rejected by legacy network + elements. Specifically, these rules state that a network element + encountering a per-service data header which it does not understand + should set bit 23 (the break-bit) to indicate that the service is not + supported and should use the length field from the header to skip + over the rest of the fragment. + + Also note that it is likely that it will not be possible for hosts or + network nodes to generate meaningful values for words 5 and/or 7 + (bandwidth estimates and path latency), due to the nature of the + service. In this case, the unknown values from [RFC2216] should be + used. + +4.3 SENDER_TSPEC Object Format + + 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 header + (a) - Service number 6 (Null Service) + (b) - Length of per-service data, 2 words not including per-service + header + + Word 2-3: Parameter + (c) - Parameter ID, parameter 128 (Null Service TSpec) + (d) - Parameter 128 flags (none set) + (e) - Parameter 128 length, 1 words not including parameter header + + + + +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 RSVP + SENDER_TSPEC object header, nor does it include the sub-object header + (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_TSPEC + object header and sub-object header. In the case that additional + service types are advertised, requiring the token bucket specific + Tspec defined in RFC2210, the Tspec above would be appended following + the token bucket Tspec, which would in turn follow the object header + and sub-object header. + +4.4 FLOWSPEC Object Format + + The format of an RSVP FLOWSPEC object originating at a receiver + requesting the Null Service is shown below. The value of 6 in the + per-service header (field (c), below) indicates that Null Service is + 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 header + (e) - Parameter ID, parameter 128 (Null Service TSpec) + (f) - Parameter 128 flags (none set) + (g) - Parameter 128 length, 1 words not including parameter header + +4.5 DCLASS Object Format + + DCLASS objects may be included in RESV messages. For details + regarding the DCLASS object format, see [dclass]. + +5. Security Considerations + + The message formatting and usage rules described in this note raise + no new security issues beyond standard RSVP. + + + +Bernet, et al. Standards Track [Page 9] + +RFC 2997 Specification of Null Service Type November 2000 + + +6. References + + [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. + Jamin, "Resource Reservation Protocol (RSVP) - Version + 1 Functional Specification", RFC 2205, September 1997. + + [RFC2216] Shenker, S. and J. Wroclawski, "Network Element QoS + Control Service Specification Template", RFC 2216, + September 1997. + + [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated + 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, "A + Framework for Integrated Services Operation over + Diffserv Networks", RFC 2998, November 2000. + + [diffarch] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. + and W. Weiss, "An Architecture for Differentiated + Services", RFC 2475, December 1998. + + [identity] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, + T., Herzog, S., "Identity Representation for RSVP", RFC + 2752, January 2000. + + [application] Bernet, Y., "Application and Sub Application Identity + Policy Objects for Use with RSVP", RFC 2872, June 2000. + + [dclass] Bernet, Y., "Format of the RSVP DCLASS Object", RFC + 2996, November 2000. + +7. Acknowledgments + + 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' Addresses + + Yoram Bernet + Microsoft + One Microsoft Way + Redmond, WA 98052 + + Phone: +1 (425) 936-9568 + EMail: Yoramb@microsoft.com + + + Andrew Smith + Allegro Networks + 6399 San Ignacio Ave. + San Jose, CA 95119, USA + + FAX: +1 415 345 1827 + Email: andrew@allegronetworks.com + + + Bruce Davie + Cisco Systems + 250 Apollo Drive + Chelmsford, MA 01824 + + Phone: +1 (978)-244-8000 + EMail: bsd@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + +Bernet, et al. Standards Track [Page 11] + +RFC 2997 Specification of Null Service Type November 2000 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2000). 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Bernet, et al. Standards Track [Page 12] + |