idnits 2.17.1 draft-ietf-rap-cops-rsvp-04.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 12) being 61 lines 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 (February 26, 1999) is 9190 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 424, 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 (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Jim Boyle 3 Expiration: August 1999 Level3 4 File: draft-ietf-rap-cops-rsvp-04.txt Ron Cohen 5 Cisco 6 David Durham 7 Intel 8 Shai Herzog 9 IPHighway 10 Raju Rajan 11 IBM 12 Arun Sastry 13 Cisco 15 COPS usage for RSVP 17 February 26, 1999 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with all 22 provisions of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering Task 25 Force (IETF), its areas, and its working groups. Note that other 26 groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference material 31 or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This document describes usage directives for supporting COPS policy 42 services in RSVP environments. 44 Internet Draft COPS usage for RSVP 26-Feb-99 46 Table of Contents 48 Abstract.............................................................1 49 Table of Contents....................................................2 50 1 Introduction.......................................................3 51 2 RSVP values for COPS objects.......................................3 52 2.1 Common Header, client-type......................................3 53 2.2 Context Object (Context)........................................3 54 2.3 Client Specific Information (ClientSI)..........................4 55 2.4 Decision Object (Decision)......................................5 56 3 Operation of COPS for RSVP PEPs....................................6 57 3.1 RSVP flows......................................................6 58 3.2 Expected Associations for RSVP Requests.........................6 59 3.3 RSVP's Capacity Admission Control: Commit and Delete............7 60 3.4 Policy Control Over PathTear and ResvTear.......................8 61 3.5 PEP Caching COPS Decisions......................................8 62 3.6 Using Multiple Context Flags in a single query..................9 63 3.7 RSVP Error Reporting...........................................10 64 4 Security Considerations...........................................10 65 5 Illustrative Examples, Using COPS for RSVP........................11 66 5.1 Unicast Flow Example...........................................11 67 5.2 Shared Multicast Flows.........................................13 68 6 References........................................................16 69 7 Author Information and Acknowledgments............................16 70 Internet Draft COPS usage for RSVP 26-Feb-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, usage guidelines, as well 88 as client specific examples. 90 2 RSVP values for COPS objects 92 The usage of several COPS objects is affected when used for client 93 type RSVP. 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 requested when the PEP receives an incoming 108 RSVP message. The PDP may decide to accept or reject the 109 incoming message and may also apply other decision object to 110 it. If the incoming message is rejected, RSVP should treat it 111 as if it never arrived. 113 Resource-Allocation request 115 This context is requested when the PEP is about to commit 116 local resources to an RSVP flow (admission control). This 117 context applies to Resv messages only. The decision whether 118 to commit local resources is performed for the merge of all 119 reservations associated with an RSVP flow, (which have 120 arrived on a particular interface, potentially from several 121 RSVP Next-Hops). 123 Outgoing-Message request (forwarding an outgoing RSVP message) 125 This context is requested 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 26-Feb-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 derived from, and are identical 137 to the values used in the "msg type" field in the RSVP header 138 [RSVP]. 140 The following RSVP message types are supported in COPS: 142 Path 143 Resv 144 PathErr 145 ResvErr 147 Other message types such as PathTear, ResvTear, and Resv Confirm 148 message types are not supported. The list of supported message types 149 cannot be expended other than by later versions of RSVP and/or later 150 version of this document. 152 2.3 Client Specific Information (ClientSI) 154 All objects that were received within an RSVP message are 155 encapsulated inside the Client Specific Information Object (Signaled 156 ClientSI) sent from the PEP to the remote PDP. (See Section 3.1. on 157 multiple flows packed in a single RSVP message). 159 The PEP and PDP share RSVP state and the PDP is assumed to implement 160 the same RSVP functional specification as the PEP. In the case where 161 a PDP detects the absence of objects required by [RSVP] it should 162 return an in the Decision message indicating "Mandatory 163 client-specific info missing". If, on the other hand, the PDP 164 detects the absence of optional RSVP objects that are needed to 165 approve the Request against current policies, the PDP should return 166 a negative . 168 Unlike the Incoming and Outgoing contexts, "Resource Allocation" 169 isn't always directly associated with a specific RSVP message. In a 170 multicast session, it may represent the merging of multiple incoming 171 reservations. Therefore, the ClientSI object should specifically 172 contain the SESSION and STYLE objects along with the merged 173 FLOWSPEC, FILTERSPEC list and SCOPE object (whenever relevant). 175 Internet Draft COPS usage for RSVP 26-Feb-99 177 2.4 Decision Object (Decision) 179 COPS provide the PDP with flexible controls over the PEP using 180 RSVP's response to messages. While accepting an RSVP message, PDPs 181 may provide preemption priority, trigger warnings, replace RSVP 182 objects, and much more, using Decision Commands, Flags and Objects. 184 DECISION COMMANDS 186 Only two commands apply to RSVP 188 Install 190 Positive Response: 191 Accept/Allow/Admit an RSVP message or local resource allocation. 193 Remove 195 Negative Response: 196 Deny/Reject/Remove an RSVP message or local resource allocation. 198 DECISION FLAGS 200 The only decision flag that applies to RSVP: 202 Trigger Error 204 If this flag is set, RSVP should schedule a PathErr, in response 205 of a Path message, or a ResvErr (in response of a Resv message). 207 STATELESS POLICY DATA 209 This object may include one or more policy elements (as specified 210 for the RSVP Policy Data object [RSVP-EXT]) which are assumed to be 211 well understood by the client's LDP. The PEP should consider these 212 as an addition to the decision already received from the PDP (it can 213 only add, but cannot override it). 215 For example: Given Policy Elements that specify a flow's preemption 216 priority, these elements may be included in an incoming Resv message 217 or may be also be provided by the PDP responding to a query. 219 Stateless objects must be well understood, but not necessarily 220 supported by all PEPs. For example, assuming a standard policy 221 element for preemption priority, it is perfectly legitimate for some 222 PEPs not to support such preemption and to ignore it. The PDP must 223 be careful when using such objects, especially, it must be prepared 224 for these objects would be ignored by PEPs. 226 Stateless Policy Data may be returned in decisions and apply 227 individually to each of the contexts flagged in REQ messages. When 228 applied to Incoming, it is assumed to have been received as a 229 POLICY_DATA object in the incoming message. When applied to Resource 231 Internet Draft COPS usage for RSVP 26-Feb-99 233 Allocation it is assumed to have been received on all merged 234 incoming messages. Last, when applied to outgoing message it is 235 assumed to have been received in all messages contributing to the 236 outgoing message. 238 REPLACEMENT DATA 240 The Replacement object may contain multiple RSVP objects to be 241 replaced (from the original RSVP request). Typical replacement is 242 performed on the "Forward Outgoing" request (for instance, replacing 243 outgoing Policy Data), but is not limited, and can also be performed 244 on other contexts (such as "Resources-Allocation Request"). In other 245 cases, replacement of the RSVP FlowSpec object may be useful for 246 controlling resources across a trusted zone (with policy ignorant 247 nodes (PINs). Currently, RSVP clients are only required to allow 248 replacement of three objects: POLICY_DATA, ERROR_SPEC, and FLOWSPEC, 249 but could optionally support replacement of more objects. 251 RSVP object replacement is performed in the following manner: 253 If Replacement Data decision doesn't appear in a decision message, 254 all signaled objects are processed as if the PDP was not there. When 255 an object of a certain C-Num appears it replaces ALL the instances 256 of C-Num objects in the RSVP message. If it appears empty (with a 257 length of 4) it simply removes all instances of C-Num objects 258 without adding a thing. 260 3 Operation of COPS for RSVP PEPs 262 3.1 RSVP flows 264 Policy Control is performed per RSVP flow, which is defined by the 265 atomic unit of RSVP reservation (TC reservation). Reservation styles 266 may also impact the definition of flows; a set of senders which are 267 considered as a single flow for WF reservation are considered as a 268 set of individual flows when FF style is used. 270 Multiple FF flows may be packed into a single Resv message. A packed 271 message must be unpack where a separate request is issued for each 272 of the packed flows as if they were individual RSVP messages. Each 273 COPS Request should include the associated POLICY_DATA objects, 274 which are, by default, all POLICY_DATA objects in the packed 275 message. Sophisticated PEPs, capable of looking inside policy 276 objects, may examine the POLICY_DATA or SCOPE object to narrow down 277 the list of associated flows (as optimization). 279 Please note that the rules governing Packed RSVP message apply 280 equally to Incoming as well as Outgoing REQ context. 282 3.2 Expected Associations for RSVP Requests 284 When making a policy decision, the PDP may consider both Resv as 285 well as its matching Path state (associated state). State 286 association is straightforward in the common unicast case since the 287 RSVP flow includes one Path state and one Resv state. In multicast 289 Internet Draft COPS usage for RSVP 26-Feb-99 291 cases this correspondence may be more complicated, as the match may 292 be many to many. The COPS protocol assumes that the PDP is RSVP 293 knowledgeable and capable of determining these associations based on 294 the contents of the Client REQ message and especially the ClientSI 295 object. 297 For example, the PDP should be able to recognize activation and 298 deactivation of RSVP blockade state following discrete events like 299 the arrival of a ResvErr message (activate the blockade state) as 300 well as the change in the outgoing Resv message. 302 3.3 RSVP's Capacity Admission Control: Commit and Delete 304 In RSVP, the admission of a new reservation requires both an 305 administrative approval (policy control) and capacity admission 306 control. After being approved by both, and after the reservation was 307 successfully installed, the PEP notifies the remote PDP by sending a 308 report message specifying the Commit type. The Commit type report 309 message signals when billing should effectively begin and performing 310 heavier delayed operations (e.g., debiting a credit card) is 311 permissible by the PDP. 313 If instead a PDP approved reservation fails admission due to lack of 314 resources, the PEP must issue a no-commit report and fold back and 315 send an updated request to its previous state (previously installed 316 reservation). If no state was previously installed, the PEP should 317 issue a delete (DRQ). 319 Internet Draft COPS usage for RSVP 26-Feb-99 321 3.4 Policy Control Over PathTear and ResvTear 323 PathTear and ResvTear messages are not controlled by this policy 324 architecture. This relies on two assumptions: First, that MD-5 325 authentication verifies that the Tear is received from the same node 326 that sent the initial reservation, and second, that it is 327 functionally equivalent to that node holding-off refreshes for this 328 reservation. When a ResvTear or PathTear is received at the PEP, all 329 affected states installed on the PDP should either be deleted or 330 updated by the PEP. 332 3.5 PEP Caching COPS Decisions 334 Because COPS is a stateful protocol, refreshes for RSVP Path and 335 Resv messages need not be constantly sent to the remote PDP. Once a 336 decision has been returned for a request, the PEP can cache that 337 decision and apply it to future refreshes. When the PEP detects a 338 change in the corresponding Resv or Path message, it should update 339 the PDP with the new request-state. PEPs may continue to use the 340 cached state until receiving the PDP response. This case is very 341 different from initial admission of a flow; given that valid 342 credentials and authentication have already been established, the 343 relative long RSVP refresh period, and the short PEP-PDP response 344 time, the tradeoff between expedient updates and attack prevention 345 leans toward expediency. However, this is really a PEP choice, and 346 is irrelevant to PDPs. 348 If the connection is lost between the PEP and the PDP, the cached 349 RSVP state may be retained for the RSVP timeout period to be used 350 for previously admitted flows (but cannot be applied to new or 351 updated state). If connection can not be reestablished with the PDP 352 or a backup PDP after the timeout period, the PEP is expected to 353 purge all its cached decisions. Without applicable cached decision, 354 the PEP must either reject the flow or resort to its LDP (if 355 available) for decisions. 357 Once a connection is reestablished to a new (or the original) PDP 358 the PDP may issue a SSQ request. In this case, the PEP must reissue 359 requests that correspond to the current RSVP state (as if all the 360 state has been updated recently). It should also include as LDP the 361 current (cached) decision regarding each such state. 363 Internet Draft COPS usage for RSVP 26-Feb-99 365 3.6 Using Multiple Context Flags in a single query 367 RSVP is a store-and-forward control protocol where messages are 368 processed in three distinctive steps (input, resource allocation, 369 and output). Each step requires a separate policy decision as 370 indicated by context flags (see Section 2.2). In many cases, setting 371 multiple context flags for bundling two or three operations together 372 in one request may significantly optimize protocol operations. 374 The following rules apply for setting multiple Context flags: 376 a. Multiple context flags can be set only in two generic cases which 377 are guaranteed not to cause ambiguity and represent substantial 378 portion of expected COPS transactions. 380 Unicast FF: 382 [Incoming + Allocation + Outgoing] 384 Multicast with only one Resv message received on the interface 386 [Incoming + Allocation] 388 b. Context events are ordered by time since every message processing 389 must first be processed as Incoming, then as Resource allocation 390 and only then as Outgoing. When multiple context flags are set, 391 all ClientSI objects included in the request are assumed to be 392 processed to the latest flag. This rule applies both to request 393 (REQ) context as well as to decision (DEC) context. 395 For example: when combining Incoming + Allocation for an incoming 396 Resv message, the flowspec included in the ClientSI would be the 397 one corresponding to the Resource-Allocation context (TC). 399 c. Each decision is bound to a context object, which determines 400 which portion of the request context it applies to. When 401 different decisions apply to different sub-groups of context the 402 PDP should send each group of decision objects encapsulated or 403 separated by the context flags object with the context flags 404 applicable to these objects set. (See the examples in Section 5). 406 Internet Draft COPS usage for RSVP 26-Feb-99 408 3.7 RSVP Error Reporting 410 RSVP uses the ERROR_SPEC object in PathErr and ResvErr messages to 411 report policy errors. While the contents of the ERROR_SPEC object is 412 defined in [RSVP,RSVP-EXT], the PDP is in the best position to 413 provide its contents (sub-codes). This is performed in the following 414 manner: First, the PEP (RSVP) queries the PDP before sending a 415 PathErr or ResvErr, and then the PDP returns the constructed 416 ERROR_SPEC in the Replacement Data Decision Object. 418 4 Security Considerations 420 This document relies on COPS for its signaling and its security. 421 Please refer to section "Security Considerations" in [COPS]. 423 Security for RSVP messages is provided by inter-router MD5 424 authentication [MD5], assuming a chain-of-trust model. 425 A likely deployment scenario calls for PEPs to be deployed only at 426 the network edge (boundary nodes) while the core of the network 427 (backbone) constitutes of PIN nodes. In this scenario MD5 trust 428 (authentication) is established between boundary (non-neighboring) 429 PEPs. Such trust can be achieved through internal signing 430 (integrity) of the Policy Data object itself, which is left 431 unmodified as it passes through PIN nodes (see [RSVP-EXT]). 433 Internet Draft COPS usage for RSVP 26-Feb-99 435 5 Illustrative Examples, Using COPS for RSVP 437 This section details both typical unicast and multicast scenarios. 439 5.1 Unicast Flow Example 441 This section details the steps in using COPS for controlling a 442 Unicast RSVP flow. It details the contents of the COPS messages 443 with respect to the following figure. 445 PEP (router) 446 +-----------------+ 447 | | 448 R1 ------------+if1 if2+------------ S1 449 | | 450 +-----------------+ 452 Figure 1: Unicast Example: a single PEP view 454 The PEP router has two interfaces (if1, if2). Sender S1 sends to 455 receiver R1. 457 A Path message arrives from S1: 459 PEP --> PDP REQ := 460 461 463 PDP --> PEP DEC := 464 466 A Resv message arrives from R1: 468 PEP --> PDP REQ := 469 470 471 473 PDP --> PEP DEC := 474 475 476 477 478 479 480 481 483 PEP --> PDP RPT := 484 486 Notice that the Decision was split because of the need to specify 487 different decision objects for different context flags. 489 Time Passes, the PDP changes its decision: 491 Internet Draft COPS usage for RSVP 26-Feb-99 493 PDP --> PEP DEC := 494 495 496 498 Because the priority is too low, the PEP preempts the flow: 500 PEP --> PDP DRQ := 501 503 Time Passes, the sender S1 ceases to send Path messages: 505 PEP --> PDP DRQ := 506 508 Internet Draft COPS usage for RSVP 26-Feb-99 510 5.2 Shared Multicast Flows 512 This section details the steps in using COPS for controlling a 513 multicast RSVP flow. It details the contents of the COPS messages 514 with respect to the following figure. 516 PEP (router) 517 +-----------------+ 518 | | 519 R1-------------+ if1 if3 +--------- S1 520 | | 521 R2----+ | | 522 | | | 523 +--------+ if2 if4 +--------- S2 524 | | | 525 R3----+ +-----------------+ 527 Figure 2: Multicast example: a single PEP view 529 Figure 2 shows an RSVP PEP (router) which has two senders (S1, S2) 530 and three receivers (R1, R2, R3) for the same multicast session. 531 Interface if2 is connected to a shared media. 532 In this example, we assume that the multicast membership is already 533 in place. No previous RSVP messages were received, and the first to 534 arrive is a Path message on interface if3 from sender S1: 536 PEP --> PDP REQ := 537 538 540 PDP --> PEP DEC := 541 543 The PEP consults its forwarding table, and finds two outgoing 544 interface for the path (if1, if2). The exchange below is for 545 interface if1, another exchange would likewise be completed for if2 546 using the new handle B2. 548 PEP --> PDP REQ := 549 550 552 PDP --> PEP DEC := 553 554 555 557 Internet Draft COPS usage for RSVP 26-Feb-99 559 Here, the PDP decided to allow the forwarding of the Path message 560 and provided the appropriate policy-data object for interface if1. 562 Next, a WF Resv message from receiver R2 arrives on interface if2. 564 PEP --> PDP REQ := 565 566 569 PDP --> PEP DEC := 570 571 572 573 574 576 PEP --> PDP RPT := 578 Here, the PDP approves the reservation and assigned it preemption 579 priority of 5. The PEP responded with a commit report. 581 The PEP needs to forward the Resv message upstream toward S1: 583 PEP --> PDP REQ := 584 585 587 PDP --> PEP DEC := 588 589 590 592 Note: The Context object is part of this DEC message even though it 593 may look redundant since the REQ specified only one context flag. 595 Next, a new WF Resv message from receiver R3 arrives on interface 596 if2 with a higher RSpec (Rspec2). Given two reservations arrived on 597 if2, it cannot perform a request with multiple context flags, and 598 must issue them separately. 600 Internet Draft COPS usage for RSVP 26-Feb-99 602 The PEP re-issues an updated handle C REQ with a new context object 603 , and receives a DEC for handle C. 605 PEP --> PDP REQ := 606 607 610 PDP --> PEP DEC := 611 613 PEP --> PDP REQ := 614 615 618 PDP --> PEP DEC := 619 620 621 623 PEP --> PDP RPT := 625 Given the change in incoming reservations, the PEP needs to forward 626 a new outgoing Resv message upstream toward S1. This repeats exactly 627 the previous interaction of Handle E, except that the ClientSI 628 objects now reflect the merging of two reservations. 630 If an ResvErr arrives from S1, the PEP maps it to R3 only (because 631 it has a higher flowspec: Rspec2) the following takes place: 633 PEP --> PDP REQ := 634 635 637 PDP --> PEP DEC := 638 640 PEP --> PDP REQ := 641 642 644 PDP --> PEP DEC := 645 646 647 649 When S2 joins the session by sending a Path message, incoming and 650 outgoing Path requests are issued for the new Path. A new outgoing 651 Resv request would be sent to S2. 653 Internet Draft COPS usage for RSVP 26-Feb-99 655 6 References 657 [RSVP-EXT] Herzog, S. "RSVP Extensions for Policy Control", 658 Internet-Draft, draft-ietf-rap-rsvp-ext-02.txt, Jan. 1999. 660 [RAP] Yavatkar, R., et al., "A Framework for Policy Based 661 Admission Control", IETF , 662 Jan., 1999. 664 [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R., 665 Sastry, A., "The COPS (Common Open Policy Service) Protocol", 666 IETF , Jan. 1999. 668 [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - 669 Functional Specification.", IETF RFC 2205, Proposed Standard, 670 Sep. 1997. 672 7 Author Information and Acknowledgments 674 Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs, 675 Fred Baker, Laura Cunningham, Russell Fenger, Roch Guerin, Ping Pan, 676 and Raj Yavatkar, for their valuable contributions. 678 Jim Boyle Ron Cohen 679 Level 3 Communications CISCO Systems 680 1450 Infinite Drive13 Hasadna St. 681 Louisville, CO 80027 Ra'anana 43650 Israel 682 303.926.3100 972.9.7462020 683 email: jboyle@l3.net ronc@cisco.com 685 David Durham Raju Rajan 686 Intel IBM T.J. Watson Research Cntr 687 2111 NE 25th Avenue P.O. Box 704 688 Hillsboro, OR 97124 Yorktown Heights, NY 10598 689 503.264.6232 914.784.7260 690 David_Durham@mail.intel.com raju@watson.ibm.com 692 Shai Herzog Arun Sastry 693 IPHighway Cisco Systems 694 400 Kelby St., Suite 1500 506210 W Tasman Drive 695 Fort-Lee, NJ 07024 San Jose, CA 95134 696 201.585.0800 408.526.7685 697 herzog@iphighway.com asastry@cisco.com