idnits 2.17.1 draft-dcsgroup-sip-call-auth-02.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? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** There are 108 instances of too long lines in the document, the longest one being 104 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 section? '1' on line 41 looks like a reference -- Missing reference section? '2' on line 71 looks like a reference -- Missing reference section? '3' on line 104 looks like a reference -- Missing reference section? '4' on line 119 looks like a reference -- Missing reference section? '7' on line 171 looks like a reference -- Missing reference section? '5' on line 385 looks like a reference -- Missing reference section? '6' on line 389 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIP Working Group W. Marshall 2 Internet Draft K. Ramakrishnan 3 Document: AT&T 5 E. Miller 6 G. Russell 7 CableLabs 9 B. Beser 10 M. Mannette 11 K. Steinbrenner 12 3Com 14 D. Oran 15 F. Andreasen 16 Cisco 18 J. Pickens 19 Com21 21 P. Lalwaney 22 Nokia 24 J. Fellows 25 Motorola 27 D. Evans 28 Secure Cable Solutions 30 K. Kelly 31 NetSpeak 33 June, 2000 35 SIP Extensions for Media Authorization 37 Status of this Memo 39 This document is an Internet-Draft and is in full conformance with all 40 provisions of Section 10 of RFC2026 [1]. 42 Internet-Drafts are working documents of the Internet Engineering Task 43 Force (IETF), its areas, and its working groups. Note that other groups 44 may also distribute working documents as Internet-Drafts. Internet-Drafts 45 are draft documents valid for a maximum of six months and may be updated, 46 replaced, or obsoleted by other documents at any time. It is 47 inappropriate to use Internet- Drafts as reference material or to cite 48 them other than as "work in progress." 50 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/ietf/1id-abstracts.txt 53 The list of Internet-Draft Shadow Directories can be accessed at 54 http://www.ietf.org/shadow.html. 56 The distribution of this memo is unlimited. It is filed as , and expires December 31, 2000. Please 58 send comments to the authors. 60 1. Abstract 62 This document describes the need for call authorization and offers a 63 mechanism for call authorization that can be used for admission control 64 and against denial of service attacks. 66 2. Conventions used in this document 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in RFC-2119 [2]. 72 3. Background and Motivation 74 The current IP Telephony systems consider a perfect world in which there 75 is unlimited amount of bandwidth and network layer QoS comes free. The 76 reality is that bandwidth is neither unlimited nor free. Enhanced quality 77 of service, as required for high-grade voice communication, needs special 78 authorization for better than `best-effort' service. Without such a 79 capability, it is possible that a single berserk IP telephony device can 80 cause denial of service to a significant number of others. 82 4. Overview 84 Integration of Media Authorization and Call Signaling architecture 85 consists of User Agents (UAs) which are considered untrusted, and SIP- 86 Proxy which authorizes the call that is initiated by UA. 88 The SIP-Proxy authorizes the Media data flow to/from the UA and returns 89 to the UA a Media-Authorization-Token, which is to be used for 90 authorization when bandwidth is requested for the data-stream. 92 When the UA is ready to send the media data-stream to the other end- 93 point, it first requests bandwidth, using the Authorization-Token it 94 received from its SIP-Proxy. 96 5. Changes to SIP to Support Media Authorization 98 This document extends SIP in support of an authorization scheme. In this 99 architecture the SIP-Proxy supplies the UA an Authorization-Token which 100 is to be used for bandwidth requests. The extension defined allows 101 network resources to be authorized by the SIP-Proxy. 103 The following syntax specification uses the augmented Backus-Naur Form 104 (BNF) as described in RFC-2234 [3]. 106 DCS Group Category Informational _ Expiration 12/31/00 2 107 5.1 SIP Header Extension 109 The Media-Auth-Token general header conveys an identifier of the local 110 Gate to a UA. This information is used for authorizing the Media Stream. 112 Media-Auth = "Media- Authorization" ":" 113 Media-Authorization-Token 115 Media-Authorization-Token = 1*hex 117 5.2 SIP Procedures 119 This section defines a SIP [4] profile for usage in Media Authorization 120 compatible systems from the point of view of Authorizing Calls. 122 The initial SIP INVITE message, as well as mid-call resource change 123 messages and mid-call changes in call destination should be authorized. 124 These SIP messages are sent through the proxies to receive this 125 authorization. 127 5.2.1. User Agent Client (UAC) 129 The Media-Auth-Token, contained in the Media-Authorization header, is 130 included in the first response message sent by the SIP-Proxy to the UAC. 132 The UAC SHOULD use the Media-Auth-Token when requesting bandwidth for 133 Media data stream during initiation and retaining of the bandwidth. 135 5.2.2. User Agent Server (UAS) 137 The User Agent Server receives the Media-Auth-Token in the INVITE message 138 from SIP-Proxy. 140 The UAS SHOULD use the Media-Auth-Token when requesting bandwidth for 141 media data stream during initiation and retaining of the bandwidth. 143 5.2.3. Originating Proxy (OP) 145 The Originating Proxy (OP) authenticates the caller, and verifies the 146 caller is authorized to receive the requested level of QoS. In 147 cooperation with originating Policy Decision Point (PDP-o), the OP 148 obtains a Media-Auth-Token that contains sufficient information for the 149 UAC to get the authorized bandwidth for the media streams. 151 DCS Group Category Informational _ Expiration 12/31/00 3 152 The Originating Proxy MUST insert the Media-Authorization header in the 153 response message that it sends to the UAC. 155 5.2.4. Destination Proxy (DP) 157 The Destination Proxy (DP) authenticates the called party, and verifies 158 the called party is authorized to receive the requested level of QoS. In 159 cooperation with termination Policy Decision Point (PDP-t), the DP 160 obtains a Media-Auth-Token that contains sufficient information for the 161 destination UAS to get the authorized bandwidth for the media streams. 163 The Destination Proxy MUST insert the Media-Authorization header in the 164 INVITE message that it sends to -the UAS. 166 6. Examples 168 6.1. Requesting Bandwidth via RSVP messaging 170 Resource Reservation Protocol (RSVP) is the end-to-end Layer 3 171 reservation protocol that is widely used [7]. 173 6.1.1. User Agent Client Side 175 Figure 1 presents a high-level overview of a basic call flow with Media 176 Authorization from the viewpoint of the UAC. It is assumed that the SIP- 177 Proxy has a previously established a authentication relationship with the 178 client. 180 When a user goes off-hook and dials a telephone number, the UAC collects 181 the dialed digits and sends the initial INVITE message to the Originating 182 SIP-Proxy. 184 The Originating SIP-Proxy (OP) authenticates UAC and forwards the INVITE 185 message to the proper SIP-proxy. 187 Assuming that the call is not forwarded, the other end-point sends a 183 188 response to the initial INVITE, forwarded back to OP. Included in this 189 response is the negotiated bandwidth requirement for the connection. 191 When OP receives the 183, it has sufficient information regarding the 192 end-points, bandwidth and characteristics of the media exchange. It 193 initiates a Policy-Setup message to PDP-o. 195 DCS Group Category Informational _ Expiration 12/31/00 4 196 UAC ER-o PDP-o OP 197 | Invite | | | Client Authentication 198 |------------------------------------------->| and Call Authorization 199 | | | | Invite 200 | | | |--------------> 201 | | | | 180/3 202 | | | Auth. Profile |<-------------- 203 | | |<--------------| 204 | | | Auth. Token | 205 | | |-------------->| Auth. Token put into 206 | | | 180/3 | Media-Authorization header 207 |<-------------------------------------------| extension. 208 |Copies the RSVP policy object | 209 |from the Media-Authorization | 210 | RSVP-PATHo | | | 211 |----------->| REQ | | 212 | |-------------->| Using the Auth-Token and Authorized 213 | | DEC | Profile that is set by the SIP Proxy 214 | |<--------------| the PDP makes the decision 215 | | | | RSVP-PATHo 216 | |------------------------------------------------> 217 | | | | RSVP-PATHt 218 |<-------------------------------------------------------------- 219 |Copies the RSVP policy object | 220 |from the Media-Authorization | 221 | RSVP-RESVt | | | 222 |----------->| REQ | | 223 | |-------------->| Using the Auth-Token and Authorized 224 | | DEC | Profile that is set by the SIP Proxy 225 | |<--------------| the PDP makes the decision 226 | | | | RSVP-RESVt 227 | |---------------------------------------------------> 228 | | | | RSVP-RESVo 229 |<---------------------------------------------------------------- 230 | | | | RSVP-RESVCONFo 231 |----------------------------------------------------------------> 232 | | | | RSVP-RESVCONFt 233 |<---------------------------------------------------------------- 234 | | | | 200 OK 235 |<-------------------------------------------|<------------------ 236 | | | | MEDIA 237 |<===============================================================> 238 | | | | ACK 239 |----------------------------------------------------------------> 241 Figure 1 243 DCS Group Category Informational _ Expiration 12/31/00 5 244 The PDP-o stores the authorized Media description in its local store 245 generates an Authorization-Token that points to this description and 246 returns the Authorization-Token to OP. 248 The OP includes the Authorization-Token in the Media-Auth-Token header 249 extension of the 183 message. 251 The UAC upon reception, stores the Media-Authorization-Token inside the 252 Media-Auth-Token header extension. 254 Before sending the Media stream, the UAC requests bandwidth using RSVP- 255 PATH message which includes the Session info that describes the Media 256 data-stream and TSpec that describes the bandwidth requested along with 257 Authorization information that was stored in Media-Authorization-Token. 259 ER-o, upon reception of the RSVP-PATHo message checks the authorization 260 through a PDP-o COPS message exchange. The PDP-o checks the authorization 261 using the stored authorized Media description that was linked to the 262 Authorization-Token that it returned to OP. If authorization is 263 successful PDP-o returns an "install" Decision. 265 ER-o checks the admissibility for the call and if admission succeeds, it 266 forwards the RSVP-PATHo message. 268 Once the UAC receives the RSVP-PATHt message it sends RSVP-RESVt message 269 to reserve the bandwidth. 271 ER-o, upon reception of the RSVP-RESVt message checks the authorization 272 through PDP-o COPS message exchange. The PDP-o checks the authorization 273 using the stored authorized Media description that was linked to 274 Authorization-Token that it returned to OP. If authorization is 275 successful PDP-o returns "install" Decision. 277 ER-o checks the admissibility for the call and if admission succeeds, it 278 forwards the RSVP-RESVt message. 280 Upon reception of RSVP-RESVo message the UAC sends RSVP-RESVCONFo message 281 to indicate that the reservation completed for one direction. 283 Upon reception of both RSVP-RESVCONFt and 200OK the UAC returns ACK 284 message. 286 6.1.2. User Agent Server Side 288 Figure 2 presents a high-level overview of a call flow with Media 289 Authorization from the viewpoint of the UAS. It is assumed that the SIP- 290 Proxy has a previously established authentication relationship with the - 291 UAS. 293 DCS Group Category Informational _ Expiration 12/31/00 6 294 UAS ER-t PDP-t DP 295 | | | | Invite 296 | | | |<-------------- 297 | | | | Proxy Authentication 298 | | | Auth. Profile | and Call Authorization 299 | | |<--------------| 300 | | | Auth. Token | 301 | | |-------------->| Auth. Token put into 302 | | | Invite | Media-Authorization header 303 |<------------------------------------------| extension 304 | 180/3 | | | 305 |------------------------------------------>| 180/3 306 |Copies the RSVP policy object |--------------> 307 |from the Media-Authorization | 308 | RSVP-PATHt| | | 309 |---------->| REQ | | 310 | |-------------->| Using the Auth-Token and Authorized 311 | | DEC | Profile that is set by the SIP Proxy 312 | |<--------------| the PDP makes the decision 313 | | | | RSVP-PATHt 314 | |--------------------------------------------------> 315 | | | | RSVP-PATHo 316 |<-------------------------------------------------------------- 317 |Copies the RSVP policy object | 318 |from the Media-Authorization | 319 | RSVP-RESVo| | | 320 |---------->| | | 321 | | REQ | | 322 | |-------------->| Using the Auth-Token and Authorized 323 | | DEC | Profile that is set by the SIP Proxy 324 | |<--------------| the PDP makes the decision 325 | | | | RSVP-RESVo 326 | |---------------------------------------------------> 327 | | | | RSVP-RESVt 328 |<--------------------------------------------------------------- 329 | | | | RSVP-RESVCONFt 330 |---------------------------------------------------------------> 331 | | | | RSVP-RESVCONFo 332 |<--------------------------------------------------------------- 333 | | | | 200 OK 334 |-----------------------------------------> |-------------------> 335 | | | | ACK 336 |<---------------------------------------------------------------- 337 Figure 2 339 DCS Group Category Informational _ Expiration 12/31/00 7 340 Since Destination SIP-Proxy (DP)has sufficient information regarding the 341 end-points, bandwidth and characteristics of the media exchange. It 342 initiates a Policy-Setup message to the termination Policy Decision Point 343 (PDP-t). 345 The PDP-t stores the authorized Media description in its local store 346 generates an Authorization-Token that points to this description and 347 returns the Authorization-Token to DP. 349 Assuming that the call is not forwarded, the UAS sends a 183 response to 350 the initial INVITE message, which is forwarded back to UAC. At the same 351 time UAS sends RSVP-PATHt message for Media data-stream that includes the 352 Session info that describes the Media data-stream and TSpec that 353 describes the bandwidth requested along with Authorization information 354 that was stored in Media-Authorization-Token. 356 ER-t upon reception of the RSVP-PATHt message checks the authorization 357 through a PDP-t COPS message exchange. The PDP-t checks the authorization 358 using the stored authorized Media description that was linked to 359 Authorization-Token that it returned to DP. If authorization is 360 successful PDP-t returns "install" Decision. 362 ER-t checks the admissibility for the call and if admission succeeds, it 363 forwards the RSVP-PATHt message. 365 Once UAS receives the RSVP-PATHo message it sends RSVP-RESVo message to 366 reserve the bandwidth. 368 ER-t upon reception of the RSVP-RESVo message checks the authorization 369 through a PDP-t COPS message exchange. The PDP-t checks the authorization 370 using the stored authorized Media description that was linked to 371 Authorization-Token that it returned to DP. If authorization is 372 successful PDP-t returns "install" Decision. 374 ER-t checks the admissibility for the call and if admission succeeds, it 375 forwards the RSVP- RESVo message. 377 Upon reception of RSVP-RESVd message the UAS sends RSVP-RESVCONFt message 378 to indicate that the reservation completed for one direction. 380 Upon reception of both RSVP-RESVCONFo and 200OK the UAS returns ACK 381 message. 383 6.2. Requesting Bandwidth via DOCSIS MAC messaging 385 The DOCSIS MAC layer [5] QoS Set-Up the call flows are different in the 386 sense that the Authorization token is a simple 32bit number [6]. And DSA- 387 REQ, DSA-RSP, and DSA-ACK are layer 2 messages that are specific to and 388 optimized for Cable environment which simplifies/reduces delays for the 389 embedded client implementation [6]. 391 DCS Group Category Informational _ Expiration 12/31/00 8 392 UAC ER/CMTSo OP 393 | Invite | | 394 |------------------------------------------->| Client Authentication 395 | | |and Call Authorization 396 | | | 397 | | | Invite 398 | | |-----------> 399 | | | 400 | | | 180/3 OK 401 | | |<------------ 402 | | | 403 | | Gate-Setup | 404 | |<--------------------- | 405 | | Gate-Setup-Ack | 406 | |---------------------> | 407 | | | GateID put into 408 | | | Media-Authorization header 409 | | | extension 410 | | 180/3 OK | 411 |<-------------------------------------------| 412 |Copies the GAteID object | 413 |from the Media-Authorization | 414 | | | 415 | DSA-REQ | | 416 |------------------->| | 417 | | Using the GateID and the Profile 418 | | communicated during Gate-Setup 419 | | the CMTS honors the request and creates 420 | DSA-RSP | a scheduler with appropriate settings 421 |<-------------------| | 422 | | | 423 | DSA-ACK | | 424 |------------------->| | 425 | | | 427 Figure 3 429 6.2.1. User Agent Client Side 431 Figure 3 presents a high-level overview of a call flow with Media 432 Authorization from the viewpoint of UAC . It is assumed that the SIP- 433 Proxy has a previously established authentication relationship with the 434 client. 436 When a user goes off-hook and dials a telephone number, the originating 437 SIP Client (UAC) collects the dialed digits and sends the initial INVITE 438 message to Originating SIP-Proxy. 440 DCS Group Category Informational _ Expiration 12/31/00 9 441 The Originating SIP-Proxy (OP) authenticates UAC and forwards the INVITE 442 message to the proper destination SIP-proxy. 444 Assuming that the call is not forwarded, the other end-point sends a 183 445 response to the initial INVITE, forwarded back to OP. Included in this 446 response is the negotiated bandwidth requirement for the connection. 447 UAS sends DSA-REQ message asking for bandwidth, which includes the 32 bit 448 index value. 450 ER/CMTSo, upon reception of the RSA-REQ message uses the index value to 451 find the authorized media description. Checks the requested media link 452 against authorized if the both authorization and admission succeeds it 453 starts a layer 2 link for Media data-stream on the Cable Access link and 454 returns DSA-RSP, which is acknowledged by UAC via DSA-ACK message. 456 Upon reception of 200OK the UAS returns ACK message. 458 6.2.2. User Agent Server Side 460 Figure 4 presents a high-level overview of a basic call flow with Media 461 Authorization from the viewpoint of UAS (UAS). It is assumed that the 462 Destination SIP-Proxy (DP) has a previously established authentication 463 relationship with the UAS. 465 When DP receives the INVITE message, it has sufficient information 466 regarding the end-points, bandwidth and characteristics of the media 467 exchange. It sends a Gate-Setup message to ER/CMTSt containing Media 468 data-stream description and bandwidth characteristics. The ER/CMTSt 469 returns a 32 bit index value that inside ER/CMTSt points to Media 470 definition that DP send out. 472 The DP includes the 32 bit index value in the Media-Auth-Token header 473 extension that its including into the INVITE message. 475 The UAS sends a 183 response to the initial INVITE, which is forwarded 476 back to UAC. At the same time UAS sends DSA-REQ message asking for 477 bandwidth which includes the 32 bit index value. 479 ER/CMTSt, upon reception of the RSA-REQ message uses the index value to 480 find the authorized media description. Checks the requested media link 481 against authorized if the both authorization and admission succeeds it 482 starts a layer 2 link for Media data-stream on the Cable Access link and 483 returns DSA-RSP, which is acknowledged by UAC via DSA-ACK message. Upon 484 reception of DSA-RSP the UAS returns ACK message. 486 DCS Group Category Informational _ Expiration 12/31/00 10 487 UAS ER/CMTSt DP 488 | | | 489 | | | Invite 490 | | |<----------- 491 | | | Proxy Authentication 492 | | | and Call Authorization 493 | | Gate-Setup | 494 | |<----------------------| 495 | | Gate-Setup-Ack | 496 | |---------------------->| 497 | | | GateID put into 498 | | | Media-Authorization header 499 | | | extension 500 | Invite | | 501 |<-------------------------------------------| 502 | | | 503 | | 180/3 | 504 |------------------------------------------->| 505 | | | 180/3 506 | | |------------> 507 |Copies the GateID object | 508 |from the Media-Authorization | 509 | | | 510 | DSA-REQ | 511 |------------------->| 512 | | Using the GateID and the Profile 513 | | communicated during Gate-Setup 514 | | the CMTS honors the request and creates 515 | DSA-RSP | a scheduler with appropriate settings 516 |<-------------------| 517 | | 518 | DSA-ACK | | 519 |------------------->| | 520 | | | 521 | | 200 OK | 522 |------------------------------------------->| 523 | | | 200 OK 524 | | |------------> 526 Figure 4 528 7. Advantages of the Proposed Approach 530 The use of call authorization makes it possible to control the 531 utilization of network resources. This in turn makes IP Telephony more 532 robust against denial of service attacks and various kinds of service 533 frauds. 535 DCS Group Category Informational _ Expiration 12/31/00 11 536 Using the authorization capability, the service provider can control the 537 number of flows, the amount of bandwidth, and the end-point reached 538 making the IP Telephony system dependable in the presence of scarce 539 resources. 541 8. Security Considerations 543 Media Authorization Tokens sent from a SIP-Proxy to a UAC/UAS MUST be 544 protected from eavesdropping, through a mechanism such as IPSec. 546 9. Notice Regarding Intellectual Property Rights 548 AT&T may seek patent or other intellectual property protection for some 549 or all of the technologies disclosed in the document. If any standards 550 arising from this disclosure are or become protected by one or more 551 patents assigned to AT&T, AT&T intends to disclose those patents and 552 license them on reasonable and non-discriminatory terms. Future revisions 553 of this draft may contain additional information regarding specific 554 intellectual property protection sought or received. 556 3COM may seek patent or other intellectual property protection for some 557 or all of the technologies disclosed in the document. If any standards 558 arising from this disclosure are or become protected by one or more 559 patents assigned to 3COM, 3COM intends to disclose those patents and 560 license them on reasonable and non-discriminatory terms. Future revisions 561 of this draft may contain additional information regarding specific 562 intellectual property protection sought or received. 564 10. Reference 566 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, 567 RFC 2026, October 1996. 569 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 570 Levels", BCP 14, RFC 2119, March 1997 572 3 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 573 Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon 574 Internet Ltd., November 1997 576 4 M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 577 session initiation protocol,"Request for Comments (Proposed 578 Standard) 2543, Internet Engineering Task Force, Mar. 1999. 580 5 CableLabs, "Data-Over-Cable Service Interface Specifications, Radio 581 Frequency Interface Specification, SP-RFIv1.1-I04-000407", April 2000. 583 6 PacketCable, Dynamic Quality of Service Specification, pkt-sp-dqos- 584 i01-991201, December 1, 1999. 586 7 RFC 2210, The Use of RSVP with IETF Integrated Services by J. 587 Wroclawski, September 1997. 589 DCS Group Category Informational _ Expiration 12/31/00 12 590 11. Acknowledgments 592 The Distributed Call Signaling work in the PacketCable project is 593 the work of a large number of people, representing many different 594 companies. The authors would like to recognize and thank the 595 following for their assistance: John Wheeler, Motorola; David 596 Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, 597 Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, 598 Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; 599 Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho, 600 Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung- 601 Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent 602 Cable Communications. 604 13. Author's Addresses 606 Bill Marshall 607 AT&T 608 Florham Park, NJ 07932 609 Email: wtm@research.att.com 611 K. K. Ramakrishnan 612 AT&T 613 Florham Park, NJ 07932 614 Email: kkrama@research.att.com 616 Ed Miller 617 CableLabs 618 Louisville, CO 80027 619 Email: E.Miller@Cablelabs.com 621 Glenn Russell 622 CableLabs 623 Louisville, CO 80027 624 Email: G.Russell@Cablelabs.com 626 Burcak Beser 627 3Com 628 Mount Prospect, IL 60004 629 Email: Burcak_Beser@3com.com 631 Mike Mannette 632 3Com 633 Rolling Meadows, IL 60008 634 Email: Michael_Mannette@3com.com 636 Kurt Steinbrenner 637 3Com 638 Rolling Meadows, IL 60008 639 Email: Kurt_Steinbrenner@3com.com 641 DCS Group Category Informational _ Expiration 12/31/00 13 642 Dave Oran 643 Cisco 644 Acton, MA 01720 645 Email: oran@cisco.com 647 Flemming Andreasen 648 Cisco 649 Edison, NJ 650 Email: fandreas@cisco.com 652 John Pickens 653 Com21 654 San Jose, CA 655 Email: jpickens@com21.com 657 Poornima Lalwaney 658 Nokia 659 San Diego, CA 92121 660 Email: poornima.lalwaney@nokia.com 662 Jon Fellows 663 Motorola 664 San Diego, CA 92121 665 Email: jfellows@gi.com 667 Doc Evans 668 Secure Cable Solutions 669 Westminster, CO 30120 670 Email: drevans@securecable.com 672 Keith Kelly 673 NetSpeak 674 Boca Raton, FL 33587 675 Email: keith@netspeak.com 677 DCS Group Category Informational _ Expiration 12/31/00 14 678 Full Copyright Statement 680 "Copyright (C) The Internet Society (date). All Rights Reserved. 681 This document and translations of it may be copied and furnished to 682 others, and derivative works that comment on or otherwise explain it 683 or assist in its implmentation may be prepared, copied, published 684 and distributed, in whole or in part, without restriction of any 685 kind, provided that the above copyright notice and this paragraph 686 are included on all such copies and derivative works. However, this 687 document itself may not be modified in any way, such as by removing 688 the copyright notice or references to the Internet Society or other 689 Internet organizations, except as needed for the purpose of 690 developing Internet standards in which case the procedures for 691 copyrights defined in the Internet Standards process must be 692 followed, or as required to translate it into languages other than 693 English. The limited permissions granted above are perpetual and 694 will not be revoked by the Internet Society or its successors or 695 assigns. This document and the information contained herein is 696 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 697 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 698 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 699 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 700 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 702 Expiration Date This memo is filed as , and expires December 31, 2000. 705 DCS Group Category Informational _ Expiration 12/31/00 15