idnits 2.17.1 draft-moore-qualservice-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 5) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2205]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'M' is mentioned on line 408, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2216 Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 T. Moore, Microsoft 2 Internet Draft Y. Bernet, Microsoft 3 Expires December 1999 A. Smith, Extreme Networks 4 draft-moore-qualservice-00.txt B. Davie, Cisco Systems 5 June, 1999 7 Specification of the Qualitative Service Type 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet- Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet- 26 Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Distribution of this memo is unlimited. 31 Copyright Notice 33 Copyright (C) The Internet Society (1999). All Rights Reserved. 35 1. Abstract 37 This draft describes the use of RSVP [RFC2205] with applications 38 that do not have resource requirements that are readily quantifiable 39 per the standard Intserv token-bucket model (qualitative 40 applications). We introduce the 'qualitative' service-type. This 41 service-type can be used in conjunction with RSVP signaling to 42 manage the allocation of network resources to traffic originating 43 from qualitative applications. This mode of RSVP usage is 44 particularly applicable to networks that combine differentiated 45 service (diff-serv) QoS mechanisms with RSVP signaling [intdiff]. 47 2. Motivation 49 Using standard RSVP/Intserv signaling, applications running on hosts 50 issue requests for network resources by communicating the following 51 information to network devices: 53 Moore expires December 1999 1 54 draft-moore-qualservice-00.txt June, 1999 56 1. A requested service level (Guaranteed or Controlled Load). 57 2. The quantity of resources required at that service level. 58 3. Classification information by which the network can recognize 59 specific traffic (filterspec). 60 4. Policy/identity information indicating the user and/or the 61 application for which resources are required. 63 In response, standard RSVP aware network nodes choose to admit or 64 deny a resource request. The decision is based on the availability 65 of resources along the relevant path and on policies. Policies 66 define the resources that may be granted to specific users and/or 67 applications. When a resource request is admitted, network nodes 68 install classifiers that are used to recognize the admitted traffic 69 and policers that are used to assure that the traffic remains within 70 the limits of the resources requested. 72 Standard RSVP/Intserv is not suitable for qualitative applications 73 because these applications are unable to quantify the resources they 74 require from the network. Since the required resources cannot be 75 quantified, network nodes cannot determine whether sufficient 76 resources exist to accommodate an application's traffic and standard 77 Intserv style admission control cannot be applied. 79 Diff-serv QoS mechanisms are better suited for qualitative 80 applications. Nodes in a diff-serv network are typically provisioned 81 to classify arriving packets to some small number of behaviour 82 aggregates (BAs) [diffarch]. Treatment is applied on a per-BA basis. 83 This provisioning tends to be 'open-loop' with respect to end-user 84 traffic flows in the sense that there is no signaling between hosts 85 and the network. Instead, the network administrator uses a 86 combination of heuristics, measurement and experience to provision 87 the network devices to handle aggregated traffic, with no 88 deterministic knowledge of the volume of traffic that will arrive at 89 any specific node. 91 In applying diff-serv mechanisms to manage qualitative traffic, 92 network administrators are faced with two challenges: 94 1. Provisioning - network administrators need to anticipate the 95 volume of traffic likely to arrive at each network node for each 96 diff-serv BA. If the volume of traffic arriving is likely to 97 exceed the capacity available for the BA claimed, the network 98 administrator has the choice of increasing the capacity for the 99 BA, reducing the volume of traffic claiming the BA, or 100 compromising service to all traffic arriving for the BA. 101 2. Classification - diff-serv nodes classify traffic to user and/or 102 application, based on the diff-serv codepoint (DSCP) in each 103 packet's IP header or based on other fields in the packet's IP 104 header (source/destination address/port and protocol). The latter 105 method of classification is referred to as MF classification. 106 This method of classification may be unreliable and imposes a 107 management burden. 109 Moore expires December, 1999 2 110 draft-moore-qualservice-00.txt June, 1999 112 By using RSVP signaling, the management of traffic from qualitative 113 applications in diff-serv networks can be significantly facilitated. 114 (Note that RSVP/diff-serv interoperability has been discussed 115 previously in the context of quantitative applications and 116 quantitative diff-serv services [intdiff]. This draft focuses on 117 qualitative applications.) 119 3. Operational Overview 121 In the proposed mechanism, the RSVP sender offers the new service 122 type, 'Service Type Qualitative' in the ADSPEC that is included with 123 the PATH message. A new Tspec corresponding to the new service type 124 is added to the SENDER_TSPEC object and may carry a limited set of 125 quantifiable parameters. In addition, the RSVP sender will typically 126 include with the PATH message policy objects identifying the user, 127 application and sub application ID [identity, application]. 129 (Note that at this time, the new Tspec is defined only to carry the 130 maximum packet size parameter (M), for the purpose of avoiding 131 fragmentation. No other parameters are defined.) 133 Network nodes receiving these PATH messages interpret the service 134 type to indicate that the traffic flow is not quantifiable using the 135 standard Intserv token-bucket model. Instead, network nodes manage 136 the traffic flow based on any or all of the following: parameters 137 which may be included in the alternate Tspec, the requesting user, 138 the requesting application and the type of application sub-flow. 140 This mechanism offers significant advantages over a pure diff-serv 141 network. At the very least, it informs each network node which would 142 be affected by the traffic flow (and which is interested in 143 intercepting the signaling) of: 145 1. The demand for resources in terms of number of flows of a 146 particular type traversing the node. 147 2. The binding between classification information and user, 148 application and sub-application. 150 This information is particularly useful to policy enforcement points 151 and policy decision points (PEPs and PDPs). 153 The network is expected to return an RSVP RESV message to the 154 sender. The returned RESV message may include a DCLASS object 155 [dclass]. The DCLASS object instructs the sender to mark packets on 156 the corresponding flow with a specific DSCP (or set of DSCPs). This 157 mechanism allows PEP/PDPs to affect the volume of traffic arriving 158 at a node for any given BA. It enables the PEP/PDP to do so based on 159 sophisticated policies. 161 Note that by providing a set of DSCPs rather than a single DSCP, the 162 network enables the host to designate certain packets as lower 163 priority than other packets on the same flow. The specific usage of 165 Moore expires December, 1999 3 166 draft-moore-qualservice-00.txt June, 1999 168 a set of DSCPs is beyond the scope of this draft and is discussed 169 further in [dclass]. 171 3.1 Operational Notes 173 3.1.1 Scalability Issues 175 In any network in which per-flow signaling is used, it is wise to 176 consider scalability concerns. Signaling for qualitative 177 applications (in addition to quantitative applications) will 178 increase the amount of signaling traffic in the network. However, 179 RSVP signaling does not, in general, generate a significant amount 180 of traffic relative to the actual data traffic associated with the 181 session. 183 Perhaps of more concern is the impact on processing resources at 184 network nodes that process the signaling messages. When considering 185 this issue, it's important to point out that it is not necessary to 186 process the signaling messages at each network node. In fact, the 187 combination of RSVP signaling with diff-serv networks may afford 188 significant benefits even when the RSVP messages are processed only 189 at certain key nodes (such as boundaries between network domains, 190 first-hop routers, PEPs or any subset of these). Individual nodes 191 should be enabled or disabled for RSVP processing at the discretion 192 of the network administrator. See [intdiff] for a discussion of the 193 impact of RSVP signaling on diff-serv networks. 195 In any case, per-flow state is not necessarily required, even in 196 nodes that apply per-flow processing. 198 3.1.2 Policy Enforcement in Legacy Networks 200 Network nodes that adhere to the RSVP spec should transparently pass 201 the signaling messages associated with qualitative applications. As 202 such, it is possible to introduce a small number of PEPs that are 203 enabled for Service Type Qualitative into a legacy network and to 204 realize the benefits described in this draft. 206 3.1.3 Quantitative Applications which Accept Qualitative Service 208 This draft does not preclude applications from offering both a 209 quantitative service type and Service Type Qualitative, at the same 210 time. An example of such an application would be a telephony 211 application that benefits from a quantitative service but is able to 212 adapt to a qualitative service. By advertising its support for both, 213 the application enables network policy to decide which service type 214 to provide. 216 4. Signaling Details 218 4.1 ADSPEC Generation 220 Moore expires December, 1999 4 221 draft-moore-qualservice-00.txt June, 1999 223 The RSVP sender constructs an initial RSVP ADSPEC object specifying 224 Service Type Qualitative. Since there are no service specific 225 parameters associated with this service type, the associated ADSPEC 226 fragment is empty and contains only the header word. Network nodes 227 may or may not supply valid values for bandwidth and latency general 228 parameters. As such, they may use the unknown values defined in 229 [RFC2216]. 231 The ADSPEC is added to the RSVP PATH message created at the sender. 233 4.2 RSVP SENDER_TSPEC Object 235 An additional Tspec is defined to correspond to the qualitative 236 service. If only the qualitative service type is offered in the 237 ADSPEC, then this is the only Tspec included in the SENDER_TSPEC 238 object. If guaranteed or controlled load services are also offered 239 in the ADSPEC, then the new Tspec is appended following the standard 240 Intserv token-bucket Tspec [RFC2210]. 242 4.3 RSVP FLOWSPEC Object 244 Receivers may respond to PATH messages by generating an RSVP RESV 245 message including a FLOWSPEC object. The FLOWSPEC object should 246 specify that it is requesting Service Type Qualitative. It is 247 possible that, in the future, a specific Rspec may be defined to 248 correspond to the new service type. 250 5. Detailed Message Formats 252 5.1 Standard ADSPEC Format 254 A standard RSVP ADSPEC object is described in [RFC2210]. It includes 255 a message header and a default general parameters fragment. 256 Following the default general parameters fragment are fragments for 257 each supported service type. 259 5.2 ADSPEC for Qualitative Service Type 261 The Qualitative Service Type ADSPEC includes the message header and 262 the default general parameters fragment, followed by a single 263 fragment denoting Service Type Qualitative. The new fragment 264 introduced for Service Type Qualitative is formatted as follows: 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | 6 (a) |x| Reserved | 0 (b) | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 a - indicates Service Type Qualitative (6). 271 x - is the break-bit. 272 b - indicates zero words in addition to the header. 274 A complete ADSPEC supporting only Service Type Qualitative is 275 illustrated below: 277 Moore expires December, 1999 5 278 draft-moore-qualservice-00.txt June, 1999 280 31 24 23 16 15 8 7 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 1 | 0 (a) | Reserved | Msg length �1 (b) | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 2 | 1 (c) |x| Reserved | 8 (d) | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 3 | 4 (e) | (f) | 1 (g) | 287 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 4 | IS hop cnt (32-bit unsigned) | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 5 | 6 (h) | (i) | 1 (j) | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 6 | Path b/w estimate (32-bit IEEE floating point number) | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 7 | 8 (k) | (l) | 1 (m) | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 8 | Minimum path latency (32-bit integer) | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 9 | 10 (n) | (o) | 1 (p) | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 10 | Composed MTU (32-bit unsigned) | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 11 | 6 (q) |x| Reserved | 0 (r) | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Word 1: Message Header: 306 (a) - Message header and version number 307 (b) - Message length - 10 words not including header 309 Words 2-10: Default general characterization parameters 310 (c) - Per-Service header, service number 1 (Default General 311 Parameters) 312 (x) - Global Break bit (NON_IS_HOP general parameter 2) 313 (d) - Length of General Parameters data block (8 words) 314 (e) - Parameter ID, parameter 4 (NUMBER_OF_IS_HOPS general 315 parameter) 316 (f) - Parameter 4 flag byte 317 (g) - Parameter 4 length, 1 word not including header 318 (h) - Parameter ID, parameter 6 (AVAILABLE_PATH_BANDWIDTH general 319 parameter) 320 (i) - Parameter 6 flag byte 321 (j) - Parameter 6 length, 1 word not including header 322 (k) - Parameter ID, parameter 8 (MINIMUM_PATH_LATENCY general 323 parameter) 324 (l) - Parameter 8 flag byte 325 (m) - Parameter 8 length, 1 word not including header 326 (n) - Parameter ID, parameter 10 (PATH_MTU general parameter) 327 (o) - Parameter 10 flag byte 328 (p) - Parameter 10 length, 1 word not including header 330 Word 11: Qualitative parameters 331 (q) - Per-Service header, service number 6 (Qualitative) 332 (x) - Break bit for Service Type Qualitative 334 Moore expires December, 1999 6 335 draft-moore-qualservice-00.txt June, 1999 337 (r) - Length (0) of per-service data not including header word. 339 Note that the standard rules for parsing ADSPEC service fragments 340 ensure that the ADSPEC will not be rejected by legacy network 341 elements. Specifically, these rules state that a network element 342 encountering a per-service data header which it does not understand 343 should set bit 23 (the break-bit) to indicate that the service is 344 not supported and should use the length field from the header to 345 skip over the rest of the fragment. 347 Also note that it is likely that it will not be possible for hosts 348 or network nodes to generate meaningful values for words 5 and/or 7 349 (bandwidth estimates and path latency), due to the qualitative 350 nature of the service. In this case, the unknown values from 351 [RFC2216] should be used. 353 5.3 SENDER_TSPEC Object Format 355 The following Tspec is defined to correspond to the qualitative 356 service type: 358 31 24 23 16 15 8 7 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 1 | 6 (a) |0| Reserved | 2 (b) | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 2 | 128 (c) | 0 (d) | 1 (e) | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 3 | Maximum Packet Size [M] (32-bit integer) | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Word 1: Service header 368 (a) - Service number 6 (Service Type Qualitative) 369 (b) - Length of per-service data, 2 words not including per-service 370 header 372 Word 2-3: Parameter 373 (c) - Parameter ID, parameter 128 (Qualitative Service TSpec) 374 (d) - Parameter 128 flags (none set) 375 (e) - Parameter 128 length, 1 words not including parameter header 377 Note that the illustration above does not include the standard RSVP 378 SENDER_TSPEC object header, nor does it include the sub-object 379 header (which indicates the message format version number and 380 length), defined in RFC 2205 and RFC 2210, respectively. 382 In the case that only Service Type Qualitative is advertised in the 383 ADSPEC, the Tspec above would be appended immediately after the 384 SENDER_TSPEC object header and sub-object header. In the case that 385 additional service types are advertised, requiring the token bucket 386 specific Tspec defined in RFC2210, the Tspec above would be appended 387 following the token bucket Tspec, which would in turn follow the 388 object header and sub-object header. 390 Moore expires December, 1999 7 391 draft-moore-qualservice-00.txt June, 1999 393 5.4 FLOWSPEC Object Format 395 The format of an RSVP FLOWSPEC object originating at a receiver 396 requesting Qualitative service is shown below. The value of 6 in the 397 per-service header (field (c), below) indicates that Service Type 398 Qualitative is being requested. 400 31 24 23 16 15 8 7 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 1 | 0 (a) | reserved | 3 (b) | 403 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 2 | 6 (c) |0| Reserved | 2 (d) | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 3 | 128 (e) | 0 (f) | 1 (g) | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 4 | Maximum Packet Size [M] (32-bit integer) | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 (a) - Message format version number (0) 412 (b) - Overall length 3 words not including header) 413 (c) - Service header, service number 6 (Qualitative) 414 (d) - Length of qualitative data, 2 words not including per-service 415 header 416 (e) - Parameter ID, parameter 128 (Qualitative Service TSpec) 417 (f) - Parameter 128 flags (none set) 418 (g) - Parameter 128 length, 1 words not including parameter header 420 5.5 DCLASS Object Format 422 DCLASS objects may be included in RESV messages. For details 423 regarding the DCLASS object format, see [dclass]. 425 6. Security Considerations 427 The message formatting and usage rules described in this note raise 428 no new security issues beyond standard RSVP. 430 9. References 432 [RFC2205] Braden, B., et al., "Resource Reservation Protocol (RSVP) 433 - Version 1 Functional Specification", RFC 2205, September 1997. 435 [RFC2216] Shenker, S., and Wroclawski, J., "Network Element QoS 436 Control Service Specification Template", RFC 2216, September 1997. 438 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 439 Services", RFC 2210, September 1997. 441 [intdiff] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., 442 Nichols, K., Speer, M., Braden, B., Davie, B., "Integrated Services 443 Operation over Diffserv Networks", Internet Draft, June 1999. 445 Moore expires December, 1999 8 446 draft-moore-qualservice-00.txt June, 1999 448 [diffarch] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 449 Weiss, W., "An Architecture for Differentiated Services", RFC 2475, 450 December 1998. 452 [identity] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, 453 T., Herzog, S., "Identity Representation for RSVP", Internet Draft, 454 February 1999. 456 [application] Bernet, Y., "Application and Sub Application Identity 457 Policy Objects for Use with RSVP", Internet Draft, February 1999. 459 [dclass] Bernet, Y., "Usage and Format of the DCLASS Object with 460 RSVP Signaling", Internet Draft, June 1999. 462 10. Acknowledgments 464 We thank Fred Baker, Dinesh Dutt, Nitsan Elfassy, John Schnizlein, 465 Ramesh Pabbati and Sanjay Kaniyar for their comments on this draft. 467 11. Author's Addresses 469 Tim Moore 470 Microsoft 471 One Microsoft Way 472 Redmond, WA 98052 473 Timmoore@microsoft.com 475 Yoram Bernet 476 Microsoft 477 One Microsoft Way 478 Redmond, WA 98052 479 (425) 936-9568 480 Yoramb@microsoft.com 482 Andrew Smith 483 Extreme Networks 484 3585 Monroe St. 485 Santa Clara CA 95051 486 USA 487 +1 (408) 579 2821 488 andrew@extremenetworks.com 490 Bruce Davie 491 Cisco Systems 492 250 Apollo Drive 493 Chelmsford, MA 01824 494 (978)-244-8000 495 bsd@cisco.com 497 Moore expires December, 1999 9