idnits 2.17.1 draft-ietf-rap-cops-rsvp-03.txt: -(237): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(239): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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. == There are 7 instances 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 12 longer pages, the longest (page 3) being 60 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 13, 1999) is 9203 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 416, 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. -------------------------------------------------------------------------------- 2 Internet Draft Jim Boyle 3 Expiration: August 1999 Level3 4 File: draft-ietf-rap-cops-rsvp-03.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 13, 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 13-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 3.8 Security Considerations........................................10 65 4 Illustrative Examples, Using COPS for RSVP........................10 66 4.1 Unicast Flow Example...........................................10 67 4.2 Shared Multicast Flows.........................................12 68 5 References........................................................16 69 6 Author Information and Acknowledgments............................16 70 Internet Draft COPS usage for RSVP 13-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 13-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 may have one of the 136 Following values that correspond to supported RSVP messages 137 In COPS: 139 1 = Path 140 2 = Resv 141 3 = PathErr 142 4 = ResvErr 144 Note: The PathTear, ResvTear, and the Resv Confirm message types are 145 not supported. 147 2.3 Client Specific Information (ClientSI) 149 All objects that were received within an RSVP message are 150 encapsulated inside the Client Specific Information Object (Signaled 151 ClientSI) sent from the PEP to the remote PDP. (See Section 3.1. on 152 multiple flows packed in a single RSVP message). 154 The PEP and PDP share RSVP state and the PDP is assumed to implement 155 the same RSVP functional specification as the PEP. In the case where 156 a PDP detects the absence of objects required by [RSVP] it should 157 return an in the Decision message indicating "Mandatory 158 client-specific info missing". If, on the other hand, the PDP 159 detects the absence of optional RSVP objects that are needed to 160 approve the Request against current policies, the PDP should return 161 a negative . 163 Unlike the Incoming and Outgoing contexts, �Resource Allocation� 164 isn�t always directly associated with a specific RSVP message. In a 165 multicast session, it may represent the merging of multiple incoming 166 reservations. Therefore, the ClientSI object should specifically 167 contain the SESSION and STYLE objects along with the merged 168 FLOWSPEC, FILTERSPEC list and SCOPE object (whenever relevant). 170 Internet Draft COPS usage for RSVP 13-Feb-99 172 2.4 Decision Object (Decision) 174 COPS provide the PDP with flexible controls over the PEP using 175 RSVP�s response to messages. While accepting an RSVP message, PDPs 176 may provide preemption priority, trigger warnings, replace RSVP 177 objects, and much more, using Decision Commands, Flags and Objects. 179 DECISION COMMANDS 181 Only two commands apply to RSVP 183 Install 185 Positive Response: 186 Accept/Allow/Admit an RSVP message or local resource allocation. 188 Remove 190 Negative Response: 191 Deny/Reject/Remove an RSVP message or local resource allocation. 193 DECISION FLAGS 195 The only decision flag that applies to RSVP: 197 Trigger Error 199 If this flag is set, RSVP should schedule a PathErr, in response 200 of a Path message, or a ResvErr (in response of a Resv message). 202 STATELESS POLICY DATA 204 This object may include one or more policy elements (as specified 205 for the RSVP Policy Data object [RSVP-EXT]) which are assumed to be 206 well understood by the client�s LDP. The PEP should consider these 207 as an addition to the decision already received from the PDP (it can 208 only add, but cannot override it). 210 For example: Given Policy Elements that specify a flow�s preemption 211 priority, these elements may be included in an incoming Resv message 212 or may be also be provided by the PDP responding to a query. 214 Stateless objects must be well understood, but not necessarily 215 supported by all PEPs. For example, assuming a standard policy 216 element for preemption priority, it is perfectly legitimate for some 217 PEPs not to support such preemption and to ignore it. The PDP must 218 be careful when using such objects, especially, it must be prepared 219 for these objects would be ignored by PEPs. 221 Stateless Policy Data may be returned in decisions and apply 222 individually to each of the contexts flagged in REQ messages. When 223 applied to Incoming, it is assumed to have been received as a 224 POLICY_DATA object in the incoming message. When applied to Resource 226 Internet Draft COPS usage for RSVP 13-Feb-99 228 Allocation it is assumed to have been received on all merged 229 incoming messages. Last, when applied to outgoing message it is 230 assumed to have been received in all messages contributing to the 231 outgoing message. 233 REPLACEMENT DATA 235 The Replacement object may contain multiple RSVP objects to be 236 replaced (from the original RSVP request). Typical replacement is 237 performed on the �Forward Outgoing� request (for instance, replacing 238 outgoing Policy Data), but is not limited, and can also be performed 239 on other contexts (such as �Resources-Allocation Request�). In other 240 cases, replacement of the RSVP FlowSpec object may be useful for 241 controlling resources across a trusted zone (with PIN nodes). 242 Currently, RSVP clients are only required to allow replacement of 243 three objects: POLICY_DATA, ERROR_SPEC, and FLOWSPEC, but could 244 optionally support replacement of more objects. 246 RSVP object replacement is performed in the following manner: 248 If Replacement Data decision doesn't appear in a decision message, 249 all signaled objects are processed as if the PDP was not there. When 250 an object of a certain C-Num appears it replaces ALL the instances 251 of C-Num objects in the RSVP message. If it appears empty (with a 252 length of 4) it simply removes all instances of C-Num objects 253 without adding a thing. 255 3 Operation of COPS for RSVP PEPs 257 3.1 RSVP flows 259 Policy Control is performed per RSVP flow, which is defined by the 260 atomic unit of RSVP reservation (TC reservation). Reservation styles 261 may also impact the definition of flows; a set of senders which are 262 considered as a single flow for WF reservation are considered as a 263 set of individual flows when FF style is used. 265 Multiple FF flows may be packed into a single Resv message. A packed 266 message must be unpack where a separate request is issued for each 267 of the packed flows as if they were individual RSVP messages. Each 268 COPS Request should include the associated POLICY_DATA objects, 269 which are, by default, all POLICY_DATA objects in the packed 270 message. Sophisticated PEPs, capable of looking inside policy 271 objects, may examine the POLICY_DATA or SCOPE object to narrow down 272 the list of associated flows (as optimization). 274 Please note that the rules governing Packed RSVP message apply 275 equally to Incoming as well as Outgoing REQ context. 277 3.2 Expected Associations for RSVP Requests 279 When making a policy decision, the PDP may consider both Resv as 280 well as its matching Path state (associated state). State 281 association is trivial in the common unicast case since the RSVP 282 flow includes one Path state and one Resv state. In multicast cases 284 Internet Draft COPS usage for RSVP 13-Feb-99 286 this correspondence may be more complicated, as the match may be 287 many to many. The COPS protocol assumes that the PDP is RSVP 288 knowledgeable and capable of determining these associations based on 289 the contents of the Client REQ message and especially the ClientSI 290 object. 292 For example, the PDP should be able to recognize activation and 293 deactivation of RSVP blockade state following discrete events like 294 the arrival of a ResvErr message (activate the blockade state) as 295 well as the change in the outgoing Resv message. 297 3.3 RSVP's Capacity Admission Control: Commit and Delete 299 In RSVP, the admission of a new reservation requires both an 300 administrative approval (policy control) and capacity admission 301 control. After being approved by both, and after the reservation was 302 successfully installed, the PEP notifies the remote PDP by sending a 303 report message specifying the Commit type. The Commit type report 304 message signals when billing should effectively begin and performing 305 heavier delayed operations (e.g., debiting a credit card) is 306 permissible by the PDP. 308 If instead a PDP approved reservation fails admission due to lack of 309 resources, the PEP must issue a no-commit report and fold back and 310 send an updated request to its previous state (previously installed 311 reservation). If no state was previously installed, the PEP should 312 issue a delete (DRQ). 314 Internet Draft COPS usage for RSVP 13-Feb-99 316 3.4 Policy Control Over PathTear and ResvTear 318 PathTear and ResvTear messages are not controlled by this policy 319 architecture. This relies on two assumptions: First, that MD-5 320 authentication verifies that the Tear is received from the same node 321 that sent the initial reservation, and second, that it is 322 functionally equivalent to that node holding-off refreshes for this 323 reservation. When a ResvTear or PathTear is received at the PEP, all 324 affected states installed on the PDP should either be deleted or 325 updated by the PEP. 327 3.5 PEP Caching COPS Decisions 329 Because COPS is a stateful protocol, refreshes for RSVP Path and 330 Resv messages need not be constantly sent to the remote PDP. Once a 331 decision has been returned for a request, the PEP can cache that 332 decision and apply it to future refreshes. When the PEP detects a 333 change in the corresponding Resv or Path message, it should update 334 the PDP with the new request-state. PEPs may continue to use the 335 cached state until receiving the PDP response. This case is very 336 different from initial admission of a flow; given that valid 337 credentials and authentication have already been established, the 338 relative long RSVP refresh period, and the short PEP-PDP response 339 time, the tradeoff between expedient updates and attack prevention 340 leans toward expediency. However, this is really a PEP choice, and 341 is irrelevant to PDPs. 343 If the connection is lost between the PEP and the PDP, the cached 344 RSVP state may be retained for the RSVP timeout period to be used 345 for previously admitted flows (but cannot be applied to new or 346 updated state). If connection can not be reestablished with the PDP 347 or a backup PDP after the timeout period, the PEP is expected to 348 purge all its cached decisions. Without applicable cached decision, 349 the PEP must either reject the flow or resort to its LDP (if 350 available) for decisions. 352 Once a connection is reestablished to a new (or the original) PDP 353 the PDP may issue a SSQ request. In this case, the PEP must reissue 354 requests that correspond to the current RSVP state (as if all the 355 state has been updated recently). It should also include as LDP the 356 current (cached) decision regarding each such state. 358 Internet Draft COPS usage for RSVP 13-Feb-99 360 3.6 Using Multiple Context Flags in a single query 362 RSVP is a store-and-forward control protocol where messages are 363 processed in three distinctive steps (input, resource allocation, 364 and output). Each step requires a separate policy decision as 365 indicated by context flags (see Section 2.2). In many cases, setting 366 multiple context flags for bundling two or three operations together 367 in one request may significantly optimize protocol operations. 369 The following rules apply for setting multiple Context flags: 371 a. Multiple context flags can be set only in two generic cases which 372 are guaranteed not to cause ambiguity and represent substantial 373 portion of expected COPS transactions. 375 Unicast FF: 377 [Incoming + Allocation + Outgoing] 379 Multicast with only one Resv message received on the interface 381 [Incoming + Allocation] 383 b. Context events are ordered by time since every message processing 384 must first be processed as Incoming, then as Resource allocation 385 and only then as Outgoing. When multiple context flags are set, 386 all ClientSI objects included in the request are assumed to be 387 processed to the latest flag. This rule applies both to request 388 (REQ) context as well as to decision (DEC) context. 390 For example: when combining Incoming + Allocation for an incoming 391 Resv message, the flowspec included in the ClientSI would be the 392 one corresponding to the Resource-Allocation context (TC). 394 c. Each decision is bound to a context object, which determines 395 which portion of the request context it applies to. When 396 different decisions apply to different sub-groups of context the 397 PDP should send each group of decision objects encapsulated or 398 separated by the context flags object with the context flags 399 applicable to these objects set. (See the examples in Section 4). 401 Internet Draft COPS usage for RSVP 13-Feb-99 403 3.7 RSVP Error Reporting 405 RSVP uses the ERROR_SPEC object in PathErr and ResvErr messages to 406 report policy errors. While the contents of the ERROR_SPEC object is 407 defined in [RSVP,RSVP-EXT], the PDP is in the best position to 408 provide its contents (sub-codes). This is performed in the following 409 manner: First, the PEP (RSVP) queries the PDP before sending a 410 PathErr or ResvErr, and then the PDP returns the constructed 411 ERROR_SPEC in the Replacement Data Decision Object. 413 3.8 Security Considerations 415 Security for RSVP messages is provided by inter-router MD5 416 authentication [MD5], assuming a chain-of-trust model. 417 A possible deployment scenario calls for PEPs to be deployed at the 418 network edge (boundary nodes) while PINs are deployed in the core of 419 the network (backbone). In this case, MD5 trust (authentication) 420 must be established between boundary (non-neighboring) PEPs. Such 421 PDP-PDP trust can be achieved through internal signing (integrity) 422 of the Policy Data object (see [RSVP-EXT]). 424 4 Illustrative Examples, Using COPS for RSVP 426 This section details both typical unicast and multicast scenarios. 428 4.1 Unicast Flow Example 430 This section details the steps in using COPS for controlling a 431 Unicast RSVP flow. It details the contents of the COPS messages 432 with respect to the following figure. 434 PEP (router) 435 +-----------------+ 436 | | 437 R1 ------------+if1 if2+------------ S1 438 | | 439 +-----------------+ 441 Figure 1: Unicast Example: a single PEP view 443 The PEP router has two interfaces (if1, if2). Sender S1 sends to 444 receiver R1. 446 A Path message arrives from S1: 448 PEP --> PDP REQ := 449 450 452 PDP --> PEP DEC := 453 455 Internet Draft COPS usage for RSVP 13-Feb-99 457 A Resv message arrives from R1: 459 PEP --> PDP REQ := 460 461 462 464 PDP --> PEP DEC := 465 466 467 468 469 470 471 472 474 PEP --> PDP RPT := 475 477 Notice that the Decision was split because of the need to specify 478 different decision objects for different context flags. 480 Time Passes, the PDP changes its decision: 482 PDP --> PEP DEC := 483 484 485 487 Because the priority is too low, the PEP preempts the flow: 489 PEP --> PDP DRQ := 490 492 Time Passes, the sender S1 ceases to send Path messages: 494 PEP --> PDP DRQ := 495 497 Internet Draft COPS usage for RSVP 13-Feb-99 499 4.2 Shared Multicast Flows 501 This section details the steps in using COPS for controlling a 502 multicast RSVP flow. It details the contents of the COPS messages 503 with respect to the following figure. 505 PEP (router) 506 +-----------------+ 507 | | 508 R1-------------+ if1 if3 +--------- S1 509 | | 510 R2----+ | | 511 | | | 512 +--------+ if2 if4 +--------- S2 513 | | | 514 R3----+ +-----------------+ 516 Figure 2: Multicast example: a single PEP view 518 Figure 2 shows an RSVP PEP (router) which has two senders (S1, S2) 519 and three receivers (R1, R2, R3) for the same multicast session. 520 Interface if2 is connected to a shared media. 521 In this example, we assume that the multicast membership is already 522 in place. No previous RSVP messages were received, and the first to 523 arrive is a Path message on interface if3 from sender S1: 525 PEP --> PDP REQ := 526 527 529 PDP --> PEP DEC := 530 532 The PEP consults its forwarding table, and finds two outgoing 533 interface for the path (if1, if2). The exchange below is for 534 interface if1, another exchange would likewise be completed for if2 535 using the new handle B2. 537 Internet Draft COPS usage for RSVP 13-Feb-99 539 PEP --> PDP REQ := 540 541 543 PDP --> PEP DEC := 544 545 546 548 Here, the PDP decided to allow the forwarding of the Path message 549 and provided the appropriate policy-data object for interface if1. 551 Next, a WF Resv message from receiver R2 arrives on interface if2. 553 PEP --> PDP REQ := 554 555 558 PDP --> PEP DEC := 559 560 561 562 563 565 PEP --> PDP RPT := 567 Here, the PDP approves the reservation and assigned it preemption 568 priority of 5. The PEP responded with a commit report. 570 The PEP needs to forward the Resv message upstream toward S1: 572 PEP --> PDP REQ := 573 574 576 PDP --> PEP DEC := 577 578 579 581 Note: The Context object is part of this DEC message even though it 582 may look redundant since the REQ specified only one context flag. 584 Internet Draft COPS usage for RSVP 13-Feb-99 586 Next, a new WF Resv message from receiver R3 arrives on interface 587 if2 with a higher RSpec (Rspec2). Given two reservations arrived on 588 if2, it cannot perform a request with multiple context flags, and 589 must issue them separately. 591 The PEP re-issues an updated handle C REQ with a new context object 592 , and receives a DEC for handle C. 594 PEP --> PDP REQ := 595 596 599 PDP --> PEP DEC := 600 602 PEP --> PDP REQ := 603 604 607 PDP --> PEP DEC := 608 609 610 612 PEP --> PDP RPT := 614 Given the change in incoming reservations, the PEP needs to forward 615 a new outgoing Resv message upstream toward S1. This repeats exactly 616 the previous interaction of Handle E, except that the ClientSI 617 objects now reflect the merging of two reservations. 619 Internet Draft COPS usage for RSVP 13-Feb-99 621 If an ResvErr arrives from S1, the PEP maps it to R3 only (because 622 it has a higher flowspec: Rspec2) the following takes place: 624 PEP --> PDP REQ := 625 626 628 PDP --> PEP DEC := 629 631 PEP --> PDP REQ := 632 633 635 PDP --> PEP DEC := 636 637 638 640 When S2 joins the session by sending a Path message, incoming and 641 outgoing Path requests are issued for the new Path. A new outgoing 642 Resv request would be sent to S2. 644 Internet Draft COPS usage for RSVP 13-Feb-99 646 5 References 648 [RSVP-EXT] Herzog, S. "RSVP Extensions for Policy Control", 649 Internet-Draft, draft-ietf-rap-rsvp-ext-02.txt, Jan. 1999. 651 [RAP] Yavatkar, R., et al., "A Framework for Policy Based 652 Admission Control", IETF , 653 Jan., 1999. 655 [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R., 656 Sastry, A., "The COPS (Common Open Policy Service) Protocol", 657 IETF , Jan. 1999. 659 [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - 660 Functional Specification.", IETF RFC 2205, Proposed Standard, 661 Sep. 1997. 663 6 Author Information and Acknowledgments 665 Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs, 666 Fred Baker, Laura Cunningham, Russell Fenger, Roch Guerin, Ping Pan, 667 and Raj Yavatkar, for their valuable contributions. 669 Jim Boyle Ron Cohen 670 Level 3 Communications CISCO Systems 671 1450 Infinite Drive13 Hasadna St. 672 Louisville, CO 80027 Ra'anana 43650 Israel 673 303.926.3100 972.9.7462020 674 email: jboyle@l3.net ronc@cisco.com 676 David Durham Raju Rajan 677 Intel IBM T.J. Watson Research Cntr 678 2111 NE 25th Avenue P.O. Box 704 679 Hillsboro, OR 97124 Yorktown Heights, NY 10598 680 503.264.6232 914.784.7260 681 David_Durham@mail.intel.com raju@watson.ibm.com 683 Shai Herzog Arun Sastry 684 IPHighway Cisco Systems 685 400 Kelby St., Suite 1500 506210 W Tasman Drive 686 Fort-Lee, NJ 07024 San Jose, CA 95134 687 201.585.0800 408.526.7685 688 herzog@iphighway.com asastry@cisco.com