idnits 2.17.1 draft-ietf-rap-cops-rsvp-05.txt: 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 11) being 63 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages 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.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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.) -- The document date (June 14, 1999) is 9080 days in the past. Is this intentional? 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: 'MD5' is mentioned on line 422, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-rap-rsvp-ext-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'RAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'COPS' Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Jim Boyle 2 Expiration: December 1999 Level3 3 File: draft-ietf-rap-cops-rsvp-05.txt Ron Cohen 4 Cisco 5 David Durham 6 Intel 7 Shai Herzog 8 IPHighway 9 Raju Rajan 10 AT&T 11 Arun Sastry 12 Cisco 14 COPS usage for RSVP 16 June 14, 1999 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with all 21 provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering Task 24 Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference material 30 or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 This document describes usage directives for supporting COPS policy 41 services in RSVP environments. 43 Internet Draft COPS usage for RSVP 14-Jun-99 45 Table of Contents 47 Abstract.............................................................1 48 Table of Contents....................................................2 49 1 Introduction.......................................................3 50 2 RSVP values for COPS objects.......................................3 51 2.1 Common Header, client-type......................................3 52 2.2 Context Object (Context)........................................3 53 2.3 Client Specific Information (ClientSI)..........................4 54 2.4 Decision Object (Decision)......................................5 55 3 Operation of COPS for RSVP PEPs....................................6 56 3.1 RSVP flows......................................................6 57 3.2 Expected Associations for RSVP Requests.........................6 58 3.3 RSVP's Capacity Admission Control: Commit and Delete............7 59 3.4 Policy Control Over PathTear and ResvTear.......................7 60 3.5 PEP Caching COPS Decisions......................................7 61 3.6 Using Multiple Context Flags in a single query..................8 62 3.7 RSVP Error Reporting............................................9 63 4 Security Considerations............................................9 64 5 Illustrative Examples, Using COPS for RSVP........................10 65 5.1 Unicast Flow Example...........................................10 66 5.2 Shared Multicast Flows.........................................12 67 6 References........................................................15 68 7 Author Information and Acknowledgments............................15 70 Internet Draft COPS usage for RSVP 14-Jun-99 72 1 Introduction 74 The Common Open Policy Service (COPS) protocol is a query response 75 protocol used to exchange policy information between a network 76 policy server and a set of clients [COPS]. COPS is being developed 77 within the RSVP Admission Policy Working Group (RAP WG) of the IETF, 78 primarily for use as a mechanism for providing policy-based 79 admission control over requests for network resources [RAP]. 81 This document is based on and assumes prior knowledge of the RAP 82 framework [RAP] and the basic COPS [COPS] protocol. It provides 83 specific usage directives for using COPS in outsourcing policy 84 control decisions by RSVP clients (PEPs) to policy servers (PDPs). 86 Given the COPS protocol design, RSVP directives are mainly limited 87 to RSVP applicability, interoperability and usage guidelines, as 88 well as client specific examples. 90 2 RSVP values for COPS objects 92 The usage of several COPS objects is affected when used the RSVP 93 client type. This section describes these objects and their usage. 95 2.1 Common Header, client-type 97 RSVP is COPS client-type 1 99 2.2 Context Object (Context) 101 The semantics of the Context object for RSVP is as follows: 103 R-Type (Request Type Flag) 105 Incoming-Message request 107 This context is used when the PEP receives an incoming RSVP 108 message. The PDP may decide to accept or reject the incoming 109 message and may also apply other decision objects to it. If 110 the incoming message is rejected, RSVP should treat it as if 111 it never arrived. 113 Resource-Allocation request 115 This context is used when the PEP is about to commit local 116 resources to an RSVP flow (admission control). This context 117 applies to Resv messages only. The decision whether to commit 118 local resources is made for the merge of all reservations 119 associated with an RSVP flow (which have arrived on a 120 particular interface, potentially from several RSVP Next- 121 Hops). 123 Outgoing-Message request (forwarding an outgoing RSVP message) 125 This context is used when the PEP is about to forward an 126 outgoing RSVP message. The PDP may decide to allow or deny 128 Internet Draft COPS usage for RSVP 14-Jun-99 130 the outgoing message, as well as provide an outgoing policy 131 data object. 133 M-Type (Message Type) 135 The M-Type field in the Context Object identifies the applicable 136 RSVP message type. M-Type values are identical to the values used in 137 the "msg type" field in the RSVP header [RSVP]. 139 The following RSVP message types are supported in COPS: 141 Path 142 Resv 143 PathErr 144 ResvErr 146 Other message types such as PathTear, ResvTear, and Resv Confirm are 147 not supported. The list of supported message types can only be 148 extended in later versions of RSVP and/or later version of this 149 document. 151 2.3 Client Specific Information (ClientSI) 153 All objects that were received in an RSVP message are encapsulated 154 inside the Client Specific Information Object (Signaled ClientSI) 155 sent from the PEP to the remote PDP (see Section 3.1. on multiple 156 flows packed in a single RSVP message). 158 The PEP and PDP share RSVP state, and the PDP is assumed to 159 implement the same RSVP functional specification as the PEP. In the 160 case where a PDP detects the absence of objects required by [RSVP] 161 it should return an in the Decision message indicating 162 "Mandatory client-specific info missing". If, on the other hand, the 163 PDP detects the absence of optional RSVP objects that are needed to 164 approve the Request against current policies, the PDP should return 165 a negative . 167 Unlike the Incoming and Outgoing contexts, "Resource Allocation" is 168 not always directly associated with a specific RSVP message. In a 169 multicast session, it may represent the merging of multiple incoming 170 reservations. Therefore, the ClientSI object should specifically 171 contain the SESSION and STYLE objects along with the merged 172 FLOWSPEC, FILTERSPEC list, and SCOPE object (whenever relevant). 174 Internet Draft COPS usage for RSVP 14-Jun-99 176 2.4 Decision Object (Decision) 178 COPS provides the PDP with flexible controls over the PEP using 179 RSVP's response to messages. While accepting an RSVP message, PDPs 180 may provide preemption priority, trigger warnings, replace RSVP 181 objects, and much more, using Decision Commands, Flags, and Objects. 183 DECISION COMMANDS 185 Only two commands apply to RSVP 187 Install 189 Positive Response: 190 Accept/Allow/Admit an RSVP message or local resource allocation. 192 Remove 194 Negative Response: 195 Deny/Reject/Remove an RSVP message or local resource allocation. 197 DECISION FLAGS 199 The only decision flag that applies to RSVP: 201 Trigger Error 203 If this flag is set, RSVP should schedule a PathErr, in response 204 to a Path message, or a ResvErr (in response of a Resv message). 206 STATELESS POLICY DATA 208 This object may include one or more policy elements (as specified 209 for the RSVP Policy Data object [RSVP-EXT]) which are assumed to be 210 well understood by the client's LDP. The PEP should consider these 211 as an addition to the decision already received from the PDP (it can 212 only add, but cannot override it). 214 For example, given Policy Elements that specify a flow's preemption 215 priority, these elements may be included in an incoming Resv message 216 or may be provided by the PDP responding to a query. 218 Stateless objects must be well understood, but not necessarily 219 supported by all PEPs. For example, assuming a standard policy 220 element for preemption priority, it is perfectly legitimate for some 221 PEPs not to support such preemption and to ignore it. The PDP must 222 be careful when using such objects. In particular, it must be 223 prepared for these objects to be ignored by PEPs. 225 Stateless Policy Data may be returned in decisions and apply 226 individually to each of the contexts flagged in REQ messages. When 227 applied to Incoming, it is assumed to have been received as a 228 POLICY_DATA object in the incoming message. When applied to Resource 230 Internet Draft COPS usage for RSVP 14-Jun-99 232 Allocation it is assumed to have been received on all merged 233 incoming messages. Last, when applied to outgoing messages it is 234 assumed to have been received in all messages contributing to the 235 outgoing message. 237 REPLACEMENT DATA 239 The Replacement object may contain multiple RSVP objects to be 240 replaced (from the original RSVP request). Typical replacement is 241 performed on the "Forward Outgoing" request (for instance, replacing 242 outgoing Policy Data), but is not limited, and can also be performed 243 on other contexts (such as "Resources-Allocation Request"). In other 244 cases, replacement of the RSVP FlowSpec object may be useful for 245 controlling resources across a trusted zone (with policy ignorant 246 nodes (PINs). Currently, RSVP clients are only required to allow 247 replacement of three objects: POLICY_DATA, ERROR_SPEC, and FLOWSPEC, 248 but could optionally support replacement of other objects. 250 RSVP object replacement is performed in the following manner: 252 If no Replacement Data decision appears in a decision message, all 253 signaled objects are processed as if the PDP was not there. When an 254 object of a certain C-Num appears, it replaces ALL the instances of 255 C-Num objects in the RSVP message. If it appears empty (with a 256 length of 4) it simply removes all instances of C-Num objects 257 without adding anything. 259 3 Operation of COPS for RSVP PEPs 261 3.1 RSVP flows 263 Policy Control is performed per RSVP flow, which is defined by the 264 atomic unit of an RSVP reservation (TC reservation). Reservation 265 styles may also impact the definition of flows; a set of senders 266 which are considered as a single flow for WF reservation are 267 considered as a set of individual flows when FF style is used. 269 Multiple FF flows may be packed into a single Resv message. A packed 270 message must be unpacked where a separate request is issued for each 271 of the packed flows as if they were individual RSVP messages. Each 272 COPS Request should include the associated POLICY_DATA objects, 273 which are, by default, all POLICY_DATA objects in the packed 274 message. Sophisticated PEPs, capable of looking inside policy 275 objects, may examine the POLICY_DATA or SCOPE object to narrow down 276 the list of associated flows (as an optimization). 278 Please note that the rules governing Packed RSVP message apply 279 equally to the Incoming as well as the Outgoing REQ context. 281 3.2 Expected Associations for RSVP Requests 283 When making a policy decision, the PDP may consider both Resv as 284 well as its matching Path state (associated state). State 285 association is straightforward in the common unicast case since the 286 RSVP flow includes one Path state and one Resv state. In multicast 288 Internet Draft COPS usage for RSVP 14-Jun-99 290 cases this correspondence may be more complicated, as the match may 291 be many-to-many. The COPS protocol assumes that the PDP is RSVP 292 knowledgeable and capable of determining these associations based on 293 the contents of the Client REQ message and especially the ClientSI 294 object. 296 For example, the PDP should be able to recognize activation and 297 deactivation of RSVP blockade state following discrete events like 298 the arrival of a ResvErr message (activate the blockade state) as 299 well as the change in the outgoing Resv message. 301 3.3 RSVP's Capacity Admission Control: Commit and Delete 303 In RSVP, the admission of a new reservation requires both an 304 administrative approval (policy control) and capacity admission 305 control. After being approved by both, and after the reservation was 306 successfully installed, the PEP notifies the remote PDP by sending a 307 report message specifying the Commit type. The Commit type report 308 message signals when billing should effectively begin and performing 309 heavier delayed operations (e.g., debiting a credit card) is 310 permissible by the PDP. 312 If, instead, a PDP approved reservation fails admission due to lack 313 of resources, the PEP must issue a no-commit report and fold back 314 and send an updated request to its previous state (previously 315 installed reservation). If no state was previously installed, the 316 PEP should issue a delete (DRQ). 318 3.4 Policy Control Over PathTear and ResvTear 320 PathTear and ResvTear messages are not controlled by this policy 321 architecture. This relies on two assumptions: First, that MD-5 322 authentication verifies that the Tear is received from the same node 323 that sent the initial reservation, and second, that it is 324 functionally equivalent to that node holding off refreshes for this 325 reservation. When a ResvTear or PathTear is received at the PEP, all 326 affected states installed on the PDP should either be deleted or 327 updated by the PEP. 329 3.5 PEP Caching COPS Decisions 331 Because COPS is a stateful protocol, refreshes for RSVP Path and 332 Resv messages need not be constantly sent to the remote PDP. Once a 333 decision has been returned for a request, the PEP can cache that 334 decision and apply it to future refreshes. When the PEP detects a 335 change in the corresponding Resv or Path message, it should update 336 the PDP with the new request-state. PEPs may continue to use the 337 cached state until receiving the PDP response. This case is very 338 different from initial admission of a flow; given that valid 339 credentials and authentication have already been established, the 340 relatively long RSVP refresh period, and the short PEP-PDP response 341 time, the tradeoff between expedient updates and attack prevention 342 leans toward expediency. However, this is really a PEP choice, and 343 is irrelevant to PDPs. 345 Internet Draft COPS usage for RSVP 14-Jun-99 347 If the connection is lost between the PEP and the PDP, the cached 348 RSVP state may be retained for the RSVP timeout period to be used 349 for previously admitted flows (but cannot be applied to new or 350 updated state). If the connection can not be reestablished with the 351 PDP or a backup PDP after the timeout period, the PEP is expected to 352 purge all its cached decisions. Without applicable cached decision, 353 the PEP must either reject the flow or resort to its LDP (if 354 available) for decisions. 356 Once a connection is reestablished to a new (or the original) PDP 357 the PDP may issue a SSQ request. In this case, the PEP must reissue 358 requests that correspond to the current RSVP state (as if all the 359 state has been updated recently). It should also include as LDP the 360 current (cached) decision regarding each such state. 362 3.6 Using Multiple Context Flags in a single query 364 RSVP is a store-and-forward control protocol where messages are 365 processed in three distinctive steps (input, resource allocation, 366 and output). Each step requires a separate policy decision as 367 indicated by context flags (see Section 2.2). In many cases, setting 368 multiple context flags for bundling two or three operations together 369 in one request may significantly optimize protocol operations. 371 The following rules apply for setting multiple Context flags: 373 a. Multiple context flags can be set only in two generic cases, 374 which represent a substantial portion of expected COPS 375 transactions, and can be guaranteed not to cause ambiguity. 377 Unicast FF: 379 [Incoming + Allocation + Outgoing] 381 Multicast with only one Resv message received on the interface 383 [Incoming + Allocation] 385 b. Context events are ordered by time since every message must first 386 be processed as Incoming, then as Resource allocation and only 387 then as Outgoing. When multiple context flags are set, all 388 ClientSI objects included in the request are assumed to be 389 processed according to the latest flag. This rule applies both to 390 the request (REQ) context as well as to the decision (DEC) 391 context. 393 For example, when combining Incoming + Allocation for an incoming 394 Resv message, the flowspec included in the ClientSI would be the 395 one corresponding to the Resource-Allocation context (TC). 397 Internet Draft COPS usage for RSVP 14-Jun-99 399 c. Each decision is bound to a context object, which determines 400 which portion of the request context it applies to. When 401 individual decisions apply to different sub-groups of the 402 context, the PDP should send each group of decision objects 403 encapsulated by the context flags object with the context flags 404 applicable to these objects set (see the examples in Section 5). 406 3.7 RSVP Error Reporting 408 RSVP uses the ERROR_SPEC object in PathErr and ResvErr messages to 409 report policy errors. While the contents of the ERROR_SPEC object 410 are defined in [RSVP,RSVP-EXT], the PDP is in the best position to 411 provide its contents (sub-codes). This is performed in the following 412 manner: First, the PEP (RSVP) queries the PDP before sending a 413 PathErr or ResvErr, and then the PDP returns the constructed 414 ERROR_SPEC in the Replacement Data Decision Object. 416 4 Security Considerations 418 This document relies on COPS for its signaling and its security. 419 Please refer to section "Security Considerations" in [COPS]. 421 Security for RSVP messages is provided by inter-router MD5 422 authentication [MD5], assuming a chain-of-trust model. 423 A likely deployment scenario calls for PEPs to be deployed only at 424 the network edge (boundary nodes) while the core of the network 425 (backbone) consists of PIN nodes. In this scenario MD5 trust 426 (authentication) is established between boundary (non-neighboring) 427 PEPs. Such trust can be achieved through internal signing 428 (integrity) of the Policy Data object itself, which is left 429 unmodified as it passes through PIN nodes (see [RSVP-EXT]). 431 Internet Draft COPS usage for RSVP 14-Jun-99 433 5 Illustrative Examples, Using COPS for RSVP 435 This section details both typical unicast and multicast scenarios. 437 5.1 Unicast Flow Example 439 This section details the steps in using COPS for controlling a 440 Unicast RSVP flow. It details the contents of the COPS messages 441 with respect to Figure 1. 443 PEP (router) 444 +-----------------+ 445 | | 446 R1 ------------+if1 if2+------------ S1 447 | | 448 +-----------------+ 450 Figure 1: Unicast Example: a single PEP view 452 The PEP router has two interfaces (if1, if2). Sender S1 sends to 453 receiver R1. 455 A Path message arrives from S1: 457 PEP --> PDP REQ := 458 459 461 PDP --> PEP DEC := 462 464 A Resv message arrives from R1: 466 PEP --> PDP REQ := 467 468 469 471 PDP --> PEP DEC := 472 473 474 475 476 477 478 479 481 PEP --> PDP RPT := 482 484 Notice that the Decision was split because of the need to specify 485 different decision objects for different context flags. 487 Time Passes, the PDP changes its decision: 489 Internet Draft COPS usage for RSVP 14-Jun-99 491 PDP --> PEP DEC := 492 493 494 496 Because the priority is too low, the PEP preempts the flow: 498 PEP --> PDP DRQ := 499 501 Time Passes, the sender S1 ceases to send Path messages: 503 PEP --> PDP DRQ := 504 506 Internet Draft COPS usage for RSVP 14-Jun-99 508 5.2 Shared Multicast Flows 510 This section details the steps in using COPS for controlling a 511 multicast RSVP flow. It details the contents of the COPS messages 512 with respect to Figure 2. 514 PEP (router) 515 +-----------------+ 516 | | 517 R1-------------+ if1 if3 +--------- S1 518 | | 519 R2----+ | | 520 | | | 521 +--------+ if2 if4 +--------- S2 522 | | | 523 R3----+ +-----------------+ 525 Figure 2: Multicast example: a single PEP view 527 Figure 2 shows an RSVP PEP (router) which has two senders (S1, S2) 528 and three receivers (R1, R2, R3) for the same multicast session. 529 Interface if2 is connected to a shared media. 530 In this example, we assume that the multicast membership is already 531 in place. No previous RSVP messages were received, and the first to 532 arrive is a Path message on interface if3 from sender S1: 534 PEP --> PDP REQ := 535 536 538 PDP --> PEP DEC := 539 541 The PEP consults its forwarding table, and finds two outgoing 542 interface for the path (if1, if2). The exchange below is for 543 interface if1, another exchange would likewise be completed for if2 544 using the new handle B2. 546 PEP --> PDP REQ := 547 548 550 PDP --> PEP DEC := 551 552 553 555 Internet Draft COPS usage for RSVP 14-Jun-99 557 Here, the PDP decided to allow the forwarding of the Path message 558 and provided the appropriate policy-data object for interface if1. 560 Next, a WF Resv message from receiver R2 arrives on interface if2. 562 PEP --> PDP REQ := 563 564 567 PDP --> PEP DEC := 568 569 570 571 572 574 PEP --> PDP RPT := 576 Here, the PDP approves the reservation and assigned it preemption 577 priority of 5. The PEP responded with a commit report. 579 The PEP needs to forward the Resv message upstream toward S1: 581 PEP --> PDP REQ := 582 583 585 PDP --> PEP DEC := 586 587 588 590 Note: The Context object is part of this DEC message even though it 591 may look redundant since the REQ specified only one context flag. 593 Next, a new WF Resv message from receiver R3 arrives on interface 594 if2 with a higher RSpec (Rspec2). Given two reservations arrived on 595 if2, it cannot perform a request with multiple context flags, and 596 must issue them separately. 598 Internet Draft COPS usage for RSVP 14-Jun-99 600 The PEP re-issues an updated handle C REQ with a new context object 601 , and receives a DEC for handle C. 603 PEP --> PDP REQ := 604 605 608 PDP --> PEP DEC := 609 611 PEP --> PDP REQ := 612 613 616 PDP --> PEP DEC := 617 618 619 621 PEP --> PDP RPT := 623 Given the change in incoming reservations, the PEP needs to forward 624 a new outgoing Resv message upstream toward S1. This repeats exactly 625 the previous interaction of Handle E, except that the ClientSI 626 objects now reflect the merging of two reservations. 628 If an ResvErr arrives from S1, the PEP maps it to R3 only (because 629 it has a higher flowspec: Rspec2) the following takes place: 631 PEP --> PDP REQ := 632 633 635 PDP --> PEP DEC := 636 638 PEP --> PDP REQ := 639 640 642 PDP --> PEP DEC := 643 644 645 647 When S2 joins the session by sending a Path message, incoming and 648 outgoing Path requests are issued for the new Path. A new outgoing 649 Resv request would be sent to S2. 651 Internet Draft COPS usage for RSVP 14-Jun-99 653 6 References 655 [RSVP-EXT] Herzog, S. "RSVP Extensions for Policy Control", 656 Internet-Draft, draft-ietf-rap-rsvp-ext-02.txt, Jan. 1999. 658 [RAP] Yavatkar, R., et al., "A Framework for Policy Based 659 Admission Control", IETF , 660 Jan., 1999. 662 [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R., 663 Sastry, A., "The COPS (Common Open Policy Service) Protocol", 664 IETF , Jan. 1999. 666 [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - 667 Functional Specification.", IETF RFC 2205, Proposed Standard, 668 Sep. 1997. 670 7 Author Information and Acknowledgments 672 Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs, 673 Fred Baker, Laura Cunningham, Russell Fenger, Roch Guerin, Ping Pan, 674 and Raj Yavatkar, for their valuable contributions. 676 Jim Boyle Ron Cohen 677 Level 3 Communications CISCO Systems 678 1450 Infinite Drive13 Hasadna St. 679 Louisville, CO 80027 Ra'anana 43650 Israel 680 303.926.3100 972.9.7462020 681 email: jboyle@l3.net ronc@cisco.com 683 David Durham Raju Rajan 684 Intel AT&T Labs Research 685 2111 NE 25th Avenue 180 Park Ave., P.O. Box 971 686 Hillsboro, OR 97124 Florham Park, NJ 07932 687 503.264.6232 973.360.7229 688 David_Durham@mail.intel.com raju@research.att.com 690 Shai Herzog Arun Sastry 691 IPHighway Cisco Systems 692 400 Kelby St., Suite 1500 506210 W Tasman Drive 693 Fort-Lee, NJ 07024 San Jose, CA 95134 694 201.585.0800 408.526.7685 695 herzog@iphighway.com asastry@cisco.com